



Network Working Group                                        B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Informational                               18 May 2026
Expires: 19 November 2026


   Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements
              Between Identity-Substrate-Bound Principals
                   draft-morrison-identity-accord-01

Abstract

   This memo specifies the Identity Accord Protocol, a peer ceremony by
   which two principals, each represented by an organisational identity
   substrate and acting under a recorded delegation from a legal entity,
   execute a bilateral agreement as a portable, self-verifying COSE-
   signed CBOR document.  The protocol composes DNS-based substrate
   discovery, Ed25519 sovereign signatures, an append-only identity log,
   and a tamper-evidence descriptor quorum into a single artefact that
   is verifiable by any third party with access to the public DNS, the
   parties' identity logs, and an on-chain anchor of the agreement's
   content hash.  The protocol does not require a central registry, a
   designated verifier, or any infrastructure operated by the
   specification's author; verification succeeds when the author's
   reference deployment is offline.  The canonical bilateral target is a
   mutual non-disclosure agreement, but the wire format generalises to
   any bilateral consent envelope between two legal entities each
   represented by an identity substrate.  An associated MCP tool
   surface, an associated pre-send enforcement gate, and an associated
   disclosure-ledger schema are specified, all of which are optional
   layers above the wire format.  The memo is Informational; the
   underlying COSE and CBOR formats are normative per [RFC9052] and
   [RFC8949].

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



Morrison                Expires 19 November 2026                [Page 1]

Internet-Draft               Identity Accord                    May 2026


   This Internet-Draft will expire on 19 November 2026.

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.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   5
   5.  Wire Format . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Signing . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Sovereign Signature . . . . . . . . . . . . . . . . . . .   8
     6.2.  Delegation Instrument . . . . . . . . . . . . . . . . . .   9
   7.  Tamper-Evidence Descriptor Quorum . . . . . . . . . . . . . .  10
   8.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Substrate Discovery . . . . . . . . . . . . . . . . . . .  11
     8.2.  Accord Discovery  . . . . . . . . . . . . . . . . . . . .  12
     8.3.  Third-Party Verification Walkthrough  . . . . . . . . . .  12
   9.  Topic Taxonomy  . . . . . . . . . . . . . . . . . . . . . . .  13
   10. MCP Tool Surface (Optional) . . . . . . . . . . . . . . . . .  13
   11. Pre-Send Enforcement Gate (Optional)  . . . . . . . . . . . .  14
   12. Disclosure Ledger . . . . . . . . . . . . . . . . . . . . . .  16
   13. Revocation  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   14. Discovery, Identity, and Trust-Tier Composition . . . . . . .  17
     14.1.  With Substrate Discovery . . . . . . . . . . . . . . . .  17
     14.2.  With Handle Tier Semantics . . . . . . . . . . . . . . .  17
     14.3.  With Org-Alter Policy Provision  . . . . . . . . . . . .  17
     14.4.  Multi-Party Anticipation . . . . . . . . . . . . . . . .  18
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     15.1.  Accord Types Registry  . . . . . . . . . . . . . . . . .  18
     15.2.  Tamper-Evidence Descriptor Types Registry  . . . . . . .  18
     15.3.  MCP Tool Surface Names . . . . . . . . . . . . . . . . .  19
     15.4.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  19
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  20
     16.1.  Sovereign-Key Compromise . . . . . . . . . . . . . . . .  20
     16.2.  Descriptor-Quorum Subversion . . . . . . . . . . . . . .  20
     16.3.  Delegation-Instrument Replay . . . . . . . . . . . . . .  21
     16.4.  Enforcement-Gate Bypass  . . . . . . . . . . . . . . . .  21



Morrison                Expires 19 November 2026                [Page 2]

Internet-Draft               Identity Accord                    May 2026


     16.5.  Classifier Adversarial Inputs  . . . . . . . . . . . . .  21
   17. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
     17.1.  Content Confidentiality  . . . . . . . . . . . . . . . .  22
     17.2.  Disclosure-Ledger Privacy  . . . . . . . . . . . . . . .  22
     17.3.  Third-Party Verification Privacy . . . . . . . . . . . .  22
     17.4.  Cross-Substrate Audit Fan-Out  . . . . . . . . . . . . .  23
   18. Relation to Companion Memos . . . . . . . . . . . . . . . . .  23
   19. Implementation Status . . . . . . . . . . . . . . . . . . . .  23
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     20.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

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

2.  Introduction

   A bilateral agreement between two organisations is, in current
   commercial practice, a document drafted by either party's legal
   counsel, signed by an authorised officer of each party, exchanged by
   email or by a third-party signature platform, and stored in each
   party's document-management system.  The agreement's existence, its
   terms, and its lifecycle events (execution, amendment, revocation,
   expiry) are not directly verifiable by any third party; they are
   matters between the parties and their records.  A third party who
   needs to verify that an agreement is in force may, at best, request a
   copy from one of the parties.

   This memo specifies a different arrangement.  Two principals, each
   representing a legal entity and each bound to an organisational
   identity substrate, execute the agreement as a portable self-
   verifying document.  The document carries the contract text, the
   parties' identities, the delegations under which the principals sign,



Morrison                Expires 19 November 2026                [Page 3]

