Internet-Draft IDDrop October 2026
van de Meent Expires 2 May 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-vandemeent-iddrop-01
Published:
Intended Status:
Standards Track
Expires:
Author:
J. van de Meent
Humotica

IDDrop: Identity Drop and Acceptance Protocol

Abstract

This document specifies IDDrop, an identity-transfer protocol for moving identity claims, actor claims, and receiver-bound claim bundles across human-facing and machine-facing environments.

IDDrop defines two complementary operating modes: offer-first, intended for proximity and human-in-the-loop workflows, and request-first, intended for autonomous systems, daemon-to-daemon exchange, and policy-driven machine identity transfer.

IDDrop does not treat filenames or user-visible extensions as identity truth. Instead, it binds identity transfer to sealed carrier truth, semantic classification, actor provenance, receiver targeting, and causal validation. It further requires that a change of the key bound to a known identity is never accepted as a side effect of a transfer, but only through an explicit, recorded decision. This document profiles the generic TIBET TAT handoff model for trustworthy identity transfer.

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 2 May 2027.

▲

Table of Contents

1. Introduction

Identity transfer in distributed systems is frequently underspecified. Systems often know how to transport bytes, but not how to safely transfer the meaning of an identity claim.

Existing encrypted transport systems provide confidentiality and integrity for byte carriage, but they do not by themselves answer whether the transferred object is an identity claim at all, whether the claim was expected or solicited, whether the visible name matches sealed semantics, whether the claim is bound to a known actor registry, or whether the response belongs to a known causal request chain.

A further question is easy to overlook: when a claim arrives for a name the receiver already knows, but bound to a different key, is this the same party on a new key, or a different party using the same name? No signature carried by the transfer itself can answer that question, because every such signature is made by the key being introduced. IDDrop therefore separates the act of transferring an identity from the act of changing what a receiver has anchored for that identity (Section 7).

IDDrop fills these gaps by defining a protocol for identity drop, acceptance, and validation across both human and system lanes.

This document is intended as an identity-transfer profile over the more general TIBET TAT transfer substrate [TAT] and within the broader Continuity Envelope Protocol (CEP) model [CEP].

The key design principle is simple: identity MUST NOT arrive as a surprise commitment.

2. Terminology

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

IDDrop
The protocol specified in this document for identity offer, request, response, validation, and acceptance.
Offer
A temporary, visible, non-binding identity availability signal.
Request
An explicit solicitation by a receiver for a specific claim or identity response.
Response
A sealed and receiver-bound identity-carrying answer to either an accepted offer or a request.
Acceptance
An explicit receiver-side act indicating consent to proceed from discovery into sealed identity transfer.
Materialization
The act of committing a validated identity claim into a receiver runtime, registry, or operator-visible state.
Carrier Truth
The byte-level truth established by sealed carrier properties such as magic bytes, authenticated encryption, signatures, and receiver binding.
Semantic Class
The declared object class of a transfer unit, such as identity, code, document, command, or receipt.
Causal Binding
The linkage between a request, offer acceptance, and later response, such that the receiver can verify that the identity answer belongs to a known prior step.
Identity Card
A self-signed record that binds a claimed name to a verification (signing) public key and, where used, a key-agreement (sealing) public key. It carries public key material only.
Anchor
A receiver-local binding of a claimed name to the key material the receiver has deliberately accepted for that name. The set of anchors held by a receiver is its Anchor Store.
Party Key
The long-lived key that identifies a party (a person, organization, agent, or device identity) as opposed to a Runtime Key.
Runtime Key
A key held by a particular execution instance acting for a party. Runtime keys may be replaced without the party changing.
Key Change
The situation in which material for a claimed name names a Party Key different from the one the receiver has anchored for that name.
Supersession Decision
An explicit, recorded act by an authorized principal that replaces an existing Anchor with different key material (Section 7.4).

3. Protocol Overview

3.1. Identity Transfer Planes

IDDrop operates across three conceptual planes:

Discovery Plane:
Visible availability and preliminary metadata.
Sealed Transfer Plane:
Confidential and receiver-bound identity carriage.
Commitment Plane:
Validation, acceptance, and materialization into runtime or operator state, including any change to the receiver's Anchor Store.

