specs/consent/request/v1_0/payload library

Classes

ConsentSubject
The platform-agnostic identifier of WHAT is being consented to: one conversation, for one agent.
Payload
A bridge asks the VTA whether an inbound conversation may reach an AI agent, prompting operator consent on first contact.
Response
Synchronous ack from the VTA: a prompt was routed (accepted) or the request was refused. The actual decision arrives out-of-band as a consent/decision.

Extension Types

Kind
The interaction kind: a 1:1 direct message, a multi-party group, or a broadcast channel.
ResponseStatus
accepted = a pending consent was minted and an approval prompt routed. refused = not actionable; reason MUST be set.
Scope
What the agent may do: receive = read inbound on this conversation; converse = read and reply.

Constants

payloadSchemaJson → const String
This specification's payload schema, as JSON text.
responsePayloadSchemaJson → const String
As payloadSchemaJson, for the success-response variant.
responseSpec → const SpecPolicy
The SPEC §7.2 policy for the success-response variant.
responseTypeUri → const String
The success-response form of typeUri (SPEC §4.4.1).
spec → const SpecPolicy
The SPEC §7.2 policy for the request variant, taken from this specification's front matter.
typeUri → const String
The Trust Task type URI this library's Payload is carried under.

Typedefs

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.