Internet-Draft               Identity Accord                    May 2026


   the agreement's term and jurisdiction, and a set of tamper-evidence
   descriptors anchored in independent substrates.  A third party who
   receives the document, or who resolves the agreement's content
   address through public discovery, can verify the agreement's
   authenticity and lifecycle status against the public DNS, the
   parties' identity logs, and any on-chain anchor the descriptors
   reference.  No party holds an authoritative copy that the other party
   lacks; the agreement is symmetric.

   The protocol composes with [MCPDNS] for substrate discovery, with
   [IDPRONOUNS] for the principal-handle namespace, with [IDCOMMITS] for
   the attribution grammar that names the authorising officer, and with
   [ORGPOLICY] for the policy stack under which the agreement is
   admitted to the parties' agent-runtime sessions.  An associated pre-
   send enforcement gate (Section 9) integrates with the agent- runtime
   governance flow specified by [ORGPOLICY] so that an agreement's
   permitted-purpose scope can be applied to outbound tool invocations
   of either party's runtimes.

   The canonical bilateral target of the v0 specification is a mutual
   non-disclosure agreement.  The wire format generalises to any
   bilateral consent envelope: master services agreements, data
   processing agreements, statements of work, reseller agreements,
   partnership letters.  Multi-party extensions (three or more parties)
   are out of scope for this version and are anticipated for a successor
   draft.

3.  Conventions and Definitions

   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.

   The following terms are defined for the purposes of this document.

   Accord  A bilateral agreement executed under the protocol of this
      memo.  The wire-format artefact is the Accord document; the act of
      reaching mutual signature is the Accord ceremony.

   Identity substrate  An organisational identity primitive of the kind
      specified by [ORGPOLICY], addressable by a domain-qualified handle
      (e.g. ~example.com).  Each party to an Accord is represented by
      one substrate.

   Sovereign-tier handle  A principal identity handle in the Sovereign




Morrison                Expires 19 November 2026                [Page 4]

Internet-Draft               Identity Accord                    May 2026


      trust tier of [IDPRONOUNS] (e.g. ~alice).  An authorised officer
      of a legal entity signs an Accord under their Sovereign-tier
      handle.

   Delegation instrument  A recorded, bounded, revocable, content-
      addressed assertion by the authorising officer of a party that a
      named handle (the delegate) is authorised to execute a specified
      Accord on the party's behalf.  The delegation instrument is itself
      a COSE-signed CBOR document and is included by content address in
      the Accord payload.

   Tamper-evidence descriptor  A pointer to an independent substrate
      against which the Accord's content address is anchored.  The
      minimum descriptor set is defined in Section 7.  A verifier
      requires a substrate-defined quorum of descriptors to consider the
      Accord tamper-evident.

   Permitted purpose  A natural-language paragraph in the Accord payload
      that defines the scope of disclosures permitted under the
      agreement.  The permitted-purpose paragraph is legally
      authoritative; the structured topic taxonomy of Section 8 is a
      deterministic runtime classifier and is subordinate to the
      permitted-purpose prose in any conflict.

   Topic taxonomy  A structured tag list, scoped to the Accord,
      identifying the topics on which disclosures are permitted,
      blocked, or require explicit consent.  The taxonomy is operative
      for runtime gating (Section 9) and is informative for legal
      interpretation.

   Disclosure-ledger event  A typed signed event written to an Accord
      party's identity log recording a permitted disclosure, a blocked
      attempt, an amendment, a revocation, or an expiry.  Events carry
      metadata and content hashes only; they do not carry the disclosed
      content.

4.  Architectural Overview

   The protocol comprises five composed layers, each addressable
   independently:

   1.  *Wire format* (Section 5).  A COSE-signed CBOR document carrying
       the Accord payload, with two counter-signatures (one per party).

   2.  *Sovereign signing* (Section 6).  Each party's signature is
       produced by an Ed25519 sovereign key associated with the
       authorising officer's ~handle, with the signature carried in a
       COSE_Sign or COSE_Sign1 envelope per [RFC9052].



Morrison                Expires 19 November 2026                [Page 5]

Internet-Draft               Identity Accord                    May 2026


   3.  *Discovery* (Section 7).  The Accord is publicly discoverable via
       a content-addressed DNS TXT record under each party's substrate
       zone, complementing the existing _alter.<domain> record of
       [MCPDNS].

   4.  *Tamper-evidence descriptor quorum* (Section 8).  Each party
       contributes descriptors anchoring the Accord's content address in
       independent substrates: per-party identity log, on-chain anchor,
       public DNS record.  A verifier requires a quorum sufficient for
       the policy under which the verifier operates.

   5.  *MCP tool surface and enforcement* (Sections 10 and 11).  An
       optional MCP tool surface allows agent runtimes of either party
       to participate in the ceremony, query Accord state, and record
       disclosure events.  An optional pre-send enforcement gate applies
       the Accord's topic taxonomy to outbound tool invocations of
       either party's runtimes.

   Layers 1 through 4 are required for any conformant Accord.  Layers 10
   and 11 are optional implementation surfaces and may be omitted by
   parties whose use of the protocol does not extend to agent-runtime-
   mediated execution.

5.  Wire Format

   An Accord is a CBOR object [RFC8949] carrying the Accord payload,
   wrapped in a COSE signature envelope [RFC9052].

   The Accord payload is a CBOR map with the following keys.

   version (text string, REQUIRED)  The wire-format version.  v0 of this
      specification uses the literal "identity-accord-v0".

   accord_type (text string, REQUIRED)  A token identifying the
      agreement type.  Recognised values for v0:

      *  mutual-nda-v2 for the canonical mutual non-disclosure target.

      *  msa-v1, dpa-v1, sow-v1, reseller-v1, partnership-v1 for the
         additional bilateral types this memo anticipates.

      Additional values MAY be registered in the IANA Accord Types
      registry (Section 13).

   accord_id (text string, REQUIRED)  A UUIDv4 assigned at ceremony
      commencement.  Identifies the Accord within each party's records
      and in the disclosure ledger.




