Internet-Draft Identity Evidence Binding October 2026
Morrison & Schrock Expires 25 April 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-morrison-schrock-identity-evidence-binding-00
Published:
Intended Status:
Informational
Expires:
Authors:
B. Morrison
Alter Meridian Pty Ltd
I. Schrock
EMILIA Protocol, Inc.

Identity Evidence for Approver Enrollment and Payee Destination Binding

Abstract

This document profiles how a relying party uses external identity evidence when it admits a consequential action, without that evidence ever standing in for permission. It defines two separate assertions, approver enrollment and payee destination binding, an authenticated binding from the exact evidence bytes to the action they support, offline status evidence with a freshness bound the relying party chooses, and the refusals that follow when any of it is missing. It applies to the pre-execution Authorization Bundle of EP Authorization Receipts and to the Command Authority Envelope for operational technology, and through the action digest to the Binding Moment Envelope.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 April 2027.

▲

Table of Contents

1. Introduction

A consequential action, a payment or a command to a physical process, is often approved by a human whose key is enrolled in a directory, and often pays someone whose account the system believes it knows. The receipt formats this document builds on already bind a human's signature to the exact action [EPRECEIPTS] and carry that approval to an enforcement point [OTCAE]. Neither says how a relying party should use outside evidence that the key belongs to the human the directory names, or that the destination belongs to the payee the action names.

This profile does that, under four constraints:

Out of scope: how identity is proofed, payment rails, settlement and whether a payment completed, federation between directories, and any payee that is an agent routing value to a sponsor (Appendix A).

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Identity authority:

A party a relying party trusts to say who a key or recipient belongs to. An approver directory under Section 5.2 of [EPRECEIPTS] is one.

Approver:

As in Section 2 of [OTCAE], a named human distinct from the initiating agent.

Payee:

The party a payment action names as recipient.

Destination:

The exact account, address or endpoint value that is paid, on a named rail or network.

Material payment parameters:

Every parameter of a payment action, other than its rail and destination, whose change would change what the approvers approved, such as the amount and currency. The action digest covers them.

Relying party:

The party that admits or refuses the action: an EP verifier, an authorisation server or policy decision point, or an OT enforcement point.

Evidence:

An assertion under Section 4 or Section 5, with the status evidence of Section 7 that describes it.

3. Formats

This profile defines no new encoding. Both assertions are JSON objects signed as JWS [RFC7515] in compact serialisation, with the payload in JCS canonical form [RFC8785]. They are profile-specific JWS payloads, not JWT Claims Sets. The relying party pins the accepted algorithms; this profile requires support for ES256 and EdDSA. Digests are SHA-256 over the exact JWS bytes, written sha256: followed by 64 lowercase hexadecimal characters, the form [EPRECEIPTS] uses. Times in this profile's own assertions are [RFC3339].

Status evidence is a Status List Token [TSL]. This version pins its JWT representation. That token keeps the NumericDate iat and exp of [TSL] and [RFC7519]; the RFC 3339 rule above does not apply to it.

An assertion and its status token are checked separately, under their respective native validation rules, including the assertions' audience checks and the status token's signer authority and list-reference binding. A valid status token does not revive an expired assertion.

4. Assertion A: Approver Enrollment

Says that an enrolled key belongs to a named human holding a role. It says nothing about whether this human may perform this action.

Table 1: Assertion A members
Member Content
profile ieb.approver-enrollment.v1
iss the identity authority
aud the relying-party scope the assertion is issued for
subject_ref a commitment to the human's stable identifier (Section 12)
key_jkt the JWK thumbprint of the enrolled approver key
role the role the authority asserts
proofing the identity-proofing method, by name
distinct_human_basis where a distinct-human requirement applies, the authority's identifier for the trusted mapping that tells two humans apart
iat, nbf, exp issue time and validity window
status a reference into a status list (Section 7)

A relying party checks Assertion A by verifying the JWS under an issuer key it selected, checking aud, checking status under Section 7, and checking that the approval's signing key has thumbprint key_jkt. It then checks the supplied reported signing time against the key's validity under the assertion, and separately that the deployment's status requirement is met at admission. Neither check establishes when the approval was signed, and one does not imply the other.

