← Book map

Chapter 08 · Families

Payload plus policy

Data packet, user data, app encryption and attestation tab all carry arbitrary payloads — what differs is who may read it, sign it, or derive from it.

Data-bearing requests Data packet, user data, app encryption and attestation tab requests all carry arbitrary payloads qualified by flags that say who signed, who may read, and whether the payload is transmittal. PAYLOAD + POLICY FLAGS data packet statements signature · transmittal user data signer · requested keys full or partial app encryption derivation id return ESK attestation tab signed claims bound to identity The library carries the payload. The policy lives in flags and in what the reader is willing to trust.

FIGURE 8.1 · Four families, one shape.

Data packet — data/DataPacketRequestDetails.ts

Carries an arbitrary payload with flags for request id, statements, signature, "for user's signature" and "for transmittal to user". The last two are the interesting ones: they say whether the payload is a thing to be signed by the recipient, or content to be forwarded onward.

User data — data/UserDataRequestDetails.ts

Asks an identity to reveal data. Flags: has request id, has signer, has requested keys. The payload then distinguishes FULL_DATA from PARTIAL_DATA — a request for everything in a content multimap, or only specific keys.

App encryption — appencryption/AppEncryptionRequestDetails.ts

The crypto family: flags for request id, an encryption response address, a derivation id, and a "return ESK" request. The derivation id is what lets two parties derive the same symmetric key without transmitting it; returning the ESK asks for the extended spending key, which is a significantly stronger capability than plain decryption.

"Return ESK" is the flag to read twice. Decryption lets someone read one message; an extended spending key lets them derive every message in that chain of derivations.

Service signer and attestation tab

These are not separate wire formats so much as compositions: a service-signer request signs on behalf of a service identity (so the envelope carries both the acting and the delegated identity), and an attestation tab is a set of signed claims attached to an identity's data. Both lean on appOrDelegatedID and the signature container rather than inventing new primitives.

Reading the code

src/vdxf/classes/data/DataPacketRequestDetails.ts
src/vdxf/classes/data/UserDataRequestDetails.ts
src/vdxf/classes/appencryption/AppEncryptionRequestDetails.ts
src/vdxf/classes/ordinals/DataDescriptorOrdinalVDXFObject.ts
src/vdxf/classes/PersonalProfile.ts
← Book map

Next — Chapter 09 · Provisioning