Morrison                Expires 19 November 2026                [Page 6]

Internet-Draft               Identity Accord                    May 2026


   contract_body (CBOR map, REQUIRED)  The contract text and its content
      address.

      *  text (text string): the UTF-8 contract body.  Legally
         authoritative.

      *  content_address (byte string): the SHA-256 hash of the UTF-8
         text.  Verifiers MUST recompute and compare.

   parties (CBOR array, REQUIRED, length 2)  One entry per party.  Each
      entry is a CBOR map:

      *  role (text string): one of party_a, party_b.

      *  handle (text string): the authorising officer's Sovereign- tier
         handle per [IDPRONOUNS] (e.g. ~alice).

      *  legal_entity (text string): the registered name of the party's
         legal entity.

      *  entity_registry_id (text string): the entity's registry
         identifier (e.g. ACN, EIN, company number).  Format is
         jurisdiction-specific.

      *  sovereign_pubkey (byte string): the Ed25519 public key against
         which the party's signature verifies.

      *  delegation_ref (byte string): the content address of the
         delegation instrument (Section 6.2).

   permitted_purpose (CBOR map, REQUIRED)  The agreement's scope.

      *  text (text string): the natural-language permitted-purpose
         paragraph.  Legally authoritative in any conflict.

      *  hash (byte string): SHA-256 of the UTF-8 text.

   topic_taxonomy (CBOR map, OPTIONAL)  The structured tag list for
      runtime gating.

      *  version (text string): the taxonomy version identifier (e.g.
         "v1").

      *  permitted_tags (array of text strings): topic tags on which
         disclosure is permitted.

      *  blocked_tags (array of text strings): topic tags on which
         disclosure is refused.



Morrison                Expires 19 November 2026                [Page 7]

Internet-Draft               Identity Accord                    May 2026


      *  escalation_tags (array of text strings, OPTIONAL): topic tags
         that require explicit consent from the disclosing principal at
         disclosure time.

      *  nl_authority_anchor (byte string): the hash of
         permitted_purpose.text, binding the taxonomy to its natural-
         language source.

   term (CBOR map, REQUIRED)  Lifecycle parameters.

      *  effective_date (text string, RFC 3339 timestamp)

      *  initial_term_days (unsigned integer)

      *  ordinary_survival_days (unsigned integer, optional)

      *  categorical_survival (CBOR map, optional): per-category
         survival rules, where the keys are category identifiers (e.g.
         trade_secret, personal_information) and the values are either
         an unsigned integer day-count or the literal "indefinite".

   jurisdiction (CBOR map, REQUIRED)  Governing law and forum.

      *  governing_law (text string): jurisdiction identifier (e.g.
         "NSW, Australia").

      *  exclusive_forum (text string, OPTIONAL).

   tamper_evidence_descriptors (CBOR array, REQUIRED, length >= 2)  An
      array of descriptors per Section 7.  Each descriptor is a CBOR map
      with a type key and type-specific fields.

   The Accord payload is canonicalised per the deterministic CBOR
   encoding rules of [RFC8949] Section 4.2 before signing.  Verifiers
   MUST canonicalise before recomputing content addresses or verifying
   signatures.

6.  Signing

6.1.  Sovereign Signature

   Each party signs the canonicalised Accord payload with the Ed25519
   private key associated with the Sovereign-tier handle named in the
   party's entry.  Signatures are carried in a COSE envelope per
   [RFC9052]:

   *  For ceremonies completed in a single co-signing event, a COSE_Sign
      envelope with two signatures is REQUIRED.



Morrison                Expires 19 November 2026                [Page 8]

Internet-Draft               Identity Accord                    May 2026


   *  For ceremonies completed in two stages (party A signs and
      publishes; party B counter-signs from the published artefact),
      each stage MAY emit a COSE_Sign1 envelope and a counter- signature
      MAY be added later per [RFC9052] counter-signature semantics.
      Verifiers MUST treat the combined two-signature envelope as
      authoritative; a single-signature artefact is a draft, not an
      Accord.

   The signature's protected header SHALL carry:

   *  alg: EdDSA (RFC 8032).

   *  content type: application/identity-accord+cbor.

   *  kid: the content address of the Accord payload.

   The signature's unprotected header MAY carry implementation- specific
   metadata; verifiers MUST NOT rely on unprotected-header fields for
   authenticity.

