ISSUE · UTILITIES
The bill you already send is the proof your customer is missing.
A utility knows two things about a customer that half the economy keeps asking them to prove: where they live, and that they pay on time. Today that knowledge leaves the utility as a PDF the customer screenshots at a landlord. Signed, it becomes a verified-service-address credential — the same fact, checkable by anyone, forgeable by no one, and carried by the customer instead of scattered across inboxes.
Proof of address, before and after
What happens today
The landlord asks for "a recent utility bill". The customer forwards a PDF that anyone with a text editor could have altered, containing their full name, address, account number, usage history and tariff — when the landlord needed one fact: this person receives service at this address.
What happens with a signed bill
The utility signs the fact at billing time. The customer presents verified-service-address; the landlord checks the signature in seconds. The account number, the usage curve and the tariff were never in the message. The bill PDF retires from its second career as an identity document.
What exists at the seam today, precisely
This is the one sector page on this site that can point at running integration code, and precision matters more than enthusiasm. The bill deposit rail exists at the platform seam: a utility tenant can deposit bill records through a contracted, idempotent API, with the contract package vendored on both sides. That is the plumbing. The consumer-facing utilities product that would stand on it — bill presentment, payment history as a credential stream — is documented design, not shipped software. Two different states, and the register below refuses to blur them.
What a utility would actually be adopting today.
No utility issues on this platform today. The deposit rail exists at the seam; the consumer product above it is planned. Issuance for a tenant is operator-run — a utility cannot yet self-serve its own credential types. The rows below are the measured state of the pieces a utility programme would stand on.
- PLANNED A wallet a person installs from an app store. wallet-native You cannot hold a credential on a phone you own. Everything a person would do with a proof waits behind this.
The register holds 17 live · 2 partial · 2 planned · 5 not yet.
4 of the 5 capabilities this page depends on have no row in the register yet, so this page will not print a state for them. They are named rather than dropped, because a slice that silently shortens itself is the same defect as a claim with no receipt.
- vc-issuance
- selective-disclosure
- partner-certification
- self-service-onboarding
The register route serves, but it carries no row for these yet. List what it does carry:
curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'