Jeff, Iman, all,
Both points were correct, and the fix is now in the reference
implementations and in the prepared -01 text. I also owe a
correction: my earlier message overstated the -00 state -- at that
point the DA was not yet a compliant RFC 7523 assertion, and the two
of you caught it.
1. DA as an RFC 7523 assertion. AIC-JWT Section 5.2 defined the DA
payload (agent_id / principal / requested_lifetime / ts / nonce,
among others) without iss / sub / aud / exp, while Section 10.2
presented it as a jwt-bearer grant -- the two did not
interoperate. The DA now carries iss (= principal realm:id),
sub (mode-dependent), aud (= intended authorization server), exp
(= ts + requested_lifetime, single canonical expression), iat (=
ts when present) and jti (= nonce). Validation enforces each;
expired or malformed grants fail closed. The DA `ver` is
bumped
to 2, so -00-shaped DAs are rejected explicitly rather than
silently downgraded.
2. Role placement per mode. In representative mode the resource
owner / principal is the sub of the DA and of the issued token, and
the agent is the RFC 8693 act / OAuth client. In authorized
mode
the agent is sub as the authorized accessor (RFC 7523 Section 3,
item 2A), with the principal as the signing issuer. Because
the
DA is signed by the principal rather than by the agent, authorized
mode remains an authorization grant, not client
self-identification (the CIMD lane). Consistency checks
enforce
this: old-shaped tokens (agent as sub in representative mode, or
an act claim in authorized mode) are rejected. The validation
decision now exposes both the audit actor (principal, in
representative
mode) and the executor (the agent), so moving the agent out of sub
does not lose it from audit.
3. Token exchange. The prepared -01 (Section 10.4) states the mapping
explicitly: the exchanged token keeps authorized-mode AIC semantics
(agent as sub, principal in aic.principal, capabilities =
intersection), the
subject_token is a grants source rather than the issued subject
(re-issuing with the resource owner as subject would require a
representative-mode DA signed by that owner, which this flow does
not re-mint), and a representative-mode token is rejected as an
actor_token.
The deviation from the RFC 8693 default subject/actor mapping is
normative and intentional rather than silent.
4. Honest boundary. A deployment where the accountable operator
differs from the resource owner needs a third binding; -01 records
that as future work and does not conflate the two parties.
The fixes are implemented in the reference implementations (Go
types/aicjwt + the aic-jwt OAuth wrapper, and the
TypeScript/WebCrypto library) with regression tests covering each
point above; Go and TypeScript suites pass, including Go race.
Reference implementations:
- types release v0.5.1: https://github.com/varwof/types/tree/v0.5.1
- aic-jwt fix branch:
https://github.com/varwof/aic-jwt/tree/fix/rfc7523-oauth-flow
The -01 draft revision containing the same text is being finalized for
posting; the -00 revision on the Datatracker remains current.
Runnable vectors on request.
Thanks for the precise reviews -- this was a real claims/role mismatch,
not a wording preference.
Best,
Jijie Wei
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
