Hi Dapeng, Thanks, and I think the extension you describe is the right one. Recording the evaluation input, the policy language, and the evaluated policy so an auditor can re-run policy(input) and check the decision closes a real gap. It makes decision correctness verifiable rather than asserted. Worth doing.
I'd separate that from the second object in the requirement, because I think the two need different mechanisms. Re-evaluating policy(input) verifies the computation. It does not verify the party the decision was enforced for. The auditor confirms the AS computed the decision faithfully over the recorded input. Whether a specific principal was actually present and authentic is a claim carried inside that input, and re-evaluation takes it as given. This is the point you already name: the extension still trusts the RS to assemble the correct input. Your mitigations help with input integrity, and one of them points at the answer. Having input sources sign their contributions is the right shape. It yields independence only when the source signing the presence-and-identity contribution is the actor's own authenticator, holding a key the enforcement point cannot access. If that contribution originates at the RS or AS and is signed there, the result is a tamper-evident enforcement-point assertion, not evidence a relying party can verify independently of the enforcement point. Independence is a property of where the claim originates, not of the integrity protection applied after. So I'd state it as two verifiable objects on the evidence record. The decision, verifiable by re-evaluation, which your extension covers. And the presence and identity of the acting party, verifiable only when that field is signed outside the enforcement point's control. draft-yossif-psea profiles the second as an EAT-based artifact bound to the action payload, which fits the profile-level split you describe: the core binding as foundation, the requirements set per use case. I'll be at IETF 126 remotely rather than in person. Glad to continue this on the list, or directly if that's easier for you. Best, Mohamad > On 7 Jul 2026, at 12:56, 刘大鹏(鹏成) <[email protected]> > wrote: > > Dapeng Liu >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
