I-D Action: draft-schrock-ep-authorization-receipts-10.txt

Internet-Draft draft-schrock-ep-authorization-receipts-10.txt is now
available.

   Title:   Authorization Receipts for High-Risk Agent Actions
   Author:  Iman Schrock
   Name:    draft-schrock-ep-authorization-receipts-10.txt
   Pages:   42
   Dates:   2026-08-06

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,
   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 names the detailed receipt profile EP-AUTHORIZATION-
   RECEIPT-v1, requires a pinned CAID mapping profile whenever a relying
   party compares the action across artifact formats, and defines an
   optional presentation-binding profile with fail-closed display-
   unbound, display-mismatch, and display-untrusted results.
   Presentation evidence binds profile-defined disclosure bytes; it does
   not establish comprehension or an uncompromised physical display
   path.

   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-10.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-schrock-ep-authorization-receipts-10

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]