The signoff time is a reported time. The signed_at value of [EPRECEIPTS] sits outside the signed context, so it is not an authenticated assertion by the approver. The first check shows only that the supplied signed_at value falls within the assertion's validity window. This does not authenticate who supplied that value or when signing occurred. The relying party judges the assertion's current validity and status against its own trusted admission time (Section 7), in addition to the native checks of [EPRECEIPTS]. That judgement does not establish when a signature was made. Proof of a historical signing time needs separate authenticated evidence, and this profile does not define it. A reported past time MUST NOT rescue an expired or revoked enrollment.

Each approver whose signoff is counted needs their own Assertion A, bound to that signer's enrolled key. A valid enrollment for one signer never covers another.

Two different key_jkt or subject_ref values do not establish two different humans. Where [OTCAE] requires an approver distinct from the requester, the relying party establishes it from distinct_human_basis under the authority's trusted mapping, never from differing values.

5. Assertion B: Payee Destination Binding

Says that a destination on a named rail belongs to, or is routed for, an identified recipient.

Table 2: Assertion B members
Member Content
profile ieb.payee-destination.v1
iss the identity authority
aud the relying-party scope
recipient_ref a commitment to the recipient's stable identifier (Section 12)
recipient_kind human or organisation
rail the payment rail or network, by registered name
destination the exact destination in that rail's canonical representation
relationship one of ownership, control, authorized-routing
method the verification method, by name
verified_at when the authority completed that verification
iat, nbf, exp issue time and validity window
status a reference into a status list (Section 7)

The three relationships are not interchangeable. ownership means the recipient holds the account; control means the recipient can move value out of it; authorized-routing means the recipient has accepted, and the authority has verified, that value for them is routed to this destination. A relying party's policy names which relationships it accepts for which actions.

A relying party checks that the action's rail and destination equal rail and destination exactly, byte for byte in the canonical representation. Display-name similarity establishes nothing.

The relying party MUST also establish that the assertion's recipient is the payee identified by the signed action, using its independently selected identity mapping and any required authenticated commitment opening. A match of rail and destination alone is insufficient, since two recipients can share one collection or escrow destination. Per-assertion commitments are not stable identity identifiers, and different commitment values do not establish different recipients. An unavailable mapping does not satisfy the identity requirement.

A relying party with no online path to the identity authority obtains the opening in one of two ways. The presenter carries it with the evidence, disclosed confidentially to the intended relying party only, or the relying party holds the payee mapping in advance. Either way, the relying party checks it against the signed commitment and the action's actual payee. Missing or mismatched evidence MUST NOT satisfy admission.

6. Binding Evidence to the Action

6.1. The Binding Object

Evidence is bound to the action by an authorization_binding object in each Authorization Context, under Section 6.1 of [EPRECEIPTS]:

"authorization_binding": {
  "profile": "ieb.action-binding.v1",
  "evidence": [
    { "kind": "approver-enrollment",
      "digest": "sha256:<64 hex>" },
    { "kind": "payee-destination",
      "digest": "sha256:<64 hex>" }
  ],
  "status_digests": [ "sha256:<64 hex>" ]
}

The object sits inside the signed Authorization Context, so the approver's own signature covers the exact evidence bytes and the profile together. It adds no member to the closed bundle. Under Section 6.1 of [EPRECEIPTS] every context in one bundle carries the same byte-identical binding.

One binding therefore covers the whole bundle. It lists the Assertion A of every counted approver, and each approver signs over all of them. Every enrollment has to exist before the first signoff. Adding, removing or replacing an approver, or any approver's enrollment, changes the binding and requires new signoffs from every approver.

JCS does not reorder arrays. This profile fixes the order: evidence lists approver-enrollment entries before payee-destination entries, and within each kind sorts by digest in ascending byte order. status_digests sorts in ascending byte order. A repeated entry in either array is a binding failure.

The status snapshots named by the signed binding MUST remain available and unchanged. Replacing a digest in status_digests requires new signoffs. Admission MAY additionally use a newer authenticated status snapshot for the same assertion and list reference (Section 7), and that does not rewrite the approved binding.

6.2. Verification Before Admission

The relying party selects this profile independently; a presenter naming it does not select it. Then, before admission:

  1. it verifies each piece of evidence natively under Section 4, Section 5 and Section 7, against issuers it pinned;

  2. it derives the expected binding object from the evidence it verified and compares its JCS bytes with the presented object. A difference is a refusal;

  3. it checks the action digest the signoffs cover is the action it will admit, and, for a payment, that the action commits the rail, destination and material payment parameters, and that the recipient of Assertion B is the payee the action names (Section 5).