Systems implementing IDDrop MUST NOT collapse these planes into a single implicit step. In particular, the arrival of an object in a receiver's inbox is a Discovery or Sealed Transfer Plane event; it is not materialization.

3.2. Human and System Lanes

IDDrop defines two operating modes:

  • offer-first, for human, proximity, NFC, QR, and local discovery workflows
  • request-first, for daemon, automation, cap-bus, and machine-to-machine workflows

Human, proximity, and NFC workflows SHOULD use offer-first mode. Autonomous, daemon, and command-fabric workflows SHOULD use request-first mode. Both modes share the same validation rules (Section 6) and the same anchor discipline (Section 7).

4. Offer-First Mode

Offer-first mode is intended for NFC handoff, QR handoff, local discovery, AirDrop-like experiences, and home-agent or human-supervised device exchange.

The offer-first flow is:

  1. sender enables a temporary offer
  2. receiver discovers offer metadata
  3. receiver chooses accept, challenge, or reject
  4. if accepted, sender performs sealed transfer to receiver
  5. receiver validates the claim
  6. receiver MAY materialize the claim

An offer SHOULD contain at least offer_id, expires_at, sender_pubkey, claimed_aint, claim_class, semantic_type, display_name, preview_hash, and ssm_class.

Offer metadata MUST NOT be treated as commitment truth.

4.1. Discovery Header and Sealed Body

When an offer is carried as a file or other storable object rather than as a live proximity exchange, it SHOULD be split into a plaintext discovery header and a sealed body. The discovery header carries only what a receiver needs to recognize that an offer exists and for whom it is intended (for example sender name, sender verification key, intended receiver name, expiry, and an ephemeral key-agreement public key). The terms of the offer travel in the sealed body, encrypted to the intended receiver's key-agreement key.

If a discovery header is used, it SHOULD be signed by the sender's verification key and SHOULD carry a hash of the sealed body, so that header and body cannot be recombined from different offers. A receiver MUST NOT rely on any header field for Rule 4 (Section 6) unless that field is covered by a signature it has verified.

4.2. Offer Lifecycle

An offer that has been presented is not an offer that has been accepted. Implementations SHOULD distinguish at least the following states when reporting on an offer:

waiting:
an offer is open and no answer has arrived
accepted:
an answer has arrived and validated
refused:
an answer has arrived and was a rejection, or failed validation
none:
no offer is open and no outcome is recorded

"waiting" and "none" MUST NOT be reported as the same state: one is an open question, the other a question that was never asked.

A sender SHOULD NOT present an offer (for example, display a QR code) unless it is able to receive the answer to that offer for the duration of the offer window. A sender SHOULD hold at most one open offer for the same question; presenting a second offer for the same question while the first is open can invalidate an offer that a receiver is in the process of answering.

Offers MAY be encoded for visual transfer, for example as a URI suitable for a QR code. Such an encoding is a Discovery Plane artifact only and confers no authority.

5. Request-First Mode

Request-first mode is intended for daemon-to-daemon exchange, cap-bus identity requests, relay and automation lanes, and policy-driven system exchange.

The request-first flow is:

  1. receiver emits a request
  2. request carries request_id and challenge_nonce
  3. sender creates a receiver-bound response
  4. receiver validates request/response linkage
  5. receiver MAY materialize the claim

A request SHOULD contain at least request_id, challenge_nonce, requested_claim_type, receiver_pubkey, requested_aint, causal_parent, and expires_at.

The challenge_nonce is issued by the receiver and is single-use. It SHOULD contain at least 128 bits of cryptographically random data.

6. Validation Rules

