| Internet-Draft | TIBET TAT | May 2026 |
| van de Meent | Expires 19 November 2026 | [Page] |
This document specifies TIBET TAT, a Touch-and-Transfer protocol for moving sealed continuity-bearing objects across proximity, relay, and local-network handoff lanes.¶
TAT defines a consent-bound handoff model, a seed exchange for tunnel establishment, encrypted chunk streaming, and mutual transfer anchoring between sender and receiver.¶
TAT does not define identity truth, semantic class, or sealed object class by itself. Instead, it defines the wire and handoff layer that carries such objects once sender and receiver have agreed to transfer. TAT is intended to sit between the Continuity Envelope Protocol (CEP) and higher-level application profiles such as IDDrop.¶
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 19 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Many systems can transport bytes, but fewer specify the exact handoff semantics of a consensual sealed transfer.¶
TIBET TAT addresses this gap. TAT is the wire and handoff protocol for touch-and-transfer and related relay delivery paths.¶
The key design principle is simple: transfer MUST be consent-bound, anchored, and sealed.¶
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.¶
TAT sits between general continuity messaging and higher-level application protocols. TIBET decides causal truth, TAT decides transfer flow, ICC or TZA/TBZ sealed carriers decide object structure, and SSM decides visible dispatch surface.¶
TAT is intended as the generic transfer profile that a specialized application profile MAY build upon.¶
TAT MAY be used across multiple transport modes including proximity touch, local relay, local network handoff, and HTTP-assisted handoff. The transport substrate MAY vary, but the TAT consent, tunnel, and transfer-pair semantics MUST remain invariant.¶
A relay or HTTP flow follows the same logical sequence. Implementations MUST NOT weaken bilateral consent, transfer-pair integrity, or receiver binding merely because the transport is not NFC-based.¶
TAT seeds are RECOMMENDED to be encoded compactly, for example using CBOR, when the seed must traverse a narrow proximity channel.¶
TAT RECOMMENDS X25519 for ephemeral ECDH [RFC7748] and HKDF-SHA256 [RFC5869] for deriving a per-transfer tunnel key and nonce prefix.¶
The transfer itself SHOULD use an authenticated encryption scheme such as AES-256-GCM [RFC5116]. Chunks MUST be sequenced and integrity checked, and the receiver MUST compare the final result to the sender's summary before writing transfer_in.¶
Bilateral Consent: a sender MUST NOT begin protected content transfer before an explicit receiver-side consent has been verified.¶
Seed Authenticity: the receiver MUST verify the seed signature, fingerprint, and transfer identifier before producing consent.¶
Transfer-Pair Consistency: the same transfer_pair_id MUST appear in the initiating seed, the receiver consent, the sender transfer_out anchor, and the receiver transfer_in anchor.¶
Stream Integrity: the receiver MUST verify the stream integrity and final content summary before writing transfer_in.¶
Mutual Anchoring: the sender MUST write transfer_out before content flow, and the receiver MUST write transfer_in only after successful verification.¶
Post-Transfer Finality: if a sender claims deactivation or succession, this MUST be represented by an explicit tombstone or equivalent finality object rather than by silent deletion alone.¶
TAT is lower than IDDrop, complementary to SSM, orthogonal to ICC or TZA/TBZ sealed object semantics, and anchored by but not identical to TIBET causal truth.¶
CEP is the umbrella continuity model, TAT is the generic handoff and transfer profile, and IDDrop is an identity-transfer application profile over TAT.¶
TAT is designed to reduce ambiguity in sealed handoff, but several security properties depend on correct composition. Physical proximity alone is insufficient without explicit consent. Transport confidentiality is insufficient without mutual anchoring. Transfer success is insufficient without final integrity checks. Silent deletion is insufficient as proof of retirement.¶
Implementations SHOULD surface fingerprint, sender identity, or equivalent trust hints before consent. Implementations MUST treat transfer_pair_id reuse as suspicious. Replayed or stale consent responses MUST be rejected.¶
This document has no IANA actions.¶