Native identity verification, action binding and admission policy are three separate results and are recorded separately. Passing the first two grants nothing.

6.3. Operational Technology

Under [OTCAE] the binding travels inside the Authorization Bundle that Section 3.4 of that document carries as the binding moment. The enforcement point verifies it with the bundle, offline, before dispatch.

6.4. Binding Moment Envelope

Each option of a Binding Moment Envelope carries its own action_digest (Section 5.6 of [BME]). Evidence about a payee attaches to the action an option names, so the evidence a principal relies on is the evidence for the option they select.

7. Status and Freshness

Each assertion's status member points into a Status List Token [TSL]. The presenter carries a signed Status List Token with the evidence, so admission works offline. An online fetch can supply a newer token. It is never the only way to satisfy status under [OTCAE].

The relying party sets a finite freshness bound for each assertion kind and each deployment. This profile sets no universal age, since a payment and an isolated plant differ.

The relying party MUST first validate the referenced assertion, then validate the Status List Token using the selected native [TSL] profile, including its type, signature and signer authority, the binding between the assertion's status-list reference and the token subject, and the referenced index and status value. It MUST enforce the token's expiration when present as well as the deployment's finite freshness limit, using a trusted time basis, and treats a token issued in the future as unusable. A longer local freshness limit does not extend the issuer's expiration. An unusable reference, unknown required status, or unavailable required verification input cannot satisfy admission policy.

The signed binding names the status snapshots the approvers saw (Section 6). Where admission uses a newer snapshot, the admission record distinguishes the signed snapshot from the newer one used for the admission decision and preserves both. The approver did not sign the newer token and the record does not say they did.

A status token proves status as of its stated time. It does not prove no revocation happened later.

8. Admission and Audit Records

The admission record is created and retained before dispatch. It holds the verified evidence digests, the exact status tokens used, signed and newer alike (Section 7), and the policy and freshness bound the relying party applied. Under [OTCAE] these go in the admission record of Section 3.5.

Once a terminal Trust Receipt exists under [EPRECEIPTS], a separately defined companion profile MAY bind that already-existing admission evidence to the complete receipt through an EP-RECEIPT-EXTENSIONS-v1 entry under Section 8 of that document. It MUST NOT reconstruct missing admission evidence afterward. The companion is an index, and the admission artifact itself is authenticated under trust the relying party selected and binds the fields Section 8 of [EPRECEIPTS] requires. This document proposes the name ieb.admission-evidence.v1 for that companion. Its artifact format, authentication, canonicalisation, operation semantics and checks are not yet defined. Until they are, it is a proposed extension and not an implemented one.

An outcome or reconciliation record may refer back to evidence recorded at admission. It is not where a pre-execution requirement is first satisfied, and it MUST NOT supply or replace evidence that was missing when the action was admitted.

9. Refusal

Required evidence that is absent, stale, revoked, from an untrusted issuer, for another audience, or mismatched with the action blocks admission under the relying party's policy. An unknown required profile or status value blocks it too; it never passes. A refusal names the assertion that failed and why, without echoing identity data.

The EP verification result stays separate from the admission decision. Where required verification or mapping is unavailable, the result is INDETERMINATE under Sections 6.1 and 6.2 of [EPRECEIPTS] and the action stays blocked. It is not relabelled REFUSE because neither result permits admission.

An independent safety function MUST NOT depend on this profile or on its availability, as Section 6 of [OTCAE] requires.

Identity evidence alone grants no permission, and proves neither that a payment is legitimate nor that it completed.

10. Test Vectors

The first four are proposed by this revision; none is yet a passing result. Each needs a verifier that checks the evidence natively under Section 4, Section 5 and Section 7, including the identity issuer's signature. Checking digests, contexts and joins alone does not authenticate an identity issuer.

A refusal vector in the table carries a repair-only control. That is the same input with only the faulty value repaired, and it shows the refusal comes from that fault alone.

Table 3: Proposed vectors
Vector Setup Expected
A-valid trusted issuer, current status, approval key thumbprint equals key_jkt, correct aud, signed binding identity checks pass; permission and execution stay separate
A-key-mismatch valid signed enrollment names a different key from the approval signer refuse; the repair-only control changes only the key binding
B-valid trusted issuer, current status, rail and destination equal the signed action or selected option, recipient is the payee the action names identity checks pass
B-destination-mismatch valid assertion binds destination X, the action pays Y refuse though both signatures verify; the repair-only control restores the exact destination

