specs/device/register/v0_2/payload
library
Classes
-
DeviceBinding
-
DeviceBinding
-
KeyCustody
-
How a device custodies its private key material — maintainer policy input,
mirroring
attestation. See docs/design-notes/mobile-key-custody-profile.md.
-
Payload
-
Public discovery surface that wraps the maintainer's existing two-phase enrolment
(provision-integration → acl/swap-key). A new Companion or Service hands the
maintainer its long-term VTA-derived key, its consumer kind, display name, and an
optional device attestation; the maintainer creates the DeviceBinding and returns
it. Phase 1 (provision-integration) is assumed to have already happened — this task
is the post-bootstrap claim step.
-
Response
-
Device Register — response payload
Extension Types
-
Capability
-
Fine-grained capability flag scoped to the device's allowed contexts. See SPEC.md
for the full semantics of each. Capability values are additive: a consumer MUST
ignore a value it does not recognise rather than reject the binding, and MUST NOT
treat an unrecognised value as conferring anything.
-
KeyCustodyTier
-
hardware: the key is non-exportable in the secure keystore (iOS Secure Enclave /
Android StrongBox) and every signing / key-agreement operation runs in-chip —
achievable only with P-256. software: the key is held in app memory during use,
stored hardware-wrapped at rest. Maintainers MAY apply stricter policy (shorter
sessions, more frequent step-up) to software-tier devices.
Typedefs
-
ConsumerKind
= Object?
-
Discriminator: is this consumer a user-driven Companion or a headless Service?
-
DeviceAttestation
= Object?
-
Producer-supplied attestation at registration time, verifiable by the maintainer
against the platform's attestation infrastructure. Tagged union over the
discriminator
kind.
-
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.