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.
Actors
Agent · Resource · Person server · User
Sequence
- 1
Agent→Resource
Signed request; resource sees ps claim on the agent token
- 2
Resource→Agent
401 requirement=auth-token plus resource token (aud = PS)
- 3
Agent→Person server
Signed POST of the resource token to token_endpoint
May 202 + interaction if the user must approve a mission or scope
- 4
Person server→Agent
aa-auth+jwt with user claims and consent
- 5
Agent→Resource
Retry with auth token; resource applies its own policy to (iss, sub)
Caveats
sub is directed per issuer. The same email from two person servers is two subjects. Draft-10 vs editor's copy may differ on person tokens and a fifth mode. Editor's copy splits token_endpoint into person_token_endpoint and auth_token_endpoint.
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.