Extension proposal: DID-binding profile for Person Servers (Avatar)
Summary: Dasith Wijesiriwardena's "The Errand" names two edges of agentic delegation that AAuth doesn't yet close: the bilateral setup a Person Server still needs with every new resource (Dad gets linked as trusted contact "the first time the family deals with the chain"), and the open question of delegation containment — whether a sub-agent actually stayed inside what its parent was authorized to do, as opposed to the protocol merely being able to show that a handoff took place. This issue proposes Avatar: a DID-binding profile for Person Servers that closes both, without breaking changes to the existing spec.
The gap, in Errand terms
AAuth gives Sam (the Agent) a precise, per-instance cryptographic identity — that's the protocol's central win. It doesn't give Dad (the Person Server) the same thing. Dad is reachable at a URL, but a URL isn't a portable identity, which shows up as two concrete problems:
- First-time setup, every time. Each new resource chain has to independently establish that this Dad really speaks for this Mom before trusting him — the exact bilateral setup AAuth's agent-side identity was built to avoid.
- No containment proof. When Sam delegates to his little brother, the protocol can show the handoff happened, but not that the brother stayed inside what Sam was actually authorized to do. Call chaining proves the chain; it doesn't bound it.
Both stem from the same root cause: no portable, independently verifiable identity root for the human, only for the agent.
The proposal
Three additive pieces, all fitting within existing AAuth extension points:
-
DID-anchored PS discovery — a did claim in /.well-known/aauth-person.json, resolvable to a DID document whose aauth-person service endpoint confirms the PS URL. No bilateral setup required; PS URL can change while the DID stays stable.
-
Avatar agent token — an agent token with avatar: true and ps_did claims indicating the agent is the person's primary agent, with its identity root anchored to the human's DID rather than an ephemeral keypair.
-
Delegation assertion — a signed JWT from an Avatar agent vouching for a sub-agent's identity and constraining its authority, scoped to a Mission. Allows agent-to-agent delegation without requiring a new PS consent interaction per sub-agent call.
All three use existing AAuth JWT signing profiles and token structures. The delegation assertion is the only net-new artifact.
Full write-up
Detailed proposal with JSON examples, open questions, and explicit non-goals (this is not a competing protocol; it's not DID maximalism):
Avatar: A DID-Binding Profile for AAuth Person Servers
Open questions I'd like community input on
- Should the profile constrain allowed DID methods, or stay method-agnostic? (
did:web has adoption advantages; did:key has stronger self-sovereignty guarantees)
- Should delegation chains be depth-bounded before a PS interaction is required?
- How does this interact with the federated four-party access mode in enterprise deployments where the org operates both the DID and the PS?
Happy to iterate on any of this — particularly the delegation JWT structure, which I know touches the scope-vs-intent tension in the current spec.
Extension proposal: DID-binding profile for Person Servers (Avatar)
Summary: Dasith Wijesiriwardena's "The Errand" names two edges of agentic delegation that AAuth doesn't yet close: the bilateral setup a Person Server still needs with every new resource (Dad gets linked as trusted contact "the first time the family deals with the chain"), and the open question of delegation containment — whether a sub-agent actually stayed inside what its parent was authorized to do, as opposed to the protocol merely being able to show that a handoff took place. This issue proposes Avatar: a DID-binding profile for Person Servers that closes both, without breaking changes to the existing spec.
The gap, in Errand terms
AAuth gives Sam (the Agent) a precise, per-instance cryptographic identity — that's the protocol's central win. It doesn't give Dad (the Person Server) the same thing. Dad is reachable at a URL, but a URL isn't a portable identity, which shows up as two concrete problems:
Both stem from the same root cause: no portable, independently verifiable identity root for the human, only for the agent.
The proposal
Three additive pieces, all fitting within existing AAuth extension points:
DID-anchored PS discovery — a
didclaim in/.well-known/aauth-person.json, resolvable to a DID document whoseaauth-personservice endpoint confirms the PS URL. No bilateral setup required; PS URL can change while the DID stays stable.Avatar agent token — an agent token with
avatar: trueandps_didclaims indicating the agent is the person's primary agent, with its identity root anchored to the human's DID rather than an ephemeral keypair.Delegation assertion — a signed JWT from an Avatar agent vouching for a sub-agent's identity and constraining its authority, scoped to a Mission. Allows agent-to-agent delegation without requiring a new PS consent interaction per sub-agent call.
All three use existing AAuth JWT signing profiles and token structures. The delegation assertion is the only net-new artifact.
Full write-up
Detailed proposal with JSON examples, open questions, and explicit non-goals (this is not a competing protocol; it's not DID maximalism):
Avatar: A DID-Binding Profile for AAuth Person Servers
Open questions I'd like community input on
did:webhas adoption advantages;did:keyhas stronger self-sovereignty guarantees)Happy to iterate on any of this — particularly the delegation JWT structure, which I know touches the scope-vs-intent tension in the current spec.