6.2.  Delegation Instrument

   Each parties[].delegation_ref resolves to a delegation instrument: a
   separate COSE-signed CBOR document, signed by the party's Sovereign-
   tier handle, that names the authorised signatory of the present
   Accord and bounds the delegation's scope.

   The delegation instrument's payload is a CBOR map with keys:

   *  version (text string): "identity-accord-delegation-v0".

   *  principal_handle (text string): the Sovereign-tier handle granting
      the delegation.

   *  delegate_handle (text string): the handle authorised to act.  In
      v0, the delegate handle MUST equal the principal handle;
      Sovereign-to-Instrument delegation is anticipated for a successor
      draft.

   *  delegated_accord_id (text string): the accord_id of the present
      Accord.

   *  scope (text string): a natural-language description of the scope
      of the delegation (e.g. "execution of the present Accord and any
      amendments to it").

   *  inception (text string, RFC 3339): start of the delegation
      validity window.



Morrison                Expires 19 November 2026                [Page 9]

Internet-Draft               Identity Accord                    May 2026


   *  expiry (text string, RFC 3339, OPTIONAL): end of the delegation
      validity window; absent implies no expiry beyond the Accord's own
      term.

   *  revocation_commitment (byte string): the hash of a revocation
      token; revocation is effected by publishing the preimage to the
      principal's identity log.

   Verifiers MUST resolve each delegation instrument from its content
   address, verify its signature against the principal handle's
   sovereign key, and verify that the delegation's delegated_accord_id
   equals the Accord's accord_id.

7.  Tamper-Evidence Descriptor Quorum

   Each party contributes one or more tamper-evidence descriptors to the
   Accord's tamper_evidence_descriptors array.  Descriptors anchor the
   Accord's content address (the SHA-256 of the canonicalised Accord
   payload) in an independent substrate.

   The minimum descriptor types for v0:

   identitylog_entry  A reference to an event in a party's append-only
      identity log, the event recording the Accord's content address at
      execution.

      *  party (text string): party_a or party_b.

      *  log_handle (text string): the substrate handle whose log
         carries the entry.

      *  entry_id (text string): the log entry identifier.

      *  signature (byte string): the log's signature over the entry.

   onchain_anchor  A reference to a transaction on a public blockchain
      whose payload anchors the Accord's content address (typically via
      inclusion in a Signed Tree Head of a per-substrate Merkle log
      inspired by [RFC6962]).

      *  chain (text string): chain identifier (e.g. "base",
         "ethereum").

      *  block (unsigned integer): block number.

      *  tx (byte string): transaction hash.





Morrison                Expires 19 November 2026               [Page 10]

Internet-Draft               Identity Accord                    May 2026


      *  sth_root (byte string): the Merkle root including the Accord's
         content address.

   dns_txt_record  A reference to a DNS TXT record under a party's
      substrate zone whose value is the Accord's content address.

      *  domain (text string): the fully-qualified domain name of the
         TXT record (typically _agreement.<content-address-
         base32>._alter.<party-domain>).

      *  record_value (text string): the TXT record's value encoding the
         content address.

      The TXT record SHOULD be DNSSEC-validated [RFC4033] per the
      practice established by [MCPDNS].

   wellknown_artefact  A reference to a content-addressed artefact
      published at a party's well-known URI per [RFC8615].

      *  url (text string): the fully-qualified URL of the well-known
         resource.

      *  expected_hash (byte string): SHA-256 of the resource body.

   Additional descriptor types MAY be registered in the IANA Tamper-
   Evidence Descriptor Types registry (Section 13).

   A descriptor quorum is sufficient when at least two descriptors of
   independent type and independent substrate operator have been
   verified.  Implementations SHOULD treat a quorum of one type, or a
   quorum of two descriptors operated by the same substrate operator, as
   INSUFFICIENT and refuse to admit the Accord as tamper-evident.
   Substrate operators SHOULD publish the quorum policy they apply.

   Graceful degradation is REQUIRED, meaning parties without access to
   the full descriptor set SHOULD participate at the minimum-conformant
   quorum rather than be excluded.

8.  Discovery

8.1.  Substrate Discovery

   Each party SHALL publish the existence and metadata of its identity
   substrate under the _alter.<domain> DNS TXT scheme of [MCPDNS].
   Substrate discovery for the Accord protocol reuses [MCPDNS] without
   modification.





Morrison                Expires 19 November 2026               [Page 11]

Internet-Draft               Identity Accord                    May 2026


8.2.  Accord Discovery

   The existence of an Accord MAY be advertised by each party under a
   content-addressed sub-record:

   _agreement.<content-address-base32>._alter.<party-domain>

   The record's value is a TXT carrying:

   *  content_address: the base32 encoding of the SHA-256 content
      address.

   *  accord_type: the value of the Accord payload's accord_type field.

   *  effective_date: the effective date in RFC 3339.

   *  expiry: the expected expiry timestamp in RFC 3339, computed from
      effective_date + initial_term_days.

   *  parties: a comma-separated pair of Sovereign-tier handles (e.g.
      ~alice,~bob) for human readability.

   *  sth_anchor (OPTIONAL): a reference to an on-chain anchor per the
      onchain_anchor descriptor type.

   Implementations SHOULD treat absence of an Accord discovery record as
   orthogonal to Accord validity; parties MAY execute a private Accord
   (with dns_txt_record descriptors omitted) and distribute the Accord
   artefact directly out of band.  An Accord without DNS discovery still
   verifies against the descriptor quorum if at least two non-DNS
   descriptors are present.

8.3.  Third-Party Verification Walkthrough

   A third party who receives an Accord artefact and a content address
   performs the following verification:

   1.  Canonicalise the Accord payload per [RFC8949] and recompute the
       SHA-256 content address.  Compare to the provided value.

   2.  For each party in parties:

       *  Resolve the party's _alter.<domain> per [MCPDNS].

       *  Verify the party's sovereign_pubkey against the public
          envelope published under [MCPDNS].





Morrison                Expires 19 November 2026               [Page 12]

Internet-Draft               Identity Accord                    May 2026


       *  Resolve the delegation_ref content address and verify the
          delegation instrument per Section 6.2.

   3.  Verify the COSE signatures against each party's sovereign_pubkey.

   4.  Verify the descriptor quorum per Section 7.

   5.  For each party, query the party's identity log for any
       accord_revoked event referencing the Accord's content address.
       Refuse to admit a revoked Accord.

   6.  Confirm the Accord has not expired against term.

   A third-party verifier requires no access to ALTER infrastructure or
   to either party's private systems beyond the public DNS, the public
   identity logs, and the on-chain anchor.

