Roadmap: identity and live data¶

This page describes a planned direction, not existing behavior. Nothing here is implemented unless a table marks it as existing. The endpoints, event names and field names below are working names and may change before they ship.

The direction combines two ideas. The first is that services hold a reference to someone's data instead of a copy, as shares and requests already do inside one server. The second is that a service learns who it is dealing with, and which facts about that person have been confirmed by someone it trusts, without the data being copied along the way.

What can and cannot be proven¶

A signature proves that the holder of a key took part. It does not prove which human is in front of the screen. Every system built on keys, including government wallets, works around this the same way:

1. One check of the person. A party the service trusts confirms the person once, for example from the chip of an ID card, and signs a statement about them.
2. A binding to a key. That statement names a key held on the person's device and unlocked with a biometric or PIN. Each later use proves that the key is held by whoever passed the check.

Revoked already provides the second part: identity keys are generated on the device (ECDSA P-256) and never leave it, and possession is proven through the challenge handshake. The first part, and the protocols that carry the result to a service, are what this roadmap adds.

A value in the vault is a different matter. It is written by the owner and proves only that the owner wrote it. It becomes a confirmed fact only when a third party signs it, which is what the attestations in step 3 are for.

Three layers¶

Built into the server¶

Every step is implemented inside the PocketBase application itself: routes on its router, data in its collections, schema changes as migrations in migrations/, background work in its hooks. No separate service or sidecar is introduced, so a self-hosted instance stays one container and one data directory.

Signing reuses what is already in the module graph. JSON Web Signatures are available through golang-jwt, which PocketBase already depends on, and SD-JWT is a thin layer on top of a JWS (salted disclosures, hashed with SHA-256). A new dependency is considered only where a specification is too large to implement by hand, and that decision is made per step.

Existing foundations¶

Step overview¶

Step 1: Live data across servers¶

The gap¶

A request answer becomes a live grant only when the responder has an account on the requester's server: the grant points at a record in a vault on that same server. A mailing tool on its own instance therefore receives live grants only from people who signed up there, and typed answers from everyone else. A revocation is noticed only as an in-app notification, and callbacks fire on submission alone.

Planned additions¶

Cross-server grants. A responder signed in on their own server answers a request from another domain. The grant is created on the responder's server, as a link that resolves their vault record, and the requester's server stores its address together with a grant token. The responder keeps seeing, updating and revoking it in their own app, as with any share. The requester's server resolves it on read, through the existing safe outbound client.

Grant events. The responder's server notifies the requester's server when a grant changes state:

An event carries the grant's id and the new state, never a value; the receiver reads the current value again if it needs it. Events are signed with the sending server's root key, so they are verified with the same DNS-anchored chain as everything else. Deliveries are retried with backoff, unlike today's callbacks.

Each requester's server passes events on to its own callback URL, so a tool behind a request learns about changes without polling.

Detecting changes. A record change fans out to every active grant that resolves it, including grants that reach it through an alias. This needs an index from record to grants, kept current when grants are created or revoked.

Bulk reading. A tool reading thousands of grants needs one request per batch rather than one per grant, ETags per grant, and a cache hint (maxAge) set by the responder's server, so a tool may keep a value briefly without holding a copy indefinitely.

As implemented¶

The step is in place as planned. Where the implementation settled a detail the plan left open, it is recorded here.

Limits¶

A service still needs its own database for its own records, such as orders, invoices and delivery logs, some of which are subject to retention periods. What is replaced is the copy of the person's data, not the service's storage. If a responder's server is unreachable, their grants do not resolve until it returns; this is stated to the tool rather than hidden behind a stale copy.

Step 2: Sign in with Revoked¶

Revoked becomes an OpenID Connect provider, so existing client libraries work unchanged.

Mapping onto what exists¶

Claims¶

Asking for data is expressed as a claims request naming vault keys. Data requested this way is delivered as grants (step 1); a plain copy is not offered (see the decisions below).

Decisions¶

Still open: how the root key is rotated, given that it is pinned in DNS. That question belongs to the trust chain as a whole rather than to this step.

As implemented¶

Step 3: Attestations by other domains¶

An attestation is a statement one domain signs about an identity of another: for example, verify.example confirms that identity X belongs to a verified adult with a given name, or club.example confirms a current membership.

What already fits¶

The trust chain verifies exactly this shape: DNS pin, served key, signature, current status. Today it covers only a server's own identities. For attestations, the issuer is a different domain from the one that issued the identity, and both chains are checked.

Design decisions¶

• Format. Attestations are issued as SD-JWT credentials from the start (step 4), with the DNS pin as the way to find and check the issuer's key. A format of Revoked's own would have to be replaced later.
• Binding. The credential names the holder's identity key (cnf), so only the device holding that key can present it.
• Status. The issuer's current opinion is checked through a status endpoint like the identity status today, or a status list as defined for SD-JWT credentials.
• Trust. DNS proves which domain signed, not whether that domain deserves trust. Which attesters a service accepts remains the service's policy, and is stated in the verification result rather than decided by Revoked.

Decisions¶

As implemented¶

Limits¶

Presentations of one credential are linkable: each shows the same key and the same identity. The standard format offers no remedy short of issuing many single-use credentials, which is left for later. A revocation reaches a verifier within the five minutes a status list may be kept. A restored backup forgets revocations made after it, as it does for identities.

Requests cannot yet require an attestation; a service asks for one separately, through the presentation link.

Step 4: OpenID4VCI and OpenID4VP¶

Parts¶

Keys¶

The device identity keys are ECDSA P-256 and fit key binding as they are. The server root key is RSA-2048, while the common credential profiles require ES256. Issuing therefore uses a separate ECDSA P-256 key, certified by the root key and published alongside it, so the DNS pin still anchors it. That key exists since step 3.

A verifier outside Revoked does not know the DNS pin. For such verifiers the issuer metadata at /.well-known/jwt-vc-issuer is what the standard prescribes, resting on the domain's TLS certificate; the certification by the root key is an addition they ignore.

Interoperability¶

Within Revoked and with services that accept Revoked as a wallet, this works fully. Official verifiers under the EU identity framework, such as banks checking state-issued identity data, expect a certified wallet that proves its certification. Revoked can present credentials to them technically, but acceptance depends on certification, which is a matter of regulation rather than code. Attestations from organizations (employers, clubs, landlords) are not affected by this.

Step 5: eID and EU wallet as a source¶

The ID card is not stored in the vault as an image. A scan proves nothing, as it is easily altered, and German law restricts copies of the ID card. What carries weight is the data signed by the card's chip, read through the eID function, or the identity data held in the state wallet.

Revoked does not compete with the state wallet in proving who someone is. Instead, an attester (step 3) reads the eID or the wallet once and issues an attestation bound to the person's Revoked identity. Access to eID data requires an authorization certificate from the responsible state body, or a partnership with a provider that already holds one. That is organizational and legal work, not code.

Order¶