[OAUTH-WG] Re: Standardizing a policy language

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

> Dapeng,
> 
> Apologies for the slow reply - your note arrived in the run-up to
> Vienna and I did not get back to it, which is my loss since I would
> have taken you up on the offer to talk there.
> 
> On the substance. The extension you describe - recording the
> complete evaluation input, the policy language type, and the
> specific policy evaluated, so an auditor can re-evaluate
> policy(input) and compare - is the right shape for the decision
> half of the problem, and I think it closes more than you claim for
> it.
> 
> The limit you name yourself is the one I would build on: it still
> trusts the RS to assemble the correct input. Your mitigations are
> the right ones - policies declaring required input fields, input
> sources signing their contributions, the RS committing to the input
> before evaluation - and the second of those is where I think the
> two lines of work meet. If input sources sign their contributions,
> then for any input field that asserts something about a human being
> present or approving, the signature that carries it has to come
> from the human's side rather than from a component the RS or the AS
> operates. Otherwise the input is self-asserted at exactly the field
> that matters most.
> 
> That is the piece draft-yossif-psea profiles: an EAT profile
> (RFC 9711) carrying a signature produced on the user's
> authenticator under a user-verification gate, bound to a canonical
> hash of the specific action payload. It is not an alternative to
> AS-signed evidence. Detached-JWS AS evidence establishes what the
> authorization server decided and observed; an authenticator-side
> proof establishes that a verified human approved these exact
> parameters. A record carrying both, joined to one action, answers a
> question neither answers alone - and it is verifiable by a party
> who trusts neither the RS nor the AS.
> 
> https://datatracker.ietf.org/doc/draft-yossif-psea/
> 
> Two things I would flag as genuinely unresolved rather than solved.
> 
> First, ordering. Both artifacts are signatures over the same
> action. Neither, by itself, establishes that the approval preceded
> the effect rather than ratifying it afterwards. For a re-evaluable
> audit record that distinction is load-bearing, and I do not think
> either of our drafts currently closes it.
> 
> Second, and this cuts across every proposal in this space including
> both of ours: a verifier resolves a public key to a named principal
> because of something enrollment guaranteed, and no current draft
> states what that something must be. Weak enrollment yields a
> mathematically sound proof about the wrong person, and nothing at
> the policy, evidence, or audit layer detects it. I have written the
> requirements up as a problem statement with no mechanism proposed:
> 
> https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/
> 
> I would value your read on it specifically, since your draft's
> threat model is the closest thing in this space to a stated
> position on what the AS is and is not trusted for.
> 
> Your point about profiles carrying the tradeoffs rather than the
> core binding mechanism seems right to me, and it is the same
> argument for keeping requirements separate from mechanism that
> Yaron was making about the language question.
> 
> Best,
> Mohamad Khalil-Yossif
> draft-yossif-psea