9.  Topic Taxonomy

   The optional topic_taxonomy field of the Accord payload provides a
   deterministic runtime classifier of the agreement's permitted scope.
   Taxonomy tags are short structured identifiers (e.g.
   engineering.architecture, finance.revenue, personnel.salaries) drawn
   from a substrate-published canonical registry or from a per-Accord
   extension thereof.

   The taxonomy is informative for legal interpretation and operative
   for runtime gating.  In the event of a conflict between the topic
   taxonomy and the permitted-purpose paragraph, the natural-language
   paragraph prevails per Section 4 (permitted_purpose.text legally
   authoritative).

   Substrate operators SHOULD publish a canonical topic-taxonomy
   registry at a stable URL under their substrate zone (typical
   location: https://registry.<substrate-domain>/topic-taxonomy/v1).
   Accords SHOULD reference the registry version they extend and SHOULD
   declare per-Accord additions or restrictions explicitly.

10.  MCP Tool Surface (Optional)

   Substrates MAY expose the following MCP tool surface to authenticated
   agent runtimes of recognised members, enabling runtime participation
   in Accord ceremony and lifecycle.

   begin_agreement(counterparty_handle, accord_type)  Creates a draft
      Accord between the calling party and a counterparty handle.
      Returns an accord_draft_id.




Morrison                Expires 19 November 2026               [Page 13]

Internet-Draft               Identity Accord                    May 2026


   `propose_terms(accord_draft_id, contract_content_address,

   permitted_purpose, topic_taxonomy, term, jurisdiction,

   delegation_ref)`  Populates the draft with proposed terms.

   accept_terms(accord_draft_id)  Counterparty's acceptance; moves the
      draft to a signing-ready state.

   sign_accord(accord_draft_id, sovereign_signature)  Attaches an
      Ed25519 signature from the authorising officer's Sovereign-tier
      handle.

   publish_tamper_evidence(accord_id, descriptor_set)  Emits tamper-
      evidence descriptors to the substrate's identity log, to on-chain
      anchors, and to DNS as configured.

   query_accord_status(accord_id_or_content_address)  Returns the
      Accord's lifecycle state (draft, executed, active, revoked,
      expired) and the descriptor set.  Available to any caller who
      knows the content address; no privileged authentication is
      required for this read.

   revoke_accord(accord_id, reason)  Either party MAY invoke; triggers
      return-or-destruction obligations and emits agreement_revoked to
      the identity log.

   `record_disclosure(accord_id, recipient_handle, topic_tags,

   content_hash, size, method)`  Records a permitted disclosure to the
      disclosure ledger.

   record_scope_violation(accord_id, attempted_tags, reason)  Records a
      blocked disclosure attempt for audit.

   The MCP tool names above SHALL be registered in the MCP Tool Surface
   Names registry referenced in [ORGPOLICY] (or a successor
   specification establishing said registry).

11.  Pre-Send Enforcement Gate (Optional)

   A party MAY operate a pre-send enforcement gate that intercepts
   outbound tool invocations from the party's agent runtimes and
   classifies the invocation's payload against the topic taxonomies of
   any active Accords binding the calling principal to the recipient
   principal.

   The gate algorithm:



Morrison                Expires 19 November 2026               [Page 14]

Internet-Draft               Identity Accord                    May 2026


   1.  For each prospective outbound tool invocation:

       *  Resolve the recipient handle from the invocation's arguments.

       *  Look up any active Accord whose parties set includes the
          caller and the recipient.

       *  If no active Accord exists between the parties, the gate does
          not apply; the invocation proceeds per the runtime's default
          policy (which may be block, prompt, or allow per the runtime's
          enforcement-gate specification of [ORGPOLICY]).

   2.  For each active Accord:

       *  Classify the invocation's payload into a set of topic tags
          using a substrate-defined classifier.  The classifier MAY
          combine a fast-path structured matcher on payload metadata
          with a slow-path model-based classifier on payload content.

       *  Compare the classified tag set to the Accord's permitted_tags,
          blocked_tags, and escalation_tags.

   3.  Take action:

       *  If the classified set lies entirely within permitted_tags,
          emit a disclosure_recorded event and allow the invocation.

       *  If the classified set intersects blocked_tags, emit a
          scope_violation_blocked event and refuse the invocation with a
          structured error.

       *  If the classified set intersects escalation_tags, present a
          confirmation prompt to the Sovereign-tier principal and
          proceed only on confirmation.

       *  If classification is ambiguous, fail closed: refuse the
          invocation and emit scope_violation_blocked with the ambiguity
          flagged.

   Disclosure-ledger events are written to the calling party's identity
   log under the event types of Section 11.

   The enforcement gate is composable with the per-runtime enforcement-
   gate specification of [ORGPOLICY]: an outbound invocation MUST
   satisfy both the party's runtime gates and any applicable Accord
   gates.  Where both apply, the more restrictive action prevails.





Morrison                Expires 19 November 2026               [Page 15]

Internet-Draft               Identity Accord                    May 2026


