id: did-minting title: The server mints the identifier, not its caller status: open crates: [didbot-pds, didbot-identity] dependsOn: [agent-accounts] exitCriterion: > A provisioning request carries no identifier and gets an account whose DID the server chose; two requests carrying the same correlation key get the same account; and a DID whose account has been deleted is never minted again. #

did-minting #

A did:web DID is a hostname, and this server takes that hostname from whoever asked for the account. ProvisionRequest::agent_id is documented as "the DNS label the DID will be minted from", and Provisioner::provision passes it straight to AgentDid::mint. The server checks two things about it: that it is a legal DNS label (validate_label — lowercase ASCII, digits, hyphens, no hyphen at either end) and that the minted host sits at or below the zone. Neither of those is a claim about identity.

Everything else about the identifier is the caller's decision. That is the wrong side of the boundary for the one value in this system that can never be changed afterwards.

What follows from it #

A harness may not have an identifier to give. A top-level session has no agent_id of its own, and a client papers over it by deriving a label out of whatever session bookkeeping it holds, because the harness does not promise the format. That is a good workaround living in the wrong place — it is one client's convention, not a rule the server enforces, and a second client is free to do something else.

Nothing makes the identifier globally unique. derive_agent_id renders 40 bits of an FNV-1a digest, and its own documentation puts the collision odds at roughly one in twenty thousand for ten thousand agents on one server. It argues that is acceptable because a collision is an availability problem: the second provisioning fails against a DID that already exists. That argument holds only for one server and only while both accounts are live.

A deleted DID can be minted again. The duplicate check is self.store.get(&did).is_some() — live accounts only. Names get a hold (DEFAULT_HOLD, thirty days) precisely so a recycled name cannot point at a different agent. DIDs get nothing, even though a DID is the thing at:// URIs and signatures are written against. Provisioner::remove already knows this: it forgets the commit history because "a later account minted at the same DID [would] inherit a head naming blocks nothing holds". It defends the block store against the scenario and leaves the identity alone.

The caller chooses what its permanent public name says. Nothing stops a request minting a label that reads as somebody else's agent, or one that carries harness-internal detail — a ticket id, a path, a username — into a name that is published in DNS, served in a DID document, and never revocable.

These are four symptoms of one thing: the identifier is an input where it should be an output.

The shape of the fix #

The server mints. A request carries whatever correlation the caller has — possibly nothing — and that value is used to answer "does this context already have an account", never to name it.

• Split the identifier from the correlation key. ProvisionRequest grows a correlation: Option<String> that is opaque to identity, and loses agent_id. Nothing about the key reaches the DID, so it needs no label rules and can be as long, as structured or as absent as a harness requires. This is a breaking change to the provisioning surface and to every caller of it — didbot-pds's --demo is the one in this repository — so it lands as a ! commit.
• Choose what the server mints from. didbot_name::generated already ships Uuid, Random, Counter and Timestamp with their disclosure properties written down; the machinery exists and is wired to handles rather than to DIDs. A random label of sufficient width makes reuse negligible rather than a policy to enforce, which is the argument for it over a counter — but a counter is durable and auditable, and this is a decision to make explicitly rather than inherit. Which zone it is minted from is name-pools's question.
• Keep provisioning idempotent. Today agent_id doubles as the idempotency key: re-provisioning the same session hits the duplicate refusal. Once the server mints, the store needs a durable correlation-key-to-DID index to answer the same question, and a request with no correlation key at all has to mean "a new account, always".
• Decide what a deleted DID becomes. name-pools answers this — the DID pool is never reclaimed from, so a deleted account frees the account and not the name — and this item is the part that lands here: a permanent ledger of minted DIDs, consulted before every mint. Provisioner::remove's comment about a later account inheriting a stale head stops being a defence against something the design allows and becomes a note about something it forbids.
• Say what happens to already-minted DIDs. They are permanent by definition, so this cannot be a migration that renames them. The epic exits with old accounts untouched and new ones minted server-side.
• Take a name hint without letting it fail. A caller may say what it would like to be called; how that is resolved, reserved and reported back is name-pools's, but the request type is this epic's: correlation is not a hint and a hint is not an identifier.
• Keep the readable prefix a server affordance. Once the server mints, a client has nothing to derive. The slug — the readable prefix that let an operator match a DID to a session by eye — is a real affordance and should be something the server attaches, not the identifier itself.

What this is not #

Not a change to attestation. What authorizes a provisioning is node's and attestation's question, and it stays theirs; this epic is only about who chooses the name once a request is admitted.

Not zone-scale. That epic counts names against a finite pool and records against a provider's quota. This one is about where a single name comes from, and a wider mint space makes zone-scale's arithmetic slightly worse rather than better.

Done #

Nothing yet.