specs/provision/integration/v0_3/payload
library
Classes
-
AdminRotationAsk
-
Admin-only mint. No integration DID is produced. Used by holders that bring (or
will mint elsewhere) their own integration-side identity and only need an admin
credential at this maintainer.
-
BootstrapRequest
-
W3C Verifiable Presentation 2.0 (§6.1: VPs MAY omit
verifiableCredential). Custom
members nonce, validUntil, label, and ask sit alongside the standard VP
fields and are covered by the same DataIntegrityProof.
-
DataIntegrityProof
-
W3C Data Integrity proof. Spec body pins cryptosuite and proofPurpose; this schema
permits the standard property bag so future cryptosuites can ride the same shape.
-
DidTemplateRef
-
Reference to a DID template already registered at the maintainer. Inline template
definitions are deliberately not supported — templates must be uploaded out-of-band
first (operator-authored or built-in) so the maintainer can validate
vars against
the template's declared schema.
-
Payload
-
Relayer presents a VP-signed bootstrap request from an integration holder; the
maintainer mints the integration's DIDs and admin credential from a registered DID
template and ships the material back HPKE-sealed to the holder's ephemeral did:key.
Two ask variants are supported: TemplateBootstrap (mint integration DID + optional
admin DID) and AdminRotation (mint only the long-term admin DID).
-
ProvisionSummary
-
Audit-grade metadata about the provisioning outcome. Mirrors the existing
vta_sdk::provision_integration::http::ProvisionSummary Rust type but uses
camelCase wire fields per Trust Task convention.
-
Response
-
Carried in a Trust Task document whose type is
https://trusttasks.org/spec/provision/integration/0.1#response. The sealed
bundle
is the secret-bearing artefact; summary is non-secret audit metadata.
-
TemplateBootstrapAsk
-
Mint an integration DID from
template, and (when adminTemplate is present)
atomically roll over the holder to a fresh long-term admin DID minted from
adminTemplate.
Extension Types
-
PayloadAdminScope
-
How wide the ACL entry the maintainer writes for the minted admin is.
context
(the default, and what every integration-class consumer wants) binds the admin to
context alone. unrestricted binds it to no context at all — the shape an ACL
reads as a super-admin, able to act in every context the maintainer holds today and
in every one created later — and is what an operator console asks for. context is
resolved and authoritative in BOTH cases: it is where the admin DID is minted and
the home a consumer stores its own configuration under, so unrestricted widens
the grant without making the target context optional. A maintainer MUST refuse
unrestricted with provision/integration:forbidden unless the relayer is itself
a super-admin, because no admin may confer authority it does not hold. A maintainer
that does not implement this member ignores it and writes a context-scoped entry;
that is why the outcome is echoed as summary.adminScope rather than assumed from
the ask.
-
PayloadAssertion
-
Producer-assertion mode the maintainer should apply to the returned sealed bundle.
didSigned (default) — Ed25519 signature over the bundle's domain-bound digest,
verified by the holder against the maintainer's published key. pinnedOnly —
holder pins the bundle's SHA-256 digest as the sole integrity anchor; for dev/test
only. Maintainers MAY support additional modes (e.g. attested for TEE
deployments) and respond with provision/integration:assertionUnsupported to
unsupported requests.
-
ProvisionSummaryAdminScope
-
The scope of the ACL entry the maintainer actually wrote for
adminDid. Echoed
rather than assumed: a maintainer that does not implement payload.adminScope
ignores an unrestricted ask and writes a context-scoped entry, and a producer
that read its own request back would record authority it does not have. Absent from
maintainers that predate this member, which a producer MUST read as context.
Typedefs
-
BootstrapAsk
= Object?
-
Discriminated union of bootstrap intents. Extensible — future minor versions MAY
add variants.
-
DigestMultibase
= String
-
A cryptographic digest as a multibase-encoded multihash — the encoding the W3C
Verifiable Credentials Data Model 2.0 defines for
digestMultibase, and the one
did:webvh uses for its SCID and entry hashes. Multihash carries the hash
algorithm in-band, so the value is self-describing and the wire format survives an
algorithm change without a schema revision; multibase does the same for the base
encoding, so a verifier never infers base58 from base64url by context. A bare hex
string or a sha-256:-style prefix hard-codes one algorithm into the wire contract
and is non-conforming here. This definition constrains the encoding only. What
the digest is computed over is stated by each referencing field, because it differs
legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS)
canonicalization, while a digest over an opaque artifact is taken over its bytes. A
field whose input is a JSON document and which does not name a canonicalization is
not reproducible. Restricted to the two multibase headers W3C Controlled
Identifiers 1.0 §2.4 normatively requires — z (base58btc) and u
(base64url-no-pad). CID permits others but states that "interoperability is not
guaranteed between implementations using such values", and a registry whose purpose
is interoperability should not mint digests a conforming verifier may be unable to
read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I
and l, and an earlier permissive pattern let three published examples carry digests
that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with
did:key and did:webvh.
-
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.