12.  Disclosure Ledger

   Each party SHALL maintain, in its identity log, the following event
   types under the agreement scope:

   agreement_executed  Emitted by both parties on ceremony completion.
      Payload: the Accord's content address, the descriptor quorum, and
      the signing handle.

   disclosure_recorded  Emitted per permitted outbound disclosure.
      Payload: the Accord's content address, the recipient handle, the
      topic tag set, the content hash, the size in bytes, the method
      (tool name).  Content is NEVER included; only the hash.

   scope_violation_blocked  Emitted per blocked disclosure attempt.
      Payload: the Accord's content address, the attempted topic tag
      set, the block reason.

   agreement_amended  Emitted on negotiated amendment of an Accord.
      Payload: the prior and successor content addresses, the diff hash,
      and the authorising signatures of both parties.

   agreement_revoked  Emitted on revocation by either party.  Payload:
      the Accord's content address, the revoking party, the reason, the
      revocation token preimage.

   agreement_expired  Emitted on term expiry.  Payload: the Accord's
      content address and the expiry timestamp.

   Each party's identity log SHOULD be cross-anchored to the
   counterparty's log via periodic hash-chain exchange so that both
   parties hold matching event subsets for the agreement.  Cross-
   anchoring is a substrate-side concern and is not specified here
   beyond the requirement that each party's log is verifiable
   independently.

13.  Revocation

   Either party MAY revoke an Accord at any time during its term.
   Revocation:

   1.  The revoking party publishes a agreement_revoked event to its
       identity log carrying the revocation token preimage.

   2.  The substrate emits a notification to the counterparty's
       subscription channel for the Accord.





Morrison                Expires 19 November 2026               [Page 16]

Internet-Draft               Identity Accord                    May 2026


   3.  The counterparty's substrate records the receipt in its own
       identity log under agreement_revoked with the cross- reference to
       the originating event.

   4.  Any pre-send enforcement gate (Section 9) ceases admitting the
       Accord; subsequent outbound invocations between the parties
       default to the runtime's no-Accord policy.

   5.  Return-or-destruction obligations under the contract body take
       effect per the contract's terms.  The protocol records the
       lifecycle event; the contract specifies the substantive
       obligations.

   Revocation is not retractable.  A re-executed agreement between the
   same parties on the same subject matter is a new Accord with a new
   accord_id and a new content address.

14.  Discovery, Identity, and Trust-Tier Composition

   The Accord protocol composes with the broader Morrison-family
   identity architecture as follows.

14.1.  With Substrate Discovery

   The _alter.<domain> TXT scheme of [MCPDNS] supplies both parties'
   substrate endpoints, signing keys, and capability profiles.  Accord-
   specific records under _agreement.<content-address>._alter.<domain>
   extend the same zone without creating a new label namespace.

14.2.  With Handle Tier Semantics

   Sovereign-tier handles per [IDPRONOUNS] are the only tier authorised
   to sign an Accord in v0.  Instrument-tier handles MAY participate in
   the ceremony surfaces (Section 10) under Sovereign-tier delegation
   per [IDCOMMITS] attribution (Acted-By: is the Sovereign signer;
   Drafted-With: may name the Instrument that drafted the contract
   body), but the authoritative signature is always Sovereign-tier.

14.3.  With Org-Alter Policy Provision

   When either party operates an agent runtime under the policy-
   provision flow of [ORGPOLICY], any active Accord adds an enforcement-
   gate composition layer above the substrate's default policy stack.
   The composition rule of Section 9 applies in addition to the
   strictest-applicable rule of [ORGPOLICY] Section 8.






Morrison                Expires 19 November 2026               [Page 17]

Internet-Draft               Identity Accord                    May 2026


14.4.  Multi-Party Anticipation

   This memo specifies bilateral Accords only.  An N-party Accord (N >
   2) requires N-way signature collection, an N-way descriptor quorum,
   and a generalised topic-taxonomy composition rule.  These extensions
   are anticipated for a successor draft and are explicitly out of scope
   here.

15.  IANA Considerations

   This memo requests that IANA establish two registries.

15.1.  Accord Types Registry

   A registry of accord_type values for the wire-format field of
   Section 5.  Initial entries:

    +================+===============+================================+
    | accord_type    | reference     | description                    |
    +================+===============+================================+
    | mutual-nda-v2  | this document | Mutual non-disclosure          |
    |                |               | agreement, v2 template family. |
    +----------------+---------------+--------------------------------+
    | msa-v1         | this document | Master services agreement.     |
    +----------------+---------------+--------------------------------+
    | dpa-v1         | this document | Data processing agreement.     |
    +----------------+---------------+--------------------------------+
    | sow-v1         | this document | Statement of work.             |
    +----------------+---------------+--------------------------------+
    | reseller-v1    | this document | Reseller agreement.            |
    +----------------+---------------+--------------------------------+
    | partnership-v1 | this document | Partnership letter.            |
    +----------------+---------------+--------------------------------+

                                  Table 1

   Registration policy: Specification Required.  New accord_type values
   are registered by Internet-Draft or by an RFC defining the contract-
   body shape and any type-specific protocol extensions.

15.2.  Tamper-Evidence Descriptor Types Registry

   A registry of tamper_evidence_descriptors[].type values for
   Section 7.  Initial entries:







Morrison                Expires 19 November 2026               [Page 18]

