Reliance Agreements: Signed Liability Terms Conditioned on Authorization-Evidence Sufficiency

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 4 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Authorization Receipts [I-D.schrock-ep-authorization-receipts] can carry one action-bound approval artifact. AEC [I-D.schrock-ep-aec] evaluates whether independently verified and action-matched evidence fills a relying-party requirement. AEB [I-D.schrock-aeb] makes the separate local authorization, custody, invocation, and reconciliation decisions. None of those layers should silently invent the terms under which another party agrees to rely on the result.¶

This document defines a narrow interchange object. A Reliance Agreement is a signed, portable, offline-verifiable statement by named parties: if the evidence presented for an action in this scope satisfies the reliance profile identified here by digest, then these liability terms (a liability shift or an indemnity, with caps, currency, and deductible) apply between us, in this window. A Reliance Event is the per-action record that a specific relying party relied, for a specific action digest, on a specific evidence verdict, under a specific agreement. Together they make the commitment and the reliance non-repudiable and portable. They deliberately do not make either enforceable; see Section 5.¶

2. The Reliance Agreement (EP-RELIANCE-AGREEMENT-v1)

A Reliance Agreement is a JSON object. Its signable payload is the object without the signatures member, serialized with JSON Canonicalization Scheme (JCS) [RFC8785] and prefixed with the domain-separation string "EP-RELIANCE-AGREEMENT-v1" followed by a single NUL octet. Every signature in the signatures array is an Ed25519 [RFC8032] signature over those exact bytes.¶

{
  "version": "EP-RELIANCE-AGREEMENT-v1",
  "agreement_id": "ra:example-issuer:example-bank:2026-001",
  "parties": {
    "issuer":        { "id": "ep:org:example-issuer",
                       "key_id": "ep:key:issuer-1" },
    "relying_party": { "id": "ep:org:example-bank",
                       "key_id": "ep:key:rp-1" },
    "underwriter":   { "id": "ep:org:example-underwriter",
                       "key_id": "ep:key:uw-1" }
  },
  "required_signers": ["issuer", "relying_party", "underwriter"],
  "scope": {
    "action_families": ["wire_transfer", "ach_credit"],
    "jurisdictions": ["US-NY"],
    "validity": { "not_before": "2026-01-01T00:00:00Z",
                  "not_after":  "2027-01-01T00:00:00Z" }
  },
  "condition": {
    "reliance_profile_digest": "sha256:<64 hex>",
    "min_assurance_class": "V",
    "max_staleness_sec": 300
  },
  "terms": {
    "mode": "indemnity",
    "cap_amount": "1000000.00",
    "currency": "USD",
    "per_action_cap": "250000.00",
    "aggregate_cap": "1000000.00",
    "deductible": "10000.00"
  },
  "recourse_ref": "https://example.com/master-agreement#annex-b",
  "signatures": [
    { "party": "issuer", "algorithm": "Ed25519",
      "key_id": "ep:key:issuer-1", "signature_b64u": "..." },
    { "party": "relying_party", "algorithm": "Ed25519",
      "key_id": "ep:key:rp-1", "signature_b64u": "..." },
    { "party": "underwriter", "algorithm": "Ed25519",
      "key_id": "ep:key:uw-1", "signature_b64u": "..." }
  ]
}

3. The Reliance Event (EP-RELIANCE-EVENT-v1)

A Reliance Event is the per-action claim instrument: the relying party's signed record that, at a stated time, it relied on a specific evidence verdict for a specific action under a specific agreement. Its signable payload is the object without the signature member, JCS-canonicalized and prefixed with "EP-RELIANCE-EVENT-v1" followed by a single NUL octet, signed Ed25519 by the agreement's relying party.¶

{
  "version": "EP-RELIANCE-EVENT-v1",
  "event_id": "rev:example-bank:2026-07-08:0001",
  "agreement_digest": "sha256:<64 hex>",
  "action_digest": "sha256:<64 hex>",
  "reliance_result_digest": "sha256:<64 hex>",
  "relied_at": "2026-07-08T11:59:00Z",
  "signature": { "party": "relying_party", "algorithm": "Ed25519",
                 "signature_b64u": "..." }
}

agreement_digest is the sha256 digest of the agreement's domain-prefixed canonical payload (signatures excluded). action_digest is the digest of the canonical action relied on, the same digest the evidence stack binds receipts and verdicts to. reliance_result_digest is the sha256 digest of the JCS-canonical reliance result record. The result record MUST carry the action_digest it attests and the action_family of the action, and MAY carry the digest of the profile it was evaluated under and the verdict itself. relied_at is the time of reliance and MUST fall inside the agreement's validity window.¶

