I-D Action: draft-schrock-ep-authorization-receipts-11.txt
[email protected] Sun, 09 Aug 2026 23:55:19 -0700
| Newsgroups | gmane.ietf.announce |
|---|---|
| Message-ID | <178634491916.358887.1162248434862378535@dt-datatracker-559c48c7fb-9llwz> |
Internet-Draft draft-schrock-ep-authorization-receipts-11.txt is now available. Title: Authorization Receipts for High-Risk Agent Actions Author: Iman Schrock Name: draft-schrock-ep-authorization-receipts-11.txt Pages: 49 Dates: 2026-08-09 Abstract: This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-schrock-ep-authorization-receipts-11.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-schrock-ep-authorization-receipts-11 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ I-D-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]