Flow · user-delegated
AAuth three-party (PS-asserted user claims)
The resource has no AS of its own. It accepts identity claims from the agent's person server after the user consents at the PS.
Use the hop list beside the stage, or the phase labels, to jump. Every hop has Now, Why, the RFC, and chips — none are skipped.
Actors
Agent · Agent provider · Resource · Person server · User
Sequence
Animated sequence · user-delegated
AAuth — How does a resource accept user claims without running an AS?
AAuth three-party (PS-asserted user claims)
The resource has no AS of its own. It accepts identity claims from the agent's person server after the user consents at the PS.
Now · 1/14· Discover· AAuth draftYou are here
Agent provider→Agent·Issues aa-agent+jwt bound to the agent's signing key (ps names the person server)
typ aa-agent+jwt: sub is the agent identifier, cnf binds the key, ps names the person server.
Why Three-party still starts with an agent token. The provider is not an OAuth AS. Do not start at the 401.
A wax-sealed ID card plus a pointer to the owner's notary.
- typ: aa-agent+jwt from the spec
- cnf from the spec
- ps from the spec
Solid = from the spec
sub is directed per issuer. The same email from two person servers is two subjects. Draft-11 has five modes, including person identity, and splits the old token_endpoint into person_token_endpoint and auth_token_endpoint. A resource token is issued only after a person token or auth token has been verified.
Transcript
- 1
DiscoverAgent provider→AgentAAuth draft
Issues aa-agent+jwt bound to the agent's signing key (ps names the person server)
typ aa-agent+jwt: sub is the agent identifier, cnf binds the key, ps names the person server.
Why Three-party still starts with an agent token. The provider is not an OAuth AS. Do not start at the 401.
A wax-sealed ID card plus a pointer to the owner's notary.
- typ: aa-agent+jwt
- cnf
- ps
- 2
DiscoverAgent provider→Agent providerAAuth draft
Publishes JWKS at {iss}/.well-known/{dwk}
The provider hosts aauth-agent.json and JWKS. This is not an OAuth token endpoint.
Why Do not skip JWKS. The resource will fetch these keys on the first signed request.
Hang the signet on the wall.
- iss
- dwk
- JWKS
- 3
ProveAgent→ResourceRFC 9421
Signed request; resource sees ps claim on the agent token
Signature-Key carries aa-agent+jwt with a ps claim. Wire is still signed HTTP.
Why The resource knows which agent called and which person server can speak for a user. There is still no authorization server on the resource.
Wax seal plus a pointer to the owner's notary.
- Signature-Key
- typ: aa-agent+jwt
- ps
- 4
ProveResource→Agent providerAAuth draft
Fetches JWKS and verifies the agent signature
Resolve {iss}/.well-known/{dwk}, fetch JWKS, verify RFC 9421 + typ aa-agent+jwt + cnf.
Why Do not skip JWKS fetch before the 401. The resource must know the seal is real before asking for user claims.
Check the messenger's seal before asking for the owner's slip.
- JWKS
- cnf
- 5
GrantResource→AgentAAuth draft
401 AAuth-Requirement: auth-token plus resource token (aud = PS)
401 carries AAuth-Requirement (requirement=auth-token) and typ aa-resource+jwt whose aud is the person server — not an OAuth AS. Draft-11 sends this only after a person token or an auth token was verified; otherwise the challenge is requirement=person-token.
Why Challenges replace browser redirects. The resource token describes what needs authorizing. This is not WWW-Authenticate: Bearer.
The door hands back a short note: go get the owner's permission slip.
- AAuth-Requirement
- requirement=auth-token
- typ: aa-resource+jwt
- aud=person server
- 6
GrantAgent→Person serverAAuth draft
Signed POST of the resource token to the person-server auth_token_endpoint
Draft-11: POST aa-resource+jwt to the PS auth_token_endpoint, still signed with the agent key. The resource issues that resource token only after it has verified a person token or an auth token.
Why Only the person server speaks for the user. The agent never presents a password to the resource. The agent does not call an OAuth authorization endpoint.
Take the door's note to the owner's notary.
May 202 + interaction if the user must approve a mission or scope
- auth_token_endpoint
- typ: aa-resource+jwt
- 7
GrantPerson server→AgentAAuth draft
May 202 + interaction if the user must approve
If consent is needed, the PS returns 202 with interaction instructions. The agent still has no aa-auth+jwt.
Why Optional only if the user already approved this mission/scope. Do not skip the wait: without this hop a beginner thinks the auth token arrives instantly.
The notary says: wait — I have to ask the owner.
- 202
- interaction
- 8
GrantPerson server→UserAAuth draft
Notifies the user that this agent wants a grant at this resource
The person server contacts the user. The resource is not in this hop.
Why The user must see what is being asked. This is not an OAuth front-channel redirect from the agent.
A ping from the owner's notary: is this the errand you meant?
- person server
- user
- 9
GrantUser→Person serverAAuth draft
Authenticates at the person server
The user proves who they are at the person server. No password is given to the agent or to the resource.
Why Authentication and consent are different hops. That page MAY wrap ordinary OIDC — the agent still never talks to that OP.
The owner shows ID at their own desk, not at the door.
- authentication
- person server
- 10
GrantUser→Person serverAAuth draft
Consents to the mission or scope at the person server
The user approves the grant (scope or R3 / mission). This is the three-party authorization decision.
Why User consent lives at the PS, not at an OAuth authorization endpoint on this hop.
The owner signs the permission slip at their own desk.
- consent
- mission / scope
- 11
GrantPerson server→AgentAAuth draft
Issues aa-auth+jwt with user claims, cnf-bound to the agent key, aud = resource
typ aa-auth+jwt: iss is the PS, aud is the resource, cnf matches the agent. sub is directed per issuer.
Why The grant names the user at this PS and is glued to the agent's key (lifetime ≤ 1 hour). Not a Bearer access token from an AS.
A permission slip wax-sealed to this messenger's key.
- typ: aa-auth+jwt
- sub
- cnf
- aud=resource
- 12
CallAgent→ResourceRFC 9421
Retries signed HTTP with the auth token
The agent retries the resource request. The resource must verify again — do not reuse the identity-based decision.
Why Every call is still signed. Presenting aa-auth+jwt without a signature is the wrong cousin of Bearer.
Seal plus permission slip. Back to the same door.
- Signature-Key
- typ: aa-auth+jwt
- 13
CallResource→Person serverAAuth draft
Fetches the person server's JWKS to verify the auth token
The resource resolves the PS well-known (iss / dwk on aa-auth+jwt) and fetches JWKS.
Why Do not skip this. The auth token is signed by the PS, not by the agent provider. A cached agent JWKS is the wrong keyring. Four-party would verify against a resource-side access server — the agent still would not talk to that AS.
Check the permission slip against the notary's published signet.
- iss
- dwk
- JWKS
- 14
CallResource→AgentAAuth draft
Verifies signature + aa-auth+jwt and applies policy to (iss, sub)
Checks: RFC 9421 signature, typ aa-auth+jwt, aud = this resource, cnf matches the signing key, exp ≤ 1 hour. Then local policy on (iss, sub).
Why The resource still verifies the HTTP signature. The auth token adds which user, at which PS. (iss, sub) is directed — the same email from two person servers is two subjects.
Seal plus permission slip. The door decides from both.
- typ: aa-auth+jwt
- iss
- sub
- cnf
- aud
Caveats
sub is directed per issuer. The same email from two person servers is two subjects. Draft-11 has five modes, including person identity, and splits the old token_endpoint into person_token_endpoint and auth_token_endpoint. A resource token is issued only after a person token or auth token has been verified.
Why this hop looks this way
This is user-delegated AAuth, not p2p. The agent still signs every HTTP call; the grant comes from the PS as aa-auth+jwt (≤ 1 hour, cnf-bound to the agent key, aud = resource).
Four-party adds a resource-side access server. The agent still only talks to the resource and its PS; the PS federates. That federation is not OpenID Federation and not OAuth identity chaining.