The following six validation rules are REQUIRED. A receiver MUST evaluate them in order and MUST stop at the first rule that fails.

  1. Carrier Truth: the receiver MUST verify carrier truth before trusting object bytes. If a sealed carrier format is used, the receiver MUST validate its authenticated encryption and signature properties. Where a carrier format defines an authorship signature, a carrier that lacks it MUST be treated as failing this rule, not as an acceptable unsigned variant.

  2. Semantic Class: the receiver MUST determine the semantic class of the object before commitment. Byte validity alone is insufficient. An identity claim MUST be explicitly classed as an identity object.

  3. Receiver Binding: the receiver MUST verify that the response is bound to the intended receiver. A response not addressed to the receiver MUST be rejected.

  4. Claim Provenance: the receiver MUST validate the claim against a provenance source such as AINS [AINS], JIS [JIS], an equivalent actor registry, or its local Anchor Store (Section 7). The outcome of this check is one of "match" (the sender key equals the anchored key), "unknown" (no anchor or registry record exists for the claimed name), or "mismatch" (a record exists for the claimed name with a different key). Only "match" satisfies this rule. Implementations SHOULD report "unknown" and "mismatch" as distinct outcomes, since they call for different actions. A "mismatch" MUST NOT be resolved by updating the anchor as a side effect of validation; Section 7.4 defines the only path by which an anchor changes. The sender key checked here MUST be one whose control the sender has demonstrated in this exchange, for example by a verified signature over the response or over the discovery header.

  5. Causal Binding: in request-first mode, the receiver MUST validate that the response belongs to the prior request by checking request_id, challenge_nonce, and any causal parent references. In offer-first mode, the receiver MUST validate that acceptance and later transfer belong to the same offer session. A nonce or offer session MUST be consumed on its first successful use; a later object bound to the same nonce or offer session MUST be rejected as a replay.

  6. Commitment Discipline: the receiver MUST NOT materialize or register an identity claim before Rules 1 through 5 have succeeded, and MUST NOT materialize a claim whose validity window has elapsed.

An implementation that accepts objects through more than one path (for example a sealed path and an older unsealed path) MUST apply Rules 3 through 6 identically on every path. A path that omits a rule is a downgrade path and defeats the rule on all paths.

7. Anchors and Key Change

This section specifies how a receiver's Anchor Store changes. It applies to both operating modes and to any other mechanism by which an implementation binds a claimed name to key material.

7.1. Anchor Store

A receiver maintains an Anchor Store that maps each claimed name to the key material the receiver has deliberately accepted for it: a verification key and, where used, a key-agreement key. Anchors are created by an explicit act, such as importing an Identity Card received out of band, or resolving the name through a registry such as AINS.

Names locate an anchor; key fingerprints decide whether two records describe the same key. Implementations SHOULD display a key fingerprint wherever they display a claimed name in a context where a key decision is made.

7.2. Identity Cards and Self-Signatures

An Identity Card is signed by the verification key it introduces. A receiver MUST verify that self-signature before creating an anchor from a card.

A valid self-signature proves only that the card is internally consistent. It does not prove that the holder of the card is the same party as any earlier holder of the same name, because the signature is made by the very key being introduced. Implementations MUST NOT treat a valid self-signature as evidence of party continuity.

7.3. Import Outcomes

When a receiver is asked to anchor key material for a claimed name, exactly one of the following outcomes applies:

first anchor:
No anchor exists for the name. The receiver MAY create one as the result of the explicit act that requested it.
identical:
An anchor exists with the same key material. The operation MUST be idempotent and SHOULD NOT create a history entry.
key change:
An anchor exists with different key material. The receiver MUST NOT replace the anchor. It MUST refuse the operation, and the refusal SHOULD identify the anchored and offered key fingerprints and the explicit decision path described in Section 7.4.

When a receiver resolves a name through a registry and already holds an anchor for that name, it MUST compare the registry key with the anchored key. On a difference it MUST NOT overwrite the anchor and SHOULD report the mismatch.

7.4. Supersession Decision

An existing anchor MAY be replaced only by a Supersession Decision: an explicit act by a principal authorized to administer the receiver's Anchor Store. A Supersession Decision MUST produce a record that:

  • identifies the claimed name;
  • records the previous and the new key material;
  • identifies the decider;
  • records when the decision was made; and
  • references the previous anchor, which MUST be retained as history and MUST NOT be deleted.

The record SHOULD state that it is an assertion by the decider rather than a cryptographic measurement. No signature available at that point can establish continuity: the new card is signed by the new key, and the old key may be unavailable and unable to object.

A Supersession Decision changes the anchor only. It MUST NOT by itself transfer relations, capabilities, consents, or other authority that were bound to the previous key.

7.5. One Rule for Every Path

Every path by which an implementation can bind a claimed name to key material MUST apply Section 7.3 and Section 7.4. This includes at least:

  • intake of an offer, request, or response (Rule 4);
  • completion of a handshake or relation succession in which the peer's key is taken from the peer's own message (Section 8);
  • import of an Identity Card; and
  • registry resolution when an anchor already exists.

A guarded intake path combined with an unguarded alternate path is not a partial defense. It makes substitution through the alternate path more credible, because the result appears to have passed the guarded path.

7.6. Own Identity and First Contact

A receiver does not anchor its own identity. When it evaluates a key change for a name whose private key it holds, it MAY treat possession of that private key as grounds for accepting the key. Implementations SHOULD report this as a distinct standing (held by possession) and MUST NOT record it as an anchor decision.

Absence of an anchor is not permission. For a first contact with no prior relation, an implementation MAY accept a key on first use through an explicit import or acceptance act. Within the succession of an existing relation, a changed key for which no anchor exists MUST be treated as a mismatch.

8. Handshake Completion and Succession

An accepted identity transfer often results in a durable mutual relation between two parties. Implementations that create such a relation SHOULD complete it in three steps:

  1. offer: the initiator signs the proposed terms;
  2. accept: the responder verifies the initiator's signature, checks that the offer has not been consumed before, and signs its half of the relation;
  3. confirm: the initiator verifies that the accept echoes its own signed offer unaltered and that the responder's half verifies, adds its own half, and returns the completed, mutually signed relation so that both sides hold the same object.

The signed relation body SHOULD describe the target state of the relation only. Handshake progress SHOULD NOT be part of the signed body, since a field that changes between accept and confirm invalidates the signature made at accept.

When a new relation replaces an earlier relation between the same parties, the new body SHOULD reference its predecessor, for example by a hash of the predecessor body, inside the signed content, so that the supersession claim is covered by both signatures. A co-signer MUST refuse to sign a supersession claim that does not match the predecessor it holds as current, or that it is unable to evaluate. An implementation that cannot determine whether a predecessor exists MUST NOT present the new relation as a first agreement.

A succession MUST NOT introduce a changed Party Key for either party unless that key has been anchored through Section 7.4 or is held by the evaluating party itself (Section 7.6). The check MUST be made before the evaluating party adds its own signature.

Runtime Keys MAY change while a relation persists; a party MAY re-attest a new Runtime Key under its unchanged Party Key without a new handshake. A change of Party Key is different in kind: it is a fork of the identity, not a delayed observation of it, and no fresher observation can repair it. It MUST be handled through Section 7.

9. Identity Migration and Key Material

Moving an identity to a new device or installation of the same party is an identity transfer in which sender and receiver are the same party. In addition to the rules above, the following apply:

10. Semantic Classification

Implementations SHOULD distinguish at least the following semantic classes: identity, code, document, command, and receipt.

Implementations MAY refine the identity class. Refinements in use include identity (a full identity assertion), sub-identity (a parent granting a sub-handle), capability (a scoped grant), and credential (an attestation about a subject). A refinement MUST NOT be used to move an object out of the identity class for the purposes of Section 6.

Offers and claims MAY additionally carry an entity class that describes what kind of subject is behind the claimed name, for example human, AI agent, IoT device, or autonomous agent endpoint, aligned with the entity types of [AINS]. Entity class is descriptive metadata and MUST NOT be used as provenance.

The semantic class MAY be carried through a semantic routing field or surface-manifest layer [SSM]. Implementations MUST NOT use filename extension alone as semantic truth.

11. Transport and Carrier Bindings

IDDrop is transport-agnostic. It MAY be carried over NFC, QR-assisted local handoff, local network discovery, message relay, and cap-bus or command-substrate lanes.

When a sealed carrier is used, implementations SHOULD use a receiver-bound confidential carrier format rather than raw opaque payload carriage.

