]> TIBET TAT: Touch-and-Transfer Protocol Humotica
Netherlands info@humotica.com https://humotica.com/
Security Internet Engineering Task Force tibet tat touch-and-transfer sealed handoff consent-bound transfer 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.
Introduction 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.
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.
TAT
The Touch-and-Transfer protocol specified in this document.
Seed
A compact signed handshake object exchanged before tunnel opening.
Consent
The explicit receiver-side decision to accept, reject, or request more information before transfer continues.
Transfer Pair
The sender-side transfer_out anchor and receiver-side transfer_in anchor that together record a single handoff event.
TAT Tunnel
The encrypted transport channel established after seed validation and consent.
Tombstone
An optional finality record written after successful transfer to indicate deactivation or succession.
Protocol Overview 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.
TAT Objects
Seed Object
Advertises transfer intent and carries minimum material for validation and tunnel setup.
Consent Object
The receiver-side signed response that echoes the transfer identifier and states accept, reject, or request_more.
Transfer-Out Anchor
The sender-side record of initiated transfer. It MUST be written before protected content flows.
Transfer-In Anchor
The receiver-side record of received and verified transfer. It MUST only be written after integrity verification succeeds.
Optional Tombstone
An optional finality object recording deactivation or succession after transfer.
Touch-and-Transfer Flow
  1. sender generates an ephemeral X25519 keypair and a new transfer_pair_id
  2. sender emits a Seed Object
  3. receiver validates the seed and performs consent
  4. receiver emits a signed Consent Object
  5. sender verifies consent
  6. sender writes transfer_out
  7. both sides derive the tunnel key
  8. encrypted chunks are streamed
  9. receiver verifies final integrity and writes transfer_in
  10. sender MAY write a tombstone
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.
Tunnel Establishment 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 and HKDF-SHA256 for deriving a per-transfer tunnel key and nonce prefix. The transfer itself SHOULD use an authenticated encryption scheme such as AES-256-GCM . Chunks MUST be sequenced and integrity checked, and the receiver MUST compare the final result to the sender's summary before writing transfer_in.
Validation Rules
  1. Bilateral Consent: a sender MUST NOT begin protected content transfer before an explicit receiver-side consent has been verified.
  2. Seed Authenticity: the receiver MUST verify the seed signature, fingerprint, and transfer identifier before producing consent.
  3. 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.
  4. Stream Integrity: the receiver MUST verify the stream integrity and final content summary before writing transfer_in.
  5. Mutual Anchoring: the sender MUST write transfer_out before content flow, and the receiver MUST write transfer_in only after successful verification.
  6. 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.
Relationship to CEP, TIBET, SSM, ICC, and IDDrop 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.
  • TIBET decides causal truth
  • TAT carries the handoff
  • ICC or TZA seals the object
  • SSM makes the outer surface routable
  • IDDrop decides identity-transfer semantics above TAT
Security Considerations 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.
IANA Considerations This document has no IANA actions.
Normative References Key words for use in RFCs to Indicate Requirement Levels An Interface and Algorithms for Authenticated Encryption HMAC-based Extract-and-Expand Key Derivation Function (HKDF) Elliptic Curves for Security Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Concise Binary Object Representation (CBOR) Informative References TIBET Causal Time TIBET Semantic Surface Manifest Continuity Envelope IDDrop