specs/task_consent/request/v0_1/payload
library
Classes
-
Effect
-
One consequence of executing the pending task, authored by the executor that is
about to run it. An effect is produced by dry-running the real handler against the
executor's own prior state — never by the requester, and never by re-implementing
the handler's semantics elsewhere. A consent surface renders ONLY effects it
received under the executor's signature.
-
Exposure
-
The authoritative SPEC §7.3 item 14 exposure class of the pending task, derived by
the executor from the compiled handler it is about to invoke — never from the
registry's declared value.
-
Payload
-
The executor asks an enrolled approver device to authorize one pending privileged
task, presenting the effects it computed by dry-running the real handler against
its own prior state. The executor signs this document; the approver renders only
what it verifies under that signature.
-
Response
-
Synchronous acknowledgement from the approver device that a prompt was raised. The
decision itself arrives separately as a task-consent/decision — a human is in the
loop, so it cannot be a synchronous reply.
-
StatePin
-
The prior state the effects were computed against. A human in the loop makes the
approval window minutes wide, so the state can move underneath a pending approval.
The executor asserts this pin still holds at execution and refuses otherwise —
without it, a lost update silently executes against state the approver never saw.
Extension Types
-
ExposureDiscloses
-
Sensitivity of data the task returns to its caller.
-
PayloadSideEffects
-
Authoritative SPEC §7.3 item 13 side-effect class of the pending task, derived by
the executor from the compiled handler it is about to invoke. NEVER taken from the
registry: a registry that decided this would be a consent kill-switch,
downgradeable by publishing a new version with a weaker class.
-
ResponseStatus
-
prompted = the request was verified and an approval prompt raised. refused =
the device will not prompt; reason MUST be set.
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.
