Hi all, While transaction-tokens is in WG Last Call, I implemented it (and identity-chaining) in an open-source OAuth 2.1 server and hit one concrete underspecification I'd like the editors' view on.
Section 14.6 (Scope Processing) says the TTS "MUST ensure that the requested scope of the Txn-Token is equal or less than the scope(s) identified in the subject_token." It doesn't say what to do when the subject_token carries no 'scope' claim at all -- which isn't a contrived edge case: an OIDC id_token used as subject_token (an RFC 7521/8693-compatible subject token type) does not carry a 'scope' claim by definition, so the literal path through §14.6 in that flow yields no scope check at all. In my implementation, a literal reading of the MUST meant the subset check only fires when the parent scope is non-empty -- so an absent parent 'scope' currently lets any requested scope through unrestricted, which is arguably the unintentional-scope-increase case the section exists to prevent. "absent == empty set" (refuse) and "absent == unconstrained" (allow) are both defensible from the text as written, which is why I think it needs an explicit sentence. The suggested clarification (one sentence in §14.6): "If the subject_token carries no `scope` claim, the TTS MUST treat the available scope as the empty set for this comparison." Full rationale on the issue: - https://github.com/oauth-wg/oauth-transaction-tokens/issues/357 The implementation is authgent (Apache-2.0). Its conformance is mapped section-by-section to source, with 8 tests exercising transaction-tokens and 17 exercising identity-chaining: - https://github.com/authgent/authgent/blob/main/STANDARDS.md For the running-code record, I also filed an RFC 7942 implementation status report covering both drafts (tracks transaction-tokens-08 and identity-chaining-15): - https://datatracker.ietf.org/doc/draft-agnihotri-oauth-agent-impl-status/ Identity-chaining is in the RFC Editor queue so I'm not raising it for change here; the report notes one analogous claims-transcription edge (a subject token with no resolvable 'sub', Section 2.5) for the record and for any future erratum. Happy to do interop testing against another implementation. Thanks, Dhruv Agnihotri
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
