specs/framework/v0_4/framework library

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.

ExtCritical = List<String>

Names the ext namespaces a consumer MUST understand or refuse, per SPEC.md §4.5.1. Every entry MUST be an immediate key of the sibling ext object at the same level; an entry naming an absent namespace is non-conforming and the consumer rejects the document with malformedRequest. A consumer that does not recognize a namespace named here MUST NOT process the document as though the namespace were absent, and rejects it with unsupportedExtension — the exception to the rule that unrecognized namespaces are ignored. A producer marks a namespace only where the document's meaning depends on it. Marking one that merely carries a hint or an annotation turns every consumer that has not implemented it into a failure where it would otherwise have interoperated. JSON Schema cannot check either of those rules: that an entry names a present namespace is checkable only against the sibling ext, and whether a namespace is load-bearing is not a schema question at all. Both are consumer-side checks.