A11. Portability
Status: normative. Document version 1.0-draft-1.
A11.1 Export and import
export.json defines autonym-export/1.0: export time, origin, entries and included versions, non-content deletion tombstones, proposal events/acknowledgements, historical grants, read receipts, non-read log events, public verification keys, inactive policy history, unsupported-category report and proof. The owner chooses current versions or complete retained history. The export manifest says which was chosen. Owner-only wrappers bind every historical grant, receipt, log event, proposal and policy to its partition ID; validate those IDs against the partition list. Preserve canonical IDs, temporal intervals, overlay targets, semantic kinds, provenance, evidence references and original origin. Evidence references may be unavailable at the new host; report that explicitly, never treat missing evidence as verified.
Sign the JCS export excluding proof by the A5.4 method with the originating provider's ES256 key and protected typ:autonym-export+jws; its signed time is exported_at. Exported public keys preserve verifiability of historical artefacts, keeping any exp (A5.4); they do not become trusted active signing keys at the destination. Once the export verifies, its public_keys and origin_host are the trusted key set and issuer for the receipts it carries, and a carried receipt naming another provider is verified against that provider's own key set or reported as unverified history (A5.4). The owner's authenticated export operation establishes the source, with explicit source trust on import. Do not follow arbitrary key URLs from the file. Never export private keys, access/refresh tokens, passkeys, client secrets or executable credentials.
The importer validates size, schema, signatures, vocabulary, IDs, versions, temporal constraints, dependency cycles, relationships and each partition's A4.1 entry limit before changing the destination. Maximum decoded v1 import is 64 MiB and 100,000 entries/events of each supported kind. Reject duplicate IDs/versions with differing content. Identical retransmission is idempotent. Imports use a staged preview listing unsupported categories and conflicts. The person chooses whether to omit unsupported material or cancel; no silent data loss is permitted. Committing entries, selection and provenance is atomic for the accepted import.
Imported grants, rules, delegations and consent events are immutable history, never executable authority. The destination creates fresh keys, handles and client-bound grants after new consent. An old token MUST fail at the new provider. Unverified credentials remain archived and non-disclosable. A legacy value with no core key mapping is reported as unsupported, not coerced into a broad text field.
A11.2 Optional encrypted export
The unencrypted signed JSON contract is required for Portable; passphrase encryption is an optional, fully specified format. Use compact JWE with alg:dir, enc:A256GCM, typ:autonym-export+jwe and cty:application/autonym-export+json. Plaintext is UTF-8 of the signed export. Use a new random 96-bit GCM IV and 128-bit authentication tag as required by JWE.
Derive a 32-byte key with Argon2id RFC 9106, version 19, memory 65,536 KiB, three iterations, four lanes and a fresh random 16-byte salt. The UTF-8 passphrase is used exactly as entered, without normalisation or truncation. The protected header contains crit:["autonym_kdf"] and autonym_kdf:{name:"argon2id",v:19,m:65536,t:3,p:4,salt:<base64url-unpadded>}. This authenticated critical extension is the sole v1 KDF parameter set. Argon2id is not a JOSE alg.
Reject unsupported/missing KDF fields, salt size, algorithms, duplicate JSON members and excess encrypted size before allocating Argon2 memory. Limit concurrent derivations. Verify GCM before parsing or exposing plaintext, then verify export signatures and semantics. Authentication failure returns a generic invalid-export result, without distinguishing wrong passphrase from tampering. Use maintained Argon2/JWE libraries; do not implement these primitives in application code.
A11.3 Honest portability
A provider claiming Portable supports both export and import for its stated categories and demonstrates round-trip preservation, conflict reporting and no authority transfer. A recipient claiming Reciprocal supports receiving and returning the person's stated data categories; it need not transfer proprietary model weights or ranking algorithms. Raw history and confirmed preferences are separate selections. Named media services are examples, not integration claims.
Checks: PORT-01, ENCRYPT-01, SIGN-01, KEY-01, LOG-02, CLAIM-01, TEMP-01 to TEMP-03.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.