[OAUTH-WG] Re: New I-D: Identity Continuation Assertion for OAuth 2.0 Token Exchange (request for review)

[Mohamad Khalil Yossif <[e-mail]>]

> Karl,
> 
> Nothing to correct. The three-layer split is right, and the sentence I
> would have argued with — PSEA at the hop where the human is present,
> ICA at the hop where they are not — is one I wrote myself, so I will
> leave it standing.
> 
> Open item 9 is where I can be useful, and I think it turns on a
> distinction that is easy to lose because both halves are called
> "testable".
> 
> A representation carried in the envelope and evaluated by the
> receiving authorization server is testable by that server. That is
> useful and it is probably what ICA should carry: scopes are the
> natural form, since scopes are what the receiving server already
> evaluates, and it needs nothing a mint does not already know.
> 
> What it does not give you is a representation a third party can check
> after the fact. The evaluation is performed by a party inside the
> trust boundary the ceiling exists to constrain — the receiving domain
> is bounded by the ceiling and is also the one applying it. A relying
> party that trusts neither the identity provider nor the receiving
> domain cannot re-run the check. That is not hypothetical: a regulator
> reconstructing a decision, a card issuer in a chargeback, a
> counterparty in a dispute. All three arrive after the fact and none of
> them can ask the receiving server to do it again.
> 
> The two are not in tension and they want different things.
> 
> The narrow suggestion: alongside whatever representation the envelope
> carries for evaluation, carry a commitment to it — a digest over a
> canonical form of the ceiling, bound into the assertion. It changes no
> evaluation, adds no field a mint has to understand, and costs a hash.
> What it buys is that a later artifact can reference the exact ceiling
> in force at establishment without ICA having to define what a ceiling
> contains, or take a position on whether it is scopes or an
> authorization detail.
> 
> The reason to want the commitment separate from the representation is
> the one my own draft turns on. A ceiling the identity provider
> computes and the receiving server evaluates establishes what those two
> agreed. It does not establish what the human agreed, because neither
> of them is the human. Keeping the commitment canonical and
> recomputable is what lets an artifact from the layer that does speak
> for the human point at the same bytes.
> 
> So the form matters more than the content. If item 9 resolves toward
> something a third party can recompute over canonical bytes, the layers
> join. If it resolves toward a policy-bound representation only, they
> do not, and the authorization layer has to carry its own copy of the
> ceiling — duplication, and somewhere for the two to drift.
> 
> That is a preference about encoding rather than about scope, and it
> does not ask ICA to carry anything it would not carry anyway.
> 
> On Mission-Bound: I owe you a proper read rather than another
> paragraph. draft-yossif-agent-mandate-problem states requirements and
> deliberately proposes no mechanism, so if Mission-Bound meets them it
> belongs there as related work rather than as an alternative. That
> revision is held on an unrelated question in RATS; when it moves, that
> is the change it carries.
> 
> Mohamad Khalil-Yossif
> 
>   draft-yossif-psea
>   https://datatracker.ietf.org/doc/draft-yossif-psea/
>   draft-yossif-agent-mandate-problem
>   https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
>   draft-yossif-enrollment-problem
>   https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/