Before this profile is complete it also needs vectors for: stale status, revoked status, untrusted issuer, wrong audience, evidence-byte substitution, an unknown required profile, a status token describing a different assertion, a future status time, and two different keys or commitments for the same human where distinct humans are required.

These cases are proposed too, each expecting the action to be blocked or the binding to fail:

None of these vectors claims completed identity-profile support, independent interoperability, a successful payment or a physical effect.

11. Security Considerations

The identity authority is a trust root. A directory whose head is signed only by an operator key is operator assertion, as Section 5.2 of [EPRECEIPTS] already says, and Assertion A inherits that.

Binding by digest alone, beside an approval, lets an attacker pair valid evidence with a different action. The binding of Section 6 sits inside the signed context to stop that.

A destination match is exact. Normalising a destination differently at issue and at check is a substitution channel, so the rail's canonical representation is part of the profile and both sides use it.

12. Privacy Considerations

The signed native evidence stays available to authorised verifiers. Public registration is a separate projection with its own privacy review, and never a publication of the whole seam by default.

Stable human and recipient identifiers belong in access-controlled evidence, not in the public projection. subject_ref and recipient_ref are hiding, context-bound commitments: HMAC-SHA256 under a per-assertion random key of at least 128 bits, over a domain-separated, unambiguous encoding of the relying-party scope and the identifier. The key is secret opening material, not a public salt. The key and identifier are disclosed only to a verifier that needs the identity, under the deployment's access control. A deterministic hash of a guessable identifier does not conceal it. The input encoding is fixed before any test vector for these commitments is published.

Native signed action digests and measurements are never salted in place; any public commitment to them sits beside them.

A hiding principal reference does not hide a signing key, destination, exact timestamp or other identifier disclosed beside it. key_jkt repeats wherever the same approver key signs, and destination repeats for every payment to it. This profile does not promise anonymity.

13. IANA Considerations

This document has no IANA actions. The ieb. names are local to this document and are not an assignment made under Section 8.1 of [EPRECEIPTS]. A later revision may move them to a reversed DNS name.

14. Open Issues

  1. Whether ieb. names move to a reversed DNS name both authors control, under Section 8.1 of [EPRECEIPTS].

  2. Which rails get a canonical destination representation in -01, and where those representations are registered.

  3. Whether EdDSA stays mandatory to implement beside ES256.

  4. Commitment input encoding (Section 12). The domain-separated encoding of the relying-party scope and identifier under the HMAC is not yet fixed. It is fixed before any test vector for these commitments is published.

  5. ieb.admission-evidence.v1 (Section 8). The name is proposed only. Its artifact format, authentication, canonicalisation, operation semantics and checks are not yet defined, here or in a companion document.

15. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/info/rfc8785>.
[EPRECEIPTS]
Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-authorization-receipts-13, , <https://datatracker.ietf.org/doc/html/draft-schrock-ep-authorization-receipts-13>.
[TSL]
Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21>.

16. Informative References

[OTCAE]
Morrison, B., Whiteside, C., and I. Schrock, "Authorised and Attributable Agent Authority for Operational-Technology Control Actions", Work in Progress, Internet-Draft, draft-morrison-ot-command-authority-04, , <https://datatracker.ietf.org/doc/html/draft-morrison-ot-command-authority-04>.
[BME]
Morrison, B. and C. Whiteside, "The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation", Work in Progress, Internet-Draft, draft-morrison-binding-moment-envelope-04, , <https://datatracker.ietf.org/doc/html/draft-morrison-binding-moment-envelope-04>.

Appendix A. Extension: Routing to Someone Other than the Subject

This revision covers human and organisational recipients only. A named extension in a later revision covers a share paid to someone other than the subject: an agent's earnings routed to its sponsor, or value held in trust for a beneficiary. It needs a separate delegation and destination relationship, and the sponsor binding it would rest on is not yet checkable by anyone outside the operator. Agent identity is never evidence that a sponsor controls a destination.

Appendix B. Document History

Acknowledgments

None yet.

Contributors

Christopher Whiteside

Authors' Addresses

Blake Morrison
Alter Meridian Pty Ltd
Iman Schrock
EMILIA Protocol, Inc.
United States of America