One binding in use seals the offer body from an ephemeral X25519 key [RFC7748] to the receiver's static X25519 key-agreement key, derives the content key with HKDF-SHA256 [RFC5869], encrypts with AES-256-GCM, and signs the plaintext discovery header, including a SHA-256 hash of the sealed body, with the sender's Ed25519 key [RFC8032]. Because the receiver's key is static, the offer can be prepared while the receiver is offline. This binding is informative; other carrier formats meeting Rule 1 are equally acceptable.

11.1. Relationship to CEP and TAT

IDDrop is not intended to redefine generic handoff mechanics.

CEP defines the umbrella continuity messaging model, TAT defines the generic consent-bound handoff and transfer flow, and IDDrop defines the identity-transfer profile over that flow.

When a TAT implementation is available, IDDrop SHOULD use it as the preferred transfer and anchoring substrate.

12. Examples

12.1. Human NFC Offer

A user enables identity offer mode for 60 seconds on a device. Another device taps via NFC, sees the claim metadata and sender fingerprint, and explicitly accepts. The sender then transfers a receiver-bound sealed response, which the receiver validates against AINS/JIS before materialization.

12.2. System Request

A daemon requests an identity claim for a specific actor and embeds a nonce and request identifier. The sender responds with a sealed, receiver-bound response referencing the original request. The receiver validates the request linkage and provenance before continuing the workflow.

12.3. Key Change Refused, Then Decided

A receiver holds an anchor for alice.aint. It receives a new Identity Card for alice.aint whose self-signature verifies but whose verification key differs from the anchored one. The import is refused; the refusal shows both fingerprints and states that only an explicit decision can replace the anchor. A sealed offer from alice.aint under the new key is also refused under Rule 4 with outcome "mismatch".

The operator confirms out of band that Alice has moved to a new key and records a Supersession Decision. The previous card is kept as history; the record names the operator as decider and states that the decision is an assertion. Offers under the new key now satisfy Rule 4. Relations formed under the old key are not carried over by the decision; they are renewed through a new handshake, whose succession check (Section 8) now finds the new key anchored.

13. Implementation Status

This section is to be removed before publishing as an RFC.

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

13.1. tibet-iddrop

Organization:
Humotica
Description:
A Rust library and command-line tool implementing the offer, request, and claim objects of this document and a validator that evaluates the six rules of Section 6 in order, stopping at the first failure. It includes a registry resolver interface with an HTTP resolver for AINS, a receiver-issued 128-bit challenge nonce, and an encoding of offers as an iddrop:// URI for QR transfer.
Maturity:
Experimental. Version 0.3.1 is published on crates.io.
Coverage:
Offer-first and request-first objects and validation. The caller asserts the Carrier Truth result, and the caller keeps the lists of outstanding requests and offers, so single-use consumption is the caller's responsibility. Rule 4 compares the sender key with the registry key and refuses on difference or absence, without the distinct outcomes now recommended in Section 6. The validator checks the claim validity window as part of Rule 6. Identity-class refinements and entity classes (Section 10) are implemented. The Anchor Store and Supersession Decision of Section 7 are not implemented in this library.
Licensing:
MIT or Apache-2.0
Contact:
info@humotica.com

13.2. AInternet-in-a-Box Reference Implementation

Organization:
Humotica
Description:

A node implementation in which identity transfer is one of several ceremonies. Elements relevant to this document:

  • Identity Cards carrying name, Ed25519 verification key and X25519 key-agreement key, self-signed, and exported under a file name that carries the card's subject.
  • A card import operation implementing the three outcomes of Section 7.3: a key change is refused by default; an explicit supersede option keeps the previous card as history and appends a record naming the decider, the previous and new keys, a statement that the decision is an assertion and not a measurement, and a flag that it grants nothing further.
  • Registry resolution that, when a card is already held, compares it with the registry key and refuses on difference instead of overwriting.
  • Offers sealed as described in Section 11, followed on receipt by a provenance check of the header's sender key against the Anchor Store with distinct "unknown" and "mismatch" refusals, and a refusal when the sender is recorded as revoked.
  • A three-step offer, accept, and confirm handshake with a single-use offer nonce, and an account-level relation whose signed body carries the target state only. Successions reference their predecessor by hash; the co-signer refuses a supersession claim it cannot stand behind; and the confirming party checks, before signing, that the succession introduces no unanchored Party Key, distinguishing "unchanged", "changed and anchored", "changed and held by possession", and "changed and unanchored".
  • Re-attestation of new Runtime Keys under an unchanged account relation after a runtime is replaced, without a new handshake.
  • A migration carrier for a device-pairing identity whose private CA key is sealed under a key derived from the party's root key, which merges revocations monotonically, and which does not carry presence evidence.
  • A non-blocking QR offer with a separate collect step that reports "approved", "refused", "waiting", or "none". This is used for owner-presence approval rather than identity transfer and is listed for its offer-lifecycle behavior only.
Maturity:
Prototype. Test vectors for the anchor and succession rules (nine cases, covering refusal, explicit supersession with history, idempotent re-import, the possession standing, and the ordering of the succession check before signing) pass. Project records report the account-level relation and its re-attestation working between two independently enrolled test nodes in August 2026, and a sealed-offer provenance refusal ("mismatch") observed between two test nodes in September 2026, which prompted the rules of Section 7.5.
Coverage and known deviations:

The identity handshake follows the offer-first pattern; request-first mode is not implemented in this code base. The following deviations from this revision are known:

  • On some optional-signature and legacy offer paths the implementation does not yet apply every validation rule of this revision. These paths are being brought into line with Section 6; until then they are not conformant to this document.
  • An inbox reader for drop envelopes (including an example descriptor of type iddrop) checks envelope shape and records arrival only; it does not open payloads, so no materialization occurs.
Licensing:
AGPL-3.0-or-later.
Contact:
info@humotica.com

14. Security Considerations

14.1. Surprise Identity Is Forbidden

Identity transfer MUST NOT become binding merely because a sealed object was received. Offer-first mode is safe only if offers remain temporary and non-binding until explicit acceptance and later validation. Request-first mode establishes intent and causal context, but the receiver MUST still validate the response and its provenance.

14.2. Names, Extensions, and Look-Alike Claims

Implementations MUST treat user-visible names and extensions as advisory surfaces only. A man-in-the-middle or misleading sender MAY present a visually similar claim name. Provenance validation and receiver binding are REQUIRED to defeat such confusion.

Two independent parties can legitimately present the same name. Storing anchors keyed by name alone, and overwriting on import, lets the later party silently replace the earlier one; everything that is subsequently sealed to that name then reaches the later party. Section 7.3 exists to prevent this.

14.3. Key Difference Is More Dangerous Than Key Absence

A party with no key fails visibly at its first signature. A party with a different key under a known name signs successfully; every local signature check passes, and the substitution is detected only by a peer that still holds the earlier anchor. For this reason a "mismatch" outcome MUST be treated as at least as serious as "unknown", and refusals SHOULD be retained as evidence rather than discarded or overwritten, since a peer that stops verifying conveys information that no local check can.

14.4. Circular Evidence

A self-signed card, a signed key-change notice, or a relation body signed by a newly introduced key all prove only that the new key signed them. Treating such evidence as proof of continuity is circular. Continuity of a party across a key change can only be asserted by a principal, which is why Section 7.4 records a decider rather than a verification result.

Similarly, several local records that agree with each other but all predate the same event share one age; they do not independently confirm the current state.

14.5. Alternate Paths and Downgrade

Implementations SHOULD enumerate every operation that can write a name-to-key binding and every path by which an identity object can be accepted, and apply the same rules to each (Section 7.5, Section 6). An unsigned discovery header that names a sender key MUST NOT be accepted as proof of that key, since any party can write a victim's public key into an unsigned field.

14.6. Replay and Expiry

Offers and requests SHOULD carry expiries. Responses SHOULD be bound to active requests or active acceptances to limit replay. Single-use consumption of nonces and offer sessions (Section 6, Rule 5) is the primary replay defense; expiry times are a secondary bound and SHOULD NOT be the only defense, since they depend on loosely synchronized clocks.

14.7. Migration

A migration carrier that contains sealed private key material is a high-value object even when sealed. It SHOULD be stored outside the device it was exported from and handled as a secret. Merging revocations monotonically prevents an older carrier from resurrecting revoked devices.

15. Privacy Considerations

A plaintext discovery header necessarily reveals that an offer exists, and typically reveals the sender and intended receiver names. Implementations SHOULD keep the discovery header to the minimum needed for recognition and SHOULD place all offer terms in the sealed body.

Registry resolution reveals to the registry which names a receiver is interested in. Implementations SHOULD allow anchors to be established out of band, through Identity Cards, without contacting a registry.

16. IANA Considerations

This document has no IANA actions.

17. References

17.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

17.2. Informative References

[AINS]
van de Meent, J., "AINS Discovery", Work in Progress, Internet-Draft, draft-vandemeent-ains-discovery-02, , <https://datatracker.ietf.org/doc/draft-vandemeent-ains-discovery/>.
[JIS]
van de Meent, J., "JIS Identity", Work in Progress, Internet-Draft, draft-vandemeent-jis-identity-02, , <https://datatracker.ietf.org/doc/draft-vandemeent-jis-identity/>.
[SSM]
van de Meent, J., "TIBET Semantic Surface Manifest", Work in Progress, Internet-Draft, draft-vandemeent-tibet-semantic-surface-manifest-02, , <https://datatracker.ietf.org/doc/draft-vandemeent-tibet-semantic-surface-manifest/>.
[CEP]
van de Meent, J., "Continuity Envelope Protocol", Work in Progress, Internet-Draft, draft-vandemeent-continuity-envelope-00, , <https://datatracker.ietf.org/doc/draft-vandemeent-continuity-envelope/>.
[TAT]
van de Meent, J., "TIBET TAT: Touch-and-Transfer Protocol", Work in Progress, Internet-Draft, draft-vandemeent-tibet-tat-00, , <https://datatracker.ietf.org/doc/draft-vandemeent-tibet-tat/>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/info/rfc7748>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/info/rfc5869>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/info/rfc8032>.

Appendix A. Minimal JSON Shapes

The shapes below are illustrative. Field names for offers, requests, and responses follow Section 4 and Section 5.

{
  "offer": {
    "offer_id": "offer-123",
    "expires_at": "2026-05-17T10:00:00Z",
    "sender_pubkey": "hex...",
    "claimed_aint": "jasper.aint",
    "semantic_type": "identity"
  },
  "request": {
    "request_id": "req-456",
    "challenge_nonce": "nonce-789",
    "receiver_pubkey": "hex...",
    "requested_claim_type": "identity"
  },
  "response": {
    "request_id": "req-456",
    "sender_pubkey": "hex...",
    "receiver_pubkey": "hex...",
    "claimed_aint": "jasper.aint",
    "semantic_type": "identity",
    "provenance_ref": "ains:..."
  }
}

An Identity Card and a Supersession Decision record, as used by the reference implementation in Section 13.2, look as follows. The card's signature is computed over the canonical JSON of all other fields.

{
  "card": {
    "kind": "org.ainternet.identity.card.v1",
    "aint": "alice.aint",
    "verify_pubkey": "hex (Ed25519)...",
    "seal_pubkey": "hex (X25519)...",
    "sig": "ed25519:hex..."
  },
  "supersession": {
    "kind": "org.ainternet.identity.anchor-supersede.v1",
    "aint": "alice.aint",
    "at": 1789000000,
    "decided_by": "onbox:operator",
    "was_verify": "hex...", "now_verify": "hex...",
    "was_seal": "hex...",   "now_seal": "hex...",
    "kept_as": "alice.aint.superseded.<fp>.card.json",
    "assertion": "a human at this box declares these keys
                  to be the SAME PARTY",
    "not_measured": "no signature can prove this",
    "grants_nothing": true
  }
}

Appendix B. Changes from -00

This section is to be removed before publishing as an RFC.

Acknowledgments

The author thanks Root AI (Claude, Anthropic) for implementation work and drafting assistance on this revision, and Codex for analysis and review during the design of the relation continuity mechanisms reported here.

Author's Address

Jasper van de Meent
Humotica
Netherlands
URI: https://humotica.com/