The three digests are the point of the object: the event joins one action, one evidence verdict, and one set of agreed terms by digest, so that no party can later substitute a different verdict, a different action, or a different version of the terms into the record of what happened.¶

4. Verification

Verification is offline, deterministic, and fail-closed: any check that cannot be completed, any unknown vocabulary value, and any malformed field yields a refusal with a stated reason, never an exception and never a permissive default.¶

Agreement verification proceeds in order: (1) structure, with all closed vocabularies (party roles, required_signers, terms mode, assurance class) and the amounts-as-strings rule enforced; (2) canonical form, computing the exact domain-prefixed JCS bytes every signature covers; (3) the validity window against verification time; (4) signatures: every role in required_signers MUST have exactly one signature entry, every signature present (required or not) MUST verify under the key pinned for that party's key_id, and a missing pin is a refusal, not a skip.¶

Event verification proceeds in order: (1) event structure, including digest formats and a relied_at that is parseable and not in the future of verification time; (2) the referenced agreement MUST verify, with the validity window evaluated at relied_at, so the question answered is "was the agreement effective when reliance occurred", not "is it effective now"; (3) the event's agreement_digest MUST equal the digest computed over the supplied agreement; (4) the event's action_digest MUST equal the action digest the supplied reliance result attests, and the reliance_result_digest MUST equal the digest computed over the supplied result; (5) the result's action family MUST be inside the agreement scope, and when the result names the profile it was evaluated under, that digest MUST equal the agreement's condition.reliance_profile_digest; (6) the event signature MUST verify under the pinned key of the agreement's relying party. A signature by any other party, however valid, MUST be refused: the claim instrument is meaningful only from the party that bore the decision.¶

Event verification binds; it does not re-judge. Whether the verdict inside the reliance result is honest is established by replaying the evidence against the profile the agreement pins by digest, using the evidence machinery of [I-D.schrock-ep-aec] and the separate admission controls of [I-D.schrock-aeb]; this document's verifier proves only that the claimed verdict, the claimed action, and the agreed terms are the ones bound together.¶

5. What This Object Is and Is Not

Implementations MUST preserve the claim boundaries in this section in user interfaces and machine-readable verification results.¶

A Reliance Agreement is the machine-readable EXPRESSION of a reliance agreement, not a substitute for contract law. It is designed to be incorporated by reference into a prose master agreement, in the same way an ETSI signature policy [ETSI-TS-119-172-1] or an eIDAS trust-service practice statement gives a machine-checkable core its legal force through the surrounding prose instrument. The recourse_ref field exists exactly for that incorporation; a deployment that signs the object without a governing prose agreement has produced evidence of intent, not a contract, and should know the difference.¶

Verifying the object proves WHO agreed (the pinned keys of the named parties), to WHAT terms (mode, caps, currency, window, scope), over WHICH evidence conditions (the profile digest and assurance floor). It does not prove that any party will honor the terms, that the terms are enforceable in any jurisdiction, that the caps are funded, or that a court or arbitrator will read the object the way its signers did. Enforceability is jurisdiction-dependent and out of scope for this document.¶

A satisfied condition is not an automatic payout. The agreement conditions liability terms on evidence sufficiency; it does not adjudicate causation, loss quantum, exclusions, or fraud by the relying party itself. Those live in the prose instrument and its forum. What the objects contribute to that forum is structure: a non-repudiable record of the terms, the evidence condition, the verdict relied on, and the moment of reliance, each bound by digest.¶

A Reliance Event records reliance; it does not create entitlement. An event that verifies proves the relying party claimed, under its own signature, to have relied on a specific verdict for a specific action while the agreement was effective. Whether that reliance was reasonable, whether the verdict was honestly computed, and whether the loss claimed flows from the action are questions for the evidence replay and the forum, in that order.¶

6. Relationship to Existing Work

Rules languages. LegalRuleML [LegalRuleML] and the Accord Project's template model [Accord] are substrates in which the semantics of an agreement like this one could be expressed: LegalRuleML as a formal rule interchange for legal norms, Accord as executable natural-language contract templates. This document deliberately defines the minimal interoperable OBJECT, not a rules language: three party roles, a digest-referenced evidence condition, a closed two-mode term vocabulary, string amounts, and multi-party signatures over canonical bytes. A deployment that needs richer clause logic can express it in those substrates and still exchange this object as the interoperable core both sides verify.¶

