The problem
Most of the people we need to reach already implemented OIDC. They have a working mental model of an ID token, and nothing on the site connects AAuth to it — so they build the bridge themselves and get it wrong.
From the August 2026 office hours, the room arrived at this unprompted:
Person token is a strict subset of an ID token (just sub). Auth token is a superset — all the ID token claims plus authorization claims.
The intuition is good. The detail is wrong in the one place that matters: it drops cnf. A person token is bound to the agent's key and is not a bearer credential, which is the whole security difference. Someone leaving with "it's an ID token with fewer claims" will design something insecure.
What to add
A page — "AAuth for OIDC developers" or similar — that starts from what they know:
- Your ID token says a person signed in. A person token says which person an agent is acting for. Same shape, different assertion.
- It is not a bearer token.
cnf binds it to the agent's signing key. Stealing it gets you nothing.
- There is no
nonce, because there is no sign-in event. Nothing to replay-protect in the OIDC sense.
sub is directed and stable across agents. Same person at that resource whichever agent shows up; a different value at every other resource.- The auth token is where authorization lives —
scope, account, and with the Budgets extension, budget.
Then the part that actually sells it: if you run an OP today, you are most of the way to running a person server. You already have the person relationship, the consent surface, and directed identifiers. Spell out what is genuinely new — key-bound tokens, the person token endpoint, and the token endpoint that turns a resource token into an auth token.
A comparison table works here. Suggested rows: what it asserts, audience, bearer vs proof-of-possession, lifetime, what carries authorization.
Companion issue in the spec repo: dickhardt/AAuth#96 covers the same gap in the normative text. The site version should be the one people actually read.
The problem
Most of the people we need to reach already implemented OIDC. They have a working mental model of an ID token, and nothing on the site connects AAuth to it — so they build the bridge themselves and get it wrong.
From the August 2026 office hours, the room arrived at this unprompted:
The intuition is good. The detail is wrong in the one place that matters: it drops
cnf. A person token is bound to the agent's key and is not a bearer credential, which is the whole security difference. Someone leaving with "it's an ID token with fewer claims" will design something insecure.What to add
A page — "AAuth for OIDC developers" or similar — that starts from what they know:
cnfbinds it to the agent's signing key. Stealing it gets you nothing.nonce, because there is no sign-in event. Nothing to replay-protect in the OIDC sense.subis directed and stable across agents. Same person at that resource whichever agent shows up; a different value at every other resource.scope,account, and with the Budgets extension,budget.Then the part that actually sells it: if you run an OP today, you are most of the way to running a person server. You already have the person relationship, the consent surface, and directed identifiers. Spell out what is genuinely new — key-bound tokens, the person token endpoint, and the token endpoint that turns a resource token into an auth token.
A comparison table works here. Suggested rows: what it asserts, audience, bearer vs proof-of-possession, lifetime, what carries authorization.
Companion issue in the spec repo: dickhardt/AAuth#96 covers the same gap in the normative text. The site version should be the one people actually read.