specs/keys/set_exportability/v0_1/payload
library
Classes
-
KeyRecord
-
KeyRecord
-
Payload
-
Names one key and the exportability it should carry afterwards. The outer document
members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the
framework — SPEC §6.3.
-
Response
-
The success response: the key record as it now stands. Returning the whole record
rather than an acknowledgement lets a producer confirm the state it asked for
without a second round trip. Wrapped in
key to match the rest of the family
(keys/show, keys/create). Carried in a Trust Task document whose type is
https://trusttasks.org/spec/keys/set-exportability/0.1#response.
Extension Types
-
KeyOrigin
-
Where the private key came from.
derived means the maintainer generated it from a
seed it holds and can reproduce it from derivationPath; imported means it
arrived from outside and exists only as stored material; internal means the
maintainer generated it from a CSPRNG and it is reproducible from nothing at all.
The distinction is operationally load-bearing: a derived key survives a seed
restore, an imported one is lost unless it was backed up separately, and an
internal one cannot be recovered by any means once the maintainer's storage is
gone. This member is also the only way a consumer can confirm that a keys/create
request for an internal key was honoured rather than silently downgraded to a
derived one — see that specification's internal member.
-
KeyStatus
-
Lifecycle state. Only an
active key may be named in a signing request; a
revoked key is retained so historic signatures remain attributable, and MUST NOT
be reactivated.
-
KeyType
-
Cryptographic algorithm the key material belongs to.
ed25519 signs (EdDSA),
x25519 performs key agreement and never signs, p256 signs (ES256), and
mldsa44 and mldsa65 sign with the post-quantum ML-DSA scheme of US NIST FIPS
204. The set is expected to grow as algorithms are standardised, and growing it is
a MINOR change under SPEC.md §5.2: keyType selects no schema branch, so adding a
value relaxes a constraint rather than narrowing one, and the generated libraries
mark this enumeration non-exhaustive so that a consumer absorbs a new value rather
than failing to compile. Two ML-DSA parameter sets are carried because two
specifications require different ones — W3C Quantum-Resistant Cryptosuites defines
Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1
mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key
and the two are not redundant. A consumer that does not implement a value it
receives MUST refuse the document rather than substitute one it does support.
Typedefs
-
Ext
= Map<String, dynamic>
-
Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a
reverse-DNS namespace; structure under each namespace is opaque to the framework.
