@techreport{schrock-ep-authorization-receipts-09,
    number =    {draft-schrock-ep-authorization-receipts-09},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/09/},
    author =    {Iman Schrock},
    title =     {{Authorization Receipts for High-Risk Agent Actions}},
    pagetotal = 37,
    year =      2026,
    month =     aug,
    day =       3,
    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. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. Section 10.7 of {[}I-D.klrc-aiagent-auth{]} states that an agent MUST NOT treat local UI confirmation alone as sufficient authorization, and notes that additional specification or design work may be needed for user confirmation occurring mid-execution, since CIBA accounts only for client initiation. This document defines one evidence artifact that an authorization architecture can use in such a 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.},
}