]> Alter Meridian Pty Ltd

blake@truealter.com

EMILIA Protocol, Inc.

United States of America team@emiliaprotocol.ai

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.

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 and carry that approval to an enforcement point . 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:

• identity evidence never grants permission. A role is a claim by an identity authority, never a grant to perform this action;
• the relying party selects the issuers and profile it trusts. Anything only the presenter supplies establishes nothing;
• evidence is bound to the action before admission, by an authenticated binding over its exact bytes, never by a digest sitting beside an approval;
• no new members are added to any closed object. The binding uses the extension points those documents already define.

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 ().

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 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 is one.

Approver:

As in Section 2 of , 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 or , with the status evidence of that describes it.

Formats This profile defines no new encoding. Both assertions are JSON objects signed as JWS in compact serialisation, with the payload in JCS canonical form . 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 uses. Times in this profile's own assertions are . Status evidence is a Status List Token . This version pins its JWT representation. That token keeps the NumericDate iat and exp of and ; 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.

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. 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 ()
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 ()

A relying party checks Assertion A by verifying the JWS under an issuer key it selected, checking aud, checking status under , 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 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 (), in addition to the native checks of . 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 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.

Assertion B: Payee Destination Binding Says that a destination on a named rail belongs to, or is routed for, an identified recipient. 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 ()
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 ()

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.

Binding Evidence to the Action

The Binding Object Evidence is bound to the action by an authorization_binding object in each Authorization Context, under Section 6.1 of : " }, { "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 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 (), and that does not rewrite the approved binding.

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 , and , 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 ().

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

Operational Technology Under 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.

Binding Moment Envelope Each option of a Binding Moment Envelope carries its own action_digest (Section 5.6 of ). 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.

Status and Freshness Each assertion's status member points into a Status List Token . 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 . 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 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 (). 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.

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 (), and the policy and freshness bound the relying party applied. Under these go in the admission record of Section 3.5. Once a terminal Trust Receipt exists under , 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 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.

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 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 requires. Identity evidence alone grants no permission, and proves neither that a payment is legitimate nor that it completed.

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 , and , 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. 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:

• same rail and destination, but the assertion is for a different recipient: block;
• a valid enrollment for one signer supplied for a different counted signer: block;
• a recent status token whose exp has passed: block;
• a status token with a valid signature but the wrong list subject or index: block;
• the signed snapshot retained, and a newer valid snapshot for the same assertion reports it revoked: block admission without rewriting the original signature;
• a signed status digest replaced without new signoffs: binding validation fails.

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

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

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.

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 . A later revision may move them to a reversed DNS name.

Open Issues

1. Whether ieb. names move to a reversed DNS name both authors control, under Section 8.1 of .
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 (). 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 (). The name is proposed only. Its artifact format, authentication, canonicalisation, operation semantics and checks are not yet defined, here or in a companion document.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. EMILIA Protocol, Inc. Informative References

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.

Document History

• draft-morrison-schrock-identity-evidence-binding-00 (2026-10-21): first version, from the 16 October outline, Iman Schrock's review of it, his review of the 19 October working copy, Christopher Whiteside's review of the 20 October copy, Iman Schrock's 21 October wording for status token validation in Section 3, and his answers the same day on the signoff time, the offline commitment opening and the spelling of authorized-routing, and his 22 October wording for the reported signing time in Section 4.

Acknowledgments None yet.

Contributors

cwhiteside.engineering@gmail.com