Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals

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

Table of Contents

1. 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, 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 [IDCOMMITS] for the handle tier taxonomy and 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. The optional pre-send enforcement gate (Section 10) integrates with the agent-runtime governance flow of [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. This memo specifies bilateral Accords only.¶

2. 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. alter:~example.com). Each party to an Accord is represented by one substrate.¶

Sovereign-tier handle

A principal identity handle in the Sovereign tier of the handle taxonomy of [IDCOMMITS] (e.g. alter:~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.¶

Content address

A SHA-256 hash that identifies a document by its bytes. The content address of an Accord is the SHA-256 of the canonicalised Accord payload (Section 6).¶

Identity log

The append-only log kept by a party's identity substrate. The events of Section 11 are recorded in it, and an identitylog_entry descriptor (Section 6) refers to an entry in it.¶

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 6. 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 10) 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.¶

Where this memo names a substrate or a principal in prose, the identifier is an alter: URI as defined in [ALTER-URI], for example alter:~example.com or alter:~alice. A handle carried as a wire-format value (parties[].handle, principal_handle, delegate_handle, log_handle, the tool arguments of Section 9 and the parties field of Section 7.2) keeps the bare form that field defines; the value ~alice corresponds to the URI alter:~alice.¶

3. Architectural Overview

The protocol comprises five composed layers, each addressable independently:¶

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

2. Sovereign signing (Section 5). 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].¶

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 6). 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 9 and 10). 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. Layer 5 (Sections 9 and 10) is an optional implementation surface and may be omitted by parties whose use of the protocol does not extend to agent-runtime-mediated execution.¶

4. 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 other bilateral types registered in Section 14.1.¶

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

accord_id (text string, REQUIRED)

A UUIDv4 assigned at ceremony commencement. Identifies the Accord within each party's records and in the disclosure ledger.¶

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 [IDCOMMITS] (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. a national company number or tax identifier). 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 5.2).¶

legal_entity and entity_registry_id are self-asserted by the party they describe. No step of the Section 7.3 verification walkthrough, and no other normative passage in this memo, checks either field against anything external; a relying party requiring assurance of the counterparty's legal identity obtains it by out-of-band means (an existing business relationship or an independent registry lookup).¶

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

• 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, [RFC3339] 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. "AU-NSW").¶

• exclusive_forum (text string, OPTIONAL).¶

tamper_evidence_descriptors (CBOR array, REQUIRED, length >= 2)

An array of descriptors per Section 6. 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.¶

5. Signing

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

• 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 14.2).¶

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

7. Discovery

8. 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. Accords SHOULD reference the registry version they extend and SHOULD declare per-Accord additions or restrictions explicitly.¶

9. MCP Tool Surface (Optional)

Substrates MAY expose the following MCP tools to authenticated agent runtimes of recognised members, so that a runtime can take part in the 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.¶

`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).¶

10. 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:¶

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-for-confirmation, or allow-with-audit per [ORGPOLICY] Section 5).¶

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

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

12. Revocation

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

1. The revoking party publishes an 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.¶

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 10) 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.¶

13. Discovery, Identity, and Trust-Tier Composition

The Accord protocol composes with the companion memos listed in Section 17 as follows.¶

14. IANA Considerations

This memo requests that IANA establish two registries and register one media type.¶

15. Security Considerations

16. Privacy Considerations

17. Relation to Companion Memos

This memo composes with three companion 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.¶

[IDCOMMITS] supplies the handle trust-tier taxonomy. Sovereign-tier handles are the authoritative signatories of an Accord. No new tier is introduced. [IDCOMMITS] also 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 10 layers above the per-runtime gate set of [ORGPOLICY] Section 5 under a strictest-applicable composition rule.¶

18. Implementation Status

An implementation of the bilateral Accord ceremony is in development. No claim of interoperability is made. This section is to be removed before publication as an RFC, per [RFC7942].¶

19. Document History

draft-morrison-identity-accord-04 (October 2026):¶

• Corrects internal section references in Sections 2, 3, 8, 13.3, 15.4 and 15.5.¶

• Defines content address and identity log in Section 2, writes the two signatures of Section 3 as signatures, and drops from Section 7.3 the statement that a verifier needs no access to any substrate operator.¶

• Updates the references to [MCPDNS] -09, [IDCOMMITS] -04, [ORGPOLICY] -06 and [ALTER-URI] -05. The sections cited in them are unchanged.¶

• Attributes the Sovereign tier to the handle taxonomy of [IDCOMMITS] and removes the Identity Pronouns reference, which this memo does not use.¶

• Cites the companion memos as Internet-Drafts and adds the [RFC3339], [RFC4033], [RFC6838], [RFC7858], [RFC7942], [RFC8126] and [RFC8484] references. Section 5.1 cites [RFC9338] instead of [RFC9052] for counter-signature semantics.¶

• States that substrates and principals named in prose are alter: URIs [ALTER-URI]. Wire-format handle values are unchanged.¶

• Removes the forward pointers to successor drafts in Sections 1 and 5.2 and removes the Multi-Party Anticipation subsection.¶

• Moves revision notes out of the protocol text: the rename of sth_anchor to onchain_anchor_ref in an earlier revision, and the account of the Cross-Substrate Audit Fan-Out recorded under -03 below.¶

• Section 13.3 names the [ORGPOLICY] Section 8 rule it applies, the strictest-applicable enforcement-gate composition rule, which is distinct from the withdrawn audit fan-out.¶

• Section 10 uses the [ORGPOLICY] Section 5 action names prompt-for-confirmation and allow-with-audit.¶

• Completes the media type registration template.¶

• Adds a privacy note on the officers' handles carried by the Accord discovery record, and an informative citation of [MORRISON-IFT] in Section 16.4.¶

• Replaces the Implementation Status text, removes the Acknowledgements and the duplicated Author's Address, and tightens prose throughout.¶

• No change to the wire format, the ceremony, the signature medium, the disclosure ledger, the IANA registry entries, or any BCP 14 requirement.¶

draft-morrison-identity-accord-03 (August 2026):¶

• Withdraws the Cross-Substrate Audit Fan-Out subsection of the Privacy Considerations and replaces it with Identity-Binding Leakage, which prohibits disclosing a party's binding to any substrate that is not a party to the Accord.¶

• Removes the dependency on the [ORGPOLICY] Section 8 fan-out, which that memo withdraws in its revision -03.¶

• No change to the ceremony, the signature medium, the disclosure ledger, the trust-tier composition, or the IANA position.¶

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

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

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

[RFC9338]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/info/rfc9338>.

[MCPDNS]

Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 8 October 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09>.

[IDCOMMITS]

Morrison, B., "Identity-Attributed Git Commits via Tier-Structured Trailers", Work in Progress, Internet-Draft, draft-morrison-identity-attributed-commits-04, 8 October 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-identity-attributed-commits-04>.

[ORGPOLICY]

Morrison, B., "Policy Provision and Governance Inheritance from an Organisational Identity Substrate", Work in Progress, Internet-Draft, draft-morrison-org-alter-policy-provision-06, 10 October 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-org-alter-policy-provision-06>.

21. Informative References

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

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

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[ALTER-URI]

Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme-05, 8 October 2026, <https://datatracker.ietf.org/doc/html/draft-morrison-alter-uri-scheme-05>.

[MORRISON-IFT]

Morrison, B., "Identity Field Theory: Toward a Physics of Being Known", 2026, <https://doi.org/10.6084/m9.figshare.31951383>.

Authors' Addresses