> On 7 Oct 2026, Karl McGuinness wrote: whether parties downstream of the AS > need to verify the original instruction themselves
Karl, all, On your question to Blake: I think the party executing a high-consequence action should be able to verify the human's approval itself, not inherit it from the AS. What it can verify is what was shown, not the instruction behind it. That matches your boundary: "Neither anchor proves the Approver understood the rendered task". -00 §15.1 notes it "deliberately does not commit the rendered consent disclosure itself", and your editor's copy (§19.1.1) says Consent Evidence binds what the AS records, "not the presentation itself". OASNT, an individual Internet-Draft, addresses that per action, signed on the device that showed the disclosure, not by the party that recorded it: - dsp, a digest of the exact disclosure octets shown (core §6.3), alongside adg over the action (§6.2) - signed by the approver's enrolled device key, hardware-bound where the platform attests it (§8) - the executing party recomputes both from the action it is about to perform (§7) - the enforcement profile verifies, request-binds and consumes the token before forwarding (enforce §4, §5, §8); a proxy without the request-to-action mapping must not call that full verification (§5.1) This composes with a Mission rather than replacing it. The Mission bounds what an agent may ask for; an OASNT token is one form your fresh action-bound approval could take, checked against the parameter digest. Iman's AEB is the executor-side model such a token is designed to be consumed by (core §2.2). https://datatracker.ietf.org/doc/draft-thallapelly-oasnt/ https://datatracker.ietf.org/doc/draft-thallapelly-oasnt-enforce/ Glad to join the 26 October interim. Best, Arun _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