Internet-Draft               Identity Accord                    May 2026


    +====================+===========+===============================+
    | type               | reference | description                   |
    +====================+===========+===============================+
    | identitylog_entry  | this      | Reference to an event in a    |
    |                    | document  | party's append-only identity  |
    |                    |           | log.                          |
    +--------------------+-----------+-------------------------------+
    | onchain_anchor     | this      | Reference to a transaction on |
    |                    | document  | a public blockchain anchoring |
    |                    |           | the content address.          |
    +--------------------+-----------+-------------------------------+
    | dns_txt_record     | this      | Reference to a DNS TXT record |
    |                    | document  | bearing the content address.  |
    +--------------------+-----------+-------------------------------+
    | wellknown_artefact | this      | Reference to a well-known URI |
    |                    | document  | artefact bearing the content  |
    |                    |           | address.                      |
    +--------------------+-----------+-------------------------------+

                                 Table 2

   Registration policy: Specification Required.  New descriptor types
   are registered by Internet-Draft or RFC defining the descriptor
   fields and the verification procedure.

15.3.  MCP Tool Surface Names

   The MCP tool surface names of Section 10 (begin_agreement,
   propose_terms, accept_terms, sign_accord, publish_tamper_evidence,
   query_accord_status, revoke_accord, record_disclosure,
   record_scope_violation) are registered in the MCP Tool Surface Names
   registry referenced in [ORGPOLICY].  Establishment of that registry,
   if not already done, is the subject of [ORGPOLICY]'s IANA
   Considerations.

15.4.  Media Type

   This memo requests registration of the media type application/
   identity-accord+cbor per RFC 6838, with the following information:

   *  Type name: application

   *  Subtype name: identity-accord+cbor

   *  Required parameters: none

   *  Optional parameters: version (the value of the Accord payload's
      version field).



Morrison                Expires 19 November 2026               [Page 19]

Internet-Draft               Identity Accord                    May 2026


   *  Encoding considerations: binary; deterministic CBOR per [RFC8949]
      Section 4.2.

   *  Security considerations: see Section 14 of this document.

   *  Interoperability considerations: see Section 5 of this document.

   *  Published specification: this document.

16.  Security Considerations

16.1.  Sovereign-Key Compromise

   An Accord's authenticity rests on the Sovereign-tier handle's Ed25519
   signing key.  Compromise of either party's signing key permits an
   attacker to forge new Accords under the party's identity, or to forge
   revocations of existing Accords.  Mitigations:

   *  Sovereign-tier signing keys SHOULD be held in hardware-backed
      custody (HSM, secure enclave, hardware security token) and SHOULD
      NOT be exported in plaintext under any circumstances.

   *  The handle's published envelope per [MCPDNS] is the canonical
      pubkey; a compromised key SHALL be rotated by publishing a new
      envelope and recording the rotation in the substrate's identity
      log.  Verifiers SHOULD check whether the signing key recorded in
      the Accord was the current key at the time of the Accord's
      effective date.

   *  Tamper-evidence descriptors anchored at the time of execution
      defend the Accord against post-hoc forgery by anchoring the
      content address in substrates the attacker does not control.

16.2.  Descriptor-Quorum Subversion

   An attacker controlling one substrate party may attempt to publish
   descriptors anchoring a falsified Accord content address.
   Mitigations:

   *  The quorum policy of Section 7 requires descriptors of independent
      type and independent substrate operator.  An attacker controlling
      a single substrate cannot satisfy the quorum alone.

   *  On-chain anchors SHOULD reference chains the attacker does not
      control; well-known artefacts SHOULD be hosted under the party's
      verifiable substrate zone, not under an attacker- controllable
      third party.




Morrison                Expires 19 November 2026               [Page 20]

Internet-Draft               Identity Accord                    May 2026


   *  Verifiers SHOULD compare independent descriptors against each
      other; descriptors anchoring conflicting content addresses for the
      same Accord ID are evidence of an attempted forgery.

16.3.  Delegation-Instrument Replay

   A revoked delegation instrument, if its revocation has not been
   propagated, may be replayed to forge new signatures.  Mitigations:

   *  Delegation revocations SHALL be recorded in the principal's
      identity log under a typed event before any reliance on the
      delegation is admitted.

   *  Verifiers SHALL check the principal's identity log for any
      revocation event referencing the delegation's content address
      before treating the delegation as valid.

   *  Delegation expiry timestamps SHOULD be set conservatively; a
      delegation that outlives the Accord's effective scope is an
      unnecessary liability.

16.4.  Enforcement-Gate Bypass

   A party operating the pre-send enforcement gate of Section 9 may have
   its gate bypassed by a runtime that does not source its policy from
   the substrate per [ORGPOLICY].  Mitigations:

   *  Parties SHOULD configure all agent runtimes bound to the party's
      identity to operate under [ORGPOLICY] policy provision.

   *  Outbound tool invocations from non-conformant runtimes SHOULD be
      detected by the substrate's audit-signal flow and the disclosure-
      ledger comparison SHOULD reveal the divergence.

   *  Outbound network traffic from non-conformant runtimes is outside
      the scope of this memo; the Accord's enforcement posture is a
      protocol layer, not a perimeter control.

16.5.  Classifier Adversarial Inputs

   The pre-send enforcement gate's topic-tag classifier may be
   adversarially manipulated through crafted payloads that evade
   classification or that classify into permitted tags spuriously.
   Mitigations:

   *  The classifier's ambiguity threshold SHOULD be conservative;
      ambiguous classifications SHALL fail closed per Section 9.




Morrison                Expires 19 November 2026               [Page 21]

Internet-Draft               Identity Accord                    May 2026


   *  The classifier's structured fast-path SHOULD operate on payload
      metadata under cryptographic integrity binding, not solely on
      payload content susceptible to crafting.

   *  Periodic adversarial-payload rehearsal of the classifier is
      RECOMMENDED.

17.  Privacy Considerations