The four-corner precedent. The closest historical precedent is the IdenTrust (Identrus) four-corner model of the early 2000s: banks issued identity certificates, relying banks obtained structured warranty messaging around reliance on those certificates, and liability flowed through operating rules written in prose. It demonstrated that structured, bank-grade reliance messaging is buildable and commercially wanted; it was also proprietary, closed to one federation, and is defunct as a scheme. This document is the open-standard version of that lesson: the warranty-shaped object survives the federation that first needed it only if anyone can implement and verify it.¶

Verifiable Credentials. The W3C Verifiable Credentials data model [VC-DATA-MODEL] defines a termsOfUse property as a generic extension point on credentials and presentations. It carries no liability semantics: no party roles, no caps, no evidence condition, no effectiveness rule. A VC deployment could carry a Reliance Agreement digest inside termsOfUse, but the agreement object itself, with its own multi-party signatures, is what this document defines and what termsOfUse lacks.¶

The EP evidence stack. Authorization receipts [I-D.schrock-ep-authorization-receipts] supply the action-bound human approval; AEC [I-D.schrock-ep-aec] computes evidence sufficiency; and AEB [I-D.schrock-aeb] owns the consequence-admission decision and lifecycle. This document adds no evidence type, authorization verdict, or execution transition. It records signed terms and one party's action-bound act of reliance.¶

7. Security Considerations

Dishonor. An agreement object cannot prevent a party from dishonoring it. What it changes is the dispute: the commitment, the evidence condition, the verdict, and the moment of reliance are each signed or digest-bound, so dishonor becomes attributable and the record is portable to whatever forum the prose master agreement names. The object converts "we never agreed to that" from a factual dispute into a cryptographic one.¶

Caps are claims, not escrow. cap_amount and its siblings are signed statements of intent about financial exposure. Nothing in this document funds, reserves, or escrows them, and a verifier MUST NOT present a verified agreement as proof of ability to pay.¶

Insurance and legal status. A verified underwriter signature is not an insurance policy, binder, certificate, or proof of coverage. A verified agreement does not establish that a term is lawful or enforceable, that a loss falls within coverage, that a party caused the loss, or that any party must pay. Implementations MUST present these objects as signed inputs to legal and commercial processes, not as their outputs.¶

Key compromise. A compromised signer key forges commitments: an attacker holding the issuer key can sign agreements the issuer never made, and one holding the relying-party key can fabricate reliance events. Deployments MUST treat agreement-signing keys with the same lifecycle discipline as receipt-signing keys, including revocation statements; a verifier presented with a revocation covering a signer key has a refusal reason, not a judgment call. Rotation is why parties carry a key_id rather than inline key material: the pin set is the verifier's own trust decision, made out of band.¶

Digest substitution. The three digests in a reliance event are only as good as the canonicalization they are computed over. Both objects use JCS [RFC8785] with domain-separation prefixes, so an agreement digest can never collide with an event digest over the same bytes, and a reliance result is bound byte-for-byte, not field-by-field. Verifiers MUST recompute every digest from supplied objects and MUST NOT accept a digest match asserted by any party.¶

Scope laundering. The event verifier refuses a result whose action family is outside the agreement scope, and refuses a result evaluated under a profile other than the one the agreement pins when the result names its profile. It cannot detect a result that omits its profile digest and was computed under a weaker profile; deployments whose results omit the profile digest have chosen to establish that binding by replay instead, and should document that choice. The fail-closed floor remains: a result naming no action family at all is refused, never waved through.¶

Amounts. Monetary amounts are decimal strings and a JSON number is refused outright. This is a security posture, not pedantry: silent binary floating-point conversion of a liability cap is an integrity failure that surfaces only at claim time, which is the worst possible moment to discover it.¶

8. IANA Considerations

A future revision will register the media types application/ep-reliance-agreement+json and application/ep-reliance-event+json. This revision requests no IANA action.¶

Appendix A. Implementation Status

A reference implementation is published Apache-2.0 in the EMILIA Protocol repository (packages/verify/src/reliance-agreement.ts): a pure, offline, fail-closed verifier for both objects (verifyRelianceAgreement, verifyRelianceEvent) with no dependency beyond the platform crypto library, plus signing helpers. A conformance suite of sixteen vectors (conformance/vectors/reliance-agreement.v1.json, exercised by tests/reliance-agreement.test.ts) covers the happy paths for both objects and the refusals specified here: a missing required signature, an expired or not-yet-effective window, a cap amount tampered after signing, a cap amount expressed as a JSON number, an unknown terms mode, an unpinned required-signer key, a required signer the agreement never declared, an event bound to a different agreement digest, an event signed by a party other than the relying party, a result attesting a different action, an action family outside the agreement scope, a result altered after the event bound it, reliance outside the agreement window, and a result evaluated under a different profile than the agreement pins.¶

Author's Address