Skip to main content

User Adapter

A sovereign venue decides exactly who it serves — membership is a deliberate trust decision, not a side effect. The user adapter manages that decision: who is registered, and which keys may authenticate as them. Registration is an explicit administrative act — successfully authenticating never registers anyone.

Operations

OperationPurposeWho may call
user:createRegister a user DID at the venuevenue admin
user:infoRegistration info for a DIDself, or admin for others
user:listList registered usersvenue admin
user:authentication-addAdd a public did:key authenticatorthe named user, or admin
user:authentication-revokeRevoke an authenticator (audit tombstone kept)the named user, or admin
user:authentication-listList active and revoked authenticatorsself, or admin

"Admin" is precise here: administrative ops require the venue's own authority — the venue DID acting directly, or a venue-rooted delegation of the relevant ability (user/create, user/read, user/authentication-manage) on the venue's users resource. An ordinary registered user, however broad their grant scope, cannot administer users.

Two kinds of user

{
"operation": "v/ops/user/create",
"input": { "username": "alice" }
}

Returns {did: "did:web:venue.example.com:u:alice", registered: true, created: true} — idempotent on repeat.

  • Venue-managed named users: username derives a did:web:<venue>:u:<name> identity under the venue's namespace. These are the users whose authenticator keys the venue manages (authentication-add/-revoke), with rotation and revocation history preserved.
  • Self-sovereign DIDs: pass any valid did (a did:key, an external did:web) instead. Registering it grants venue access but never transfers control — the venue's root authority stops strictly at identities it minted itself.

Agent sub-principal DIDs are refused outright: registering one would hand its bearer the owner's whole namespace. Named users can also be bootstrapped from venue config for repeatable deployments.