> 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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