17.1.  Content Confidentiality

   The Accord's contract body MAY contain confidential terms; the Accord
   wire format preserves the body's confidentiality only to the extent
   that the artefact is not published.  Parties wishing to retain
   content confidentiality SHOULD:

   *  Omit the dns_txt_record and wellknown_artefact descriptors,
      retaining only identitylog_entry and onchain_anchor (which record
      content addresses, not content).

   *  Distribute the artefact directly between the parties, out of band
      of the public substrate surface.

17.2.  Disclosure-Ledger Privacy

   Events under the disclosure ledger of Section 11 record content
   hashes, recipient handles, and topic-tag sets.  An adversary with
   access to a party's identity log can observe disclosure patterns even
   without access to disclosed content.  Mitigations:

   *  Identity logs MAY be encrypted at rest; the cross-anchor hash-
      chain exchange between parties' logs does not require exposing log
      contents.

   *  Recipient handles in disclosure events SHOULD be pseudonymous
      where the substrate permits; the Accord's permitted-purpose scope
      binds the disclosure regardless of recipient pseudonymity.

17.3.  Third-Party Verification Privacy

   A third-party verifier accessing public discovery records and on-
   chain anchors leaves network and chain-observation footprints.  Such
   verifiers SHOULD operate over privacy- preserving DNS (DNS over HTTPS
   or DNS over TLS) and SHOULD treat their verification queries as
   potentially observable.






Morrison                Expires 19 November 2026               [Page 22]

Internet-Draft               Identity Accord                    May 2026


17.4.  Cross-Substrate Audit Fan-Out

   Where an outbound tool invocation between Accord parties involves a
   third substrate (e.g. a tool whose execution is mediated by a third
   party), the disclosure-ledger event is written to all participating
   substrates per the audit fan-out of [ORGPOLICY] Section 8.  Parties
   SHOULD declare in their permitted-purpose paragraph any third-
   substrate involvement so that fan-out is anticipated rather than
   incidental.

18.  Relation to Companion Memos

   This memo composes with five Morrison-family Internet-Drafts.

   [MCPDNS] supplies substrate discovery (_alter.<domain> TXT scheme)
   and the cryptographic identity envelope that publishes each party's
   Sovereign-tier signing key.  The Accord protocol does not introduce
   new DNS labels except as content-addressed sub-records under the
   existing _alter. zone.

   [IDPRONOUNS] supplies the handle namespace and trust-tier taxonomy.
   Sovereign-tier handles are the authoritative signatories of an
   Accord.  No new tier is introduced.

   [IDCOMMITS] supplies the attribution grammar used by the optional MCP
   tool surface and by Accord-adjacent git commits recording amendment
   activity.  The Accord protocol's parties[].handle field corresponds
   semantically to the Acted-By: trailer slot of [IDCOMMITS].

   [ORGPOLICY] supplies the agent-runtime policy provision flow into
   which the Accord's enforcement gate composes.  The Accord gate of
   Section 9 layers above the per-runtime gate set of [ORGPOLICY]
   Section 5 under a strictest-applicable composition rule.

   The substrate-observation posture of the companion substrate-
   observation memo (the present author's prior I-D) is not directly
   invoked by the Accord protocol but is a sibling posture: both rest on
   the principle that bilateral and multilateral coordination problems
   benefit from substrate- physics commitments rather than from
   canonical-broker arbitration.

19.  Implementation Status

   A reference implementation of the bilateral Accord ceremony is in
   active development by the specification's author.  Initial ceremony
   targets are private; post-ceremony case studies are anticipated as
   the public artefacts of this work.




Morrison                Expires 19 November 2026               [Page 23]

Internet-Draft               Identity Accord                    May 2026


   In the spirit of [RFC7942], the present author notes that this
   section documents implementation intent and is expected to be removed
   before the document advances beyond the Independent Stream.  No claim
   of interoperability is made; the reference deployment is a single
   substrate operated by the specification's author with a single
   anticipated counterparty.

20.  References

20.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.





Morrison                Expires 19 November 2026               [Page 24]

Internet-Draft               Identity Accord                    May 2026


   [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
              via DNS TXT Records", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
              discovery/>.

   [IDPRONOUNS]
              Morrison, B., "Identity Pronouns: A Reference-Axis
              Extension to ~handle Identity Systems", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              pronouns/>.

   [IDCOMMITS]
              Morrison, B., "Identity-Attributed Git Commits via Tier-
              Structured Trailers", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              attributed-commits/>.

   [ORGPOLICY]
              Morrison, B., "Org-Alter-Mediated Policy Provision and
              Governance Inheritance for Agent Runtimes Bound to a
              Principal Identity", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-org-
              alter-policy-provision/>.

20.2.  Informative References

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC8615-WK]
              "Well-Known URIs", 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

Acknowledgements

   This memo grew out of internal architectural work on the question of
   how two organisations, each represented by an identity substrate, can
   execute a bilateral agreement as a self-verifying portable artefact
   without recourse to a central registry, a third-party signature
   platform, or any infrastructure operated by either party's vendor.
   The realisation that the agreement substrate, the identity substrate,
   and the audit substrate are the same substrate, and that this



Morrison                Expires 19 November 2026               [Page 25]

Internet-Draft               Identity Accord                    May 2026


   collapse is what makes a third-party signature platform structurally
   redundant between parties who hold their own identity logs, is the
   load-bearing insight behind this specification.

Author's Address

   Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com

Author's Address

   Blake Morrison
   Alter Meridian Pty Ltd
   Email: blake@truealter.com






































Morrison                Expires 19 November 2026               [Page 26]
