specs/task_consent/decision/v0_2/payload
library
Classes
-
AssertionResponse
-
The credential the client returns from
navigator.credentials.get. Binary fields
are base64url-encoded.
-
AssertionResponseResponse
-
AssertionResponseResponse, generated from its schema.
-
Payload
-
An enrolled approver authorizes (or refuses) one pending privileged task, bound to
the exact payload it was shown. The proof on this document — not the transport
session that carried it — is the authorization, and it is always made by the
approver's own DID. Additive over 0.1: an OPTIONAL
evidence member carries an
additional factor (a WebAuthn assertion, or a signed step-up approver statement)
the executor verifies on top of the proof, and an OPTIONAL actionId links the
decision to a Verifiable Trust Community action (vtc/admin/actions/list/0.1). The
outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof)
are owned by the framework — SPEC §6.3.
-
Response
-
Acknowledgement of the recorded decision, and whether the approval threshold is now
met.
Extension Types
-
Decision
-
The approver's answer.
deny aborts the pending request; a subsequent submit of
the same task starts a fresh one.
-
ResponseStatus
-
granted = the threshold is met: the requester's re-submit will now execute, or —
for a VTC action — the executor has executed (or is executing) the parked operation
itself. pending = the approval was recorded but more are needed. denied = the
request was aborted.
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.
-
Evidence
= Object?
-
An additional factor backing the decision, tagged on
kind. It never replaces the
document's proof — that proof is still REQUIRED and is by the approver's own DID —
and it is verified by the executor on top of it. Absent, the proof alone is the
authorization, exactly as in 0.1.
-
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.
