IDDrop: Identity Drop and Acceptance Protocol

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. IDDrop fills this gap 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 and within the broader Continuity Envelope Protocol (CEP) model. The key design principle is simple: identity MUST NOT arrive as a surprise commitment.

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

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.

Protocol Overview IDDrop operates across three conceptual planes: Discovery Plane, Sealed Transfer Plane, and Commitment Plane. Systems implementing IDDrop MUST NOT collapse these planes into a single implicit step. 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

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:

sender enables a temporary offer
receiver discovers offer metadata
receiver chooses accept, challenge, or reject
if accepted, sender performs sealed transfer to receiver
receiver validates the claim
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.

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:

receiver emits a request
request carries `request_id` and `challenge_nonce`
sender creates a receiver-bound response
receiver validates request/response linkage
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`.

Validation Rules The following six validation rules are REQUIRED.

Carrier Truth: the receiver MUST verify carrier truth before trusting object bytes.
Semantic Class: the receiver MUST determine the semantic class of the object before commitment. Byte validity alone is insufficient.
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.
Claim Provenance: the receiver MUST validate the claim against a provenance source such as AINS, JIS, or an equivalent actor registry.
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.
Commitment Discipline: the receiver MUST NOT materialize or register an identity claim before Rules 1 through 5 have succeeded.

Semantic Classification Implementations SHOULD distinguish at least the following semantic classes: identity, code, document, command, and receipt. Implementations MUST NOT use filename extension alone as semantic truth.

Security Considerations IDDrop forbids surprise identity commitment. 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. 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. Offers and requests SHOULD carry expiries. Responses SHOULD be bound to active requests or active acceptances to limit replay.

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.

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.

Examples

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.

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.