# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-04T06:03:19Z", "synthesisSha256": "2e6a62557a1c366d9fe62702a66d28dffa13a1fa05d33126a36b5cb83b39e516", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-XCT-034", "registryId": "vr.wm-xct-034", "name": "Digital Signature / Proof", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.SIG" ], "tags": [ "digital", "signature", "proof", "xct.sig" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-034-digital-signature-proof/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-034", "model": { "registry_id": "vr.wm-xct-034", "model_id": "WM-XCT-034", "name": "Digital Signature / Proof", "entry_kind": "mixin", "purpose": "Provide a reusable, format-neutral mixin for attaching digital signatures and cryptographic proofs to any host record: the proof instance itself, its method and parameters, the signer and verification-method references it claims, the meaning it asserts, its composition with other proofs, and the verification status recorded against it.", "scope_statement": "WM-XCT-034 models a proof as a host-bound value: an identified, versioned, stateful assertion produced by applying a cryptographic method over a bound content representation, together with the references, claims and recorded status needed to reason about it. The boundary covers the proof record and its identity; classification of proof kind; method, parameters, proof value and encoding; the reference (not the substance) of the verification method and signer; the declared purpose or commitment and the content-binding declaration stating what representation the proof covers; explicit separation of authenticity, integrity, origin attribution, approval, authorization, non-repudiation support and legal effect; composition of independent co-signatures, ordered countersignatures, endorsements and threshold or multi-party proofs; trust-validation inputs and recorded verification status; preservation state for long-term verifiability; and the governance metadata an adopting Dimension needs to operate the mixin. It does not own private keys, party records, credentials, certification-authority operations, trust anchors, the host content, authorization policy, audit trails, notarization or the determination of legal effect.", "in_scope": [ "Proof instance identity, version and state as a host-bound record distinct from the host it protects", "Classification of proof kind, including qualified kinds such as electronic seal, time-stamp token, selective-disclosure proof and zero-knowledge attestation", "Method and cryptosuite identifiers, hash function, algorithm parameters and the encoding of the proof value", "Reference to the verification method or public key required to verify, carried as a reference with binding and coverage metadata", "Content-binding declaration: which representation the proof covers and whether it is enveloped, enveloping, detached or internally detached", "Separation of claimed signer, signing actor, key or verification-method controller, credential subject and verified signer identity", "Signer capacity and on-behalf-of representation claims, carried as claims with references to external mandate evidence", "Declared proof purpose, commitment type, security domain, challenge and nonce that limit acceptable reuse", "Explicit per-property declaration of integrity, authenticity, origin attribution, approval, authorization, non-repudiation support and legal effect", "Composition patterns, cardinality and dependency for co-signature sets, ordered proof chains, endorsements and threshold or multi-party proofs", "Claimed signing instant as a signer claim, references to external proof-of-existence evidence, and separately recorded observation time", "Recorded verification status with its evaluation instant, evaluating-party reference, referenced validation policy and declared staleness", "Preservation state recording which long-term verification material has been attached to the proof", "Governance metadata for the mixin: stewardship, access scope, retention disposition and interoperability profile bindings" ], "out_of_scope": [ "Private signing keys, signature creation data, signature activation data, key generation, key storage and signature creation devices", "Person, organization, device and software-agent identity records; the mixin carries references only", "Credentials and public-key certificates, their contents, issuance, suspension and revocation", "Certification authority, trust service provider and time-stamping authority operations", "Trust anchors, trusted lists and trust-anchor management", "The host document, dataset or message being signed, its content model, canonicalization rules and lifecycle", "Authorization policy definition and the decision whether a signer was permitted to sign", "Execution of cryptographic verification, evaluation of validation policy, and enforcement of validation outcomes", "Audit logs and audit-trail semantics for verification, access or disposition events", "Notarization services and determination of legal effect, admissibility or evidential weight", "Encryption, confidentiality, key agreement and key transport", "Specification of cryptographic algorithms and the selection of approved algorithm suites" ], "boundary_notes": [ { "neighbor": "Message authentication code (symmetric MAC)", "distinction": "COSE MAC structures provide data authentication and integrity but no or very limited data origination and cannot prove the sender's identity to a third party; a MAC is a distinct proof kind and never a synonym for a digital signature.", "source_refs": [ "SRC-008", "SRC-006" ] }, { "neighbor": "Unkeyed hash, digest or checksum", "distinction": "A digest binds content to a value but carries no signer, key or purpose. Digests appear inside proofs (the CMS message-digest attribute, SD-JWT _sd digests) as integrity mechanisms; they are not proofs of origin.", "source_refs": [ "SRC-006", "SRC-010" ] }, { "neighbor": "Electronic time-stamp and time-stamp token", "distinction": "A TSA asserts only that a datum existed before a particular time; it asserts nothing about the datum's validity or who created it. Time-stamp tokens are referenced as proof-of-existence evidence and their issuance belongs to the time-stamping model.", "source_refs": [ "SRC-009", "SRC-011" ] }, { "neighbor": "Electronic seal of a legal person", "distinction": "eIDAS defines an electronic seal as data ensuring origin and integrity of other data, while a signatory is a natural person who creates an electronic signature. The mixin classifies these as different proof kinds and never decides their legal effect.", "source_refs": [ "SRC-011" ] }, { "neighbor": "Public-key certificate and verifiable credential", "distinction": "A certificate or credential binds a key or claims to a subject. The proof only nominates a verification method; issuance, subject claims, status and revocation belong to the credential model.", "source_refs": [ "SRC-005", "SRC-006" ] }, { "neighbor": "Signature validation application and validation policy", "distinction": "Creation and validation procedures, validation constraints and the resulting validation report are produced by a validation application under a validation policy. This model records a status value and a report reference and never owns evaluation, enforcement or the report itself.", "source_refs": [ "SRC-013", "SRC-004" ] }, { "neighbor": "Selective-disclosure and zero-knowledge proof", "distinction": "SD-JWT presentations combine an issuer signature, disclosures and optional holder key binding; unlinkability limits and holder key binding are properties of that mechanism. Such proofs are qualified proof kinds with their own constraints, not equivalents of a plain signature.", "source_refs": [ "SRC-010" ] }, { "neighbor": "Legal effect determination", "distinction": "Model law sets non-discrimination, functional-equivalence and reliability criteria, and regulation attaches legal effect to categories of signature. Legal effect is determined by applicable law and forum, not by this record.", "source_refs": [ "SRC-012", "SRC-011" ] }, { "neighbor": "Host content and its canonical representation", "distinction": "The proof declares what representation it covers and how it is attached, but the host's content model, transforms and canonicalization rules remain with the host model.", "source_refs": [ "SRC-004", "SRC-006" ] } ] }, "sources": [ { "id": "SRC-001", "title": "FIPS 186-5, Digital Signature Standard (DSS)", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/fips/186-5/final", "version_or_date": "FIPS 186-5, 3 February 2023, DOI 10.6028/NIST.FIPS.186-5", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Normative definition of approved digital signature algorithms and the statement that signatures detect unauthorized modification, authenticate the signatory and support non-repudiation." }, { "id": "SRC-002", "title": "FIPS 204, Module-Lattice-Based Digital Signature Standard", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/fips/204/final", "version_or_date": "FIPS 204, 13 August 2024, DOI 10.6028/NIST.FIPS.204", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Establishes that approved signature methods are a versioned, extensible set, grounding method-identifier and parameter fields and algorithm-agility requirements." }, { "id": "SRC-003", "title": "NIST Special Publication 800-102, Recommendation for Digital Signature Timeliness", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-102.pdf", "version_or_date": "September 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "States that a signer-asserted signing time is not trustworthy evidence and that trusted timestamp authorities are required to establish when a signature was generated." }, { "id": "SRC-004", "title": "Verifiable Credential Data Integrity 1.0: Securing the Integrity of Verifiable Credential Data", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-data-integrity/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Normative proof data model (type, cryptosuite, proofPurpose, verificationMethod, created, expires, domain, challenge, nonce, proofValue, previousProof), proof sets versus proof chains, verification result structure, and explicit statements about what a proof does not assert." }, { "id": "SRC-005", "title": "Verifiable Credentials Data Model v2.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Separates securing mechanisms (embedded versus enveloping proofs) from the host data model, distinguishes verification from validation, and states that the data model does not define the proof format itself." }, { "id": "SRC-006", "title": "RFC 5652: Cryptographic Message Syntax (CMS)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5652.html", "version_or_date": "STD 70, September 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "SignerInfo structure, signer identification, signed and unsigned attributes, parallel signatures by multiple signers, the countersignature attribute over a signature value, signing-time trust caveats, and the SignedData versus AuthenticatedData distinction." }, { "id": "SRC-007", "title": "RFC 7515: JSON Web Signature (JWS)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7515.html", "version_or_date": "Standards Track, May 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Protected versus unprotected header coverage, the alg parameter, key-identification headers (jku, jwk, kid, x5u, x5c, x5t), multiple signatures in the JSON serialization, and security considerations stating that a JWS does not establish trust in the key." }, { "id": "SRC-008", "title": "RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9052.html", "version_or_date": "STD 96, August 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "COSE_Sign (multiple signers) versus COSE_Sign1 (single signer), algorithm authentication requirements, removal of countersignature text, and the explicit statement that MACs cannot prove sender identity to a third party." }, { "id": "SRC-009", "title": "RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3161.html", "version_or_date": "Standards Track, August 2001", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "TSTInfo structure (policy, messageImprint, serialNumber, genTime, accuracy, ordering, nonce, tsa) and the limit that a TSA asserts only that a datum existed before a time, not its validity or authorship." }, { "id": "SRC-010", "title": "RFC 9901: Selective Disclosure for JSON Web Tokens (SD-JWT)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9901.html", "version_or_date": "Standards Track, November 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Issuer-signed JWT plus disclosures plus optional key-binding JWT, the _sd and _sd_alg mechanisms, the cnf key-binding claim, and privacy limits including linkability and issuer-verifier collusion." }, { "id": "SRC-011", "title": "Regulation (EU) No 910/2014 (eIDAS), Article 3 — Definitions", "organization": "The National Archives / legislation.gov.uk (retained EU legislation)", "url": "https://www.legislation.gov.uk/eur/2014/910/article/3", "version_or_date": "Revised text as retained in UK law, amendments to 5 February 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Definitions of electronic signature, advanced and qualified electronic signature, signatory as a natural person, electronic signature creation data, electronic seal for origin and integrity, electronic time stamp, and validation as verifying and confirming validity." }, { "id": "SRC-012", "title": "UNCITRAL Model Law on Electronic Signatures (2001)", "organization": "United Nations Commission on International Trade Law (UNCITRAL)", "url": "https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_signatures", "version_or_date": "Adopted 5 July 2001", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Establishes non-discrimination, technological neutrality and functional equivalence, and makes reliability criteria — not a specific technology — the basis for legal equivalence, keeping legal effect outside the technical record." }, { "id": "SRC-013", "title": "Digital Signature Service (DSS) Documentation", "organization": "European Commission, Digital Building Blocks", "url": "https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html", "version_or_date": "Version 6.4, 24 July 2024", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "First-party documentation of the European Commission implementation of the ETSI EN 319 102-1 validation model: baseline levels B-B/B-T/B-LT/B-LTA, indications TOTAL-PASSED / TOTAL-FAILED / INDETERMINATE with sub-indications, validation policy and constraints, validation reports, packaging modes and commitment types." }, { "id": "SRC-014", "title": "RFC 7797: JSON Web Signature (JWS) Unencoded Payload Option", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7797.html", "version_or_date": "RFC 7797, February 2016 (Proposed Standard)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:16:00Z", "relevance": "Defines the b64 header parameter that changes the exact protected input, requires it to occur only in the protected header and to be listed in crit (Sections 3 and 6), requires the same value across all signatures of one object, and addresses detached payloads and character restrictions (Sections 5.1 and 5.2). Direct evidence that payload encoding is itself a protected, must-be-understood binding parameter." }, { "id": "SRC-015", "title": "RFC 9338: CBOR Object Signing and Encryption (COSE): Countersignatures", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9338.html", "version_or_date": "RFC 9338, December 2022 (Proposed Standard)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:19:00Z", "relevance": "Defines the Countersign_structure with context, body_protected, sign_protected, external_aad, payload and other_fields (Section 3.3), where other_fields carries the target signature value, and requires the target structure's cryptographic functions to be finalized before countersigning. Primary evidence that a dependent proof must bind the exact finalized bytes of the prior protected input." }, { "id": "SRC-016", "title": "XML Signature Syntax and Processing Version 1.1", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/xmldsig-core1/", "version_or_date": "W3C Recommendation, 11 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:21:00Z", "relevance": "Defines the Reference element with an optional URI attribute that may be omitted on at most one Reference, the advisory Type attribute, Transforms, DigestMethod and DigestValue (Section 4.4.3), reference generation (Section 3.1.1), core validation as two mandatory steps of reference validation and SignedInfo signature validation (Section 3.2), the enveloped, enveloping and detached topologies (Section 2), and the Manifest element (Section 5.1)." }, { "id": "SRC-017", "title": "Content Credentials: C2PA Technical Specification, Version 2.1", "organization": "Coalition for Content Provenance and Authenticity (C2PA)", "url": "https://spec.c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html", "version_or_date": "Version 2.1, September 2024", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:23:00Z", "relevance": "Defines hard bindings to content: the data hash assertion with exclusion ranges expressed as start and length plus padding, the BMFF-based hash and general box hash assertions for selected-part scope, hashed URI references carrying url, alg and hash, the requirement that a standard manifest contain at least one hard-binding assertion, and the security requirement that changes to excluded data must not change how the asset is interpreted." }, { "id": "SRC-018", "title": "Subresource Integrity", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/SRI/", "version_or_date": "W3C Working Draft, 20 March 2026", "source_type": "standard", "primary_source": false, "authority_tier": 2, "accessed_at": "2026-09-04T10:24:00Z", "relevance": "Defines integrity metadata as a hash function plus digest, both of which MUST be provided (Section 3.1), the match-or-block comparison of computed digest against metadata (Sections 3.3.4 and 3.7), algorithm agility with multiple hash expressions (Section 3.2.1) and strongest-metadata selection (Section 3.3.3). Cited only as the digest-pinning pattern for immutable external resources; as a Working Draft it is corroboration, never a conformance target." }, { "id": "SRC-019", "title": "RFC 8785: JSON Canonicalization Scheme (JCS)", "organization": "RFC Editor / IETF Independent Submission", "url": "https://www.rfc-editor.org/rfc/rfc8785.html", "version_or_date": "June 2020, Informational", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:15:00Z", "relevance": "Normative rules for JSON property ordering by UTF-16 code units, ECMAScript number serialization, escaping, whitespace suppression, the I-JSON constraint forbidding duplicate names, and UTF-8 output." }, { "id": "SRC-020", "title": "Canonical XML Version 1.1", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/xml-c14n11/", "version_or_date": "W3C Recommendation, 2 May 2008", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:16:00Z", "relevance": "UTF-8 output, line-break normalization to #xA, attribute and namespace ordering, whitespace treatment, xml: attribute inheritance and xml:base fixup, plus the explicit statement that the canonical form may lose base URI and entity information." }, { "id": "SRC-021", "title": "RDF Dataset Canonicalization (RDFC-1.0)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/rdf-canon/", "version_or_date": "W3C Recommendation, 21 May 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:17:00Z", "relevance": "Graph-level canonicalization with deterministic blank node labelling, canonical N-Quads output, a parameterised internal hash algorithm that must be unequivocally expressed, and the poison-dataset complexity denial-of-service consideration." }, { "id": "SRC-022", "title": "RFC 9421: HTTP Message Signatures", "organization": "RFC Editor / IETF", "url": "https://www.rfc-editor.org/rfc/rfc9421.html", "version_or_date": "February 2024, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:21:00Z", "relevance": "Signature base construction from canonicalized component values plus an @signature-params line, and security considerations on canonicalization ambiguity, message component source ambiguity, insufficient coverage, replay and signature confusion." }, { "id": "SRC-023", "title": "XML Signature Best Practices", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/xmldsig-bestpractices/", "version_or_date": "W3C Working Group Note, 11 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:23:00Z", "relevance": "Signature wrapping mitigation requiring position as well as name checks, restriction of XSLT and XPath transforms, entity expansion and external reference risks, and nonce plus timestamp replay guidance." }, { "id": "SRC-024", "title": "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax", "organization": "RFC Editor / IETF", "url": "https://www.rfc-editor.org/rfc/rfc3986.html", "version_or_date": "January 2005, Standards Track, STD 66", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:24:00Z", "relevance": "Four-level base URI establishment precedence, the reference resolution algorithm, media-type dependent fragment semantics, and the normalization and comparison ladder from simple string to protocol-based equivalence." }, { "id": "SRC-025", "title": "Unicode Standard Annex #15: Unicode Normalization Forms", "organization": "Unicode Consortium", "url": "https://www.unicode.org/reports/tr15/", "version_or_date": "Version 17.0.0, 2025-07-30", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:25:00Z", "relevance": "NFC, NFD, NFKC and NFKD forms, canonical versus compatibility equivalence, the irreversibility warning for compatibility forms, normalization stability with the composition version fixed at Unicode 3.1.0, and version dependence for unassigned code points." }, { "id": "SRC-026", "title": "RFC 9380: Hashing to Elliptic Curves", "organization": "RFC Editor / IRTF Crypto Forum Research Group", "url": "https://www.rfc-editor.org/rfc/rfc9380.html", "version_or_date": "August 2023, Informational (IRTF)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:26:00Z", "relevance": "Domain separation tag definition and construction requirements: nonzero length, application-unique fixed string, embedded version and suite identifiers, and the cross-protocol reuse risk when domain separation is absent." }, { "id": "SRC-027", "title": "RFC 8725: JSON Web Token Best Current Practices", "organization": "RFC Editor / IETF", "url": "https://www.rfc-editor.org/rfc/rfc8725.html", "version_or_date": "February 2020, BCP 225", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:27:00Z", "relevance": "Algorithm confusion and none-algorithm threats, cross-JWT confusion and substitution attacks, and the countermeasures of explicit typing, mutually exclusive validation rules per token kind, and audience validation." }, { "id": "SRC-028", "title": "RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format", "organization": "RFC Editor / IETF", "url": "https://www.rfc-editor.org/rfc/rfc8259.html", "version_or_date": "December 2017, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:28:00Z", "relevance": "Duplicate member names are only SHOULD-unique with divergent parser behaviour, member ordering visibility varies, numeric precision is bounded by binary64 for interoperability, and interchange must use UTF-8." }, { "id": "SRC-029", "title": "RFC 8949: Concise Binary Object Representation (CBOR)", "organization": "RFC Editor / IETF", "url": "https://www.rfc-editor.org/rfc/rfc8949.html", "version_or_date": "December 2020, Standards Track, STD 94", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:29:00Z", "relevance": "Core deterministic encoding requirements, shortest-form arguments, prohibition of indefinite-length items, bytewise lexicographic map key ordering over encoded keys, and duplicate map keys being well-formed but not valid with protocol-defined disposition." }, { "id": "SRC-030", "title": "Canonical XML Version 2.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/xml-c14n2/", "version_or_date": "W3C Working Group Note, 11 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:30:00Z", "relevance": "A single algorithm URI subject to named parameters (IgnoreComments, TrimTextNodes, PrefixRewrite, QNameAware) with documented defaults, plus a catalogue of defects in Canonical XML 1.x and Exclusive C14N including QName and wrapping exposure and XPath-driven cost." }, { "id": "SRC-031", "title": "RFC 9360: CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9360.html", "version_or_date": "RFC 9360, February 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:13:00Z", "relevance": "Defines x5bag (32), x5chain (33), x5t (34) and x5u (35), their permitted protected/unprotected placement, the requirement that end-entity certificate identification be integrity protected, and the boundary statement that certificate validation remains a separate obligation." }, { "id": "SRC-032", "title": "RFC 9053: CBOR Object Signing and Encryption (COSE): Initial Algorithms", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9053.html", "version_or_date": "RFC 9053, August 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:20:00Z", "relevance": "Shows COSE algorithm identifiers as negative/positive integers from the IANA COSE Algorithms registry (ES256 = -7, EdDSA = -8) and requires curve/key-type consistency — the evidence base for algorithm identifier-space divergence between projections." }, { "id": "SRC-033", "title": "RFC 8118: The application/pdf Media Type", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8118.html", "version_or_date": "RFC 8118, March 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:22:00Z", "relevance": "Registers application/pdf and states that the single media type is used for all PDF versions, with the version only in the %PDF- header — direct evidence for media-type ambiguity, and confirms that PDF supports digital signatures and that ISO 32000-2 is PDF 2.0." }, { "id": "SRC-034", "title": "Securing Verifiable Credentials using JOSE and COSE", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-jose-cose/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:10:00Z", "relevance": "Defines the enveloping-proof approach and registers application/vc+jwt, application/vp+jwt, application/vc+sd-jwt, application/vp+sd-jwt, application/vc+cose and application/vp+cose; states that the unsecured credential is the JWS payload or the COSE_Sign1 payload, and makes no statement about conversion between securing mechanisms." }, { "id": "SRC-035", "title": "XML Advanced Electronic Signatures (XAdES)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/XAdES/", "version_or_date": "W3C Note, 20 February 2003", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T09:16:00Z", "relevance": "Freely readable enumeration of signed qualifying properties (SigningTime, SigningCertificate, SignaturePolicyIdentifier, SignatureProductionPlace, SignerRole, DataObjectFormat/MimeType, CommitmentTypeIndication, data-object timestamps) and unsigned properties (CounterSignature, SignatureTimeStamp, CompleteCertificateRefs, CompleteRevocationRefs, CertificateValues, RevocationValues, ArchiveTimeStamp), plus QualifyingProperties attachment via Target and a typed SignedProperties reference. Superseded for normative use by ETSI EN 319 132-1." }, { "id": "SRC-036", "title": "ETSI EN 319 142-1: Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.02.01_60/en_31914201v010201p.pdf", "version_or_date": "V1.2.1, January 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:14:00Z", "relevance": "Normative source for PAdES baseline levels B-B/B-T/B-LT/B-LTA, the SubFilter value ETSI.CAdES.detached, ByteRange coverage of the whole file except the signature octets, and Document Security Store certificate/revocation carriage. Publisher listing and version confirmed; the PDF body was not machine-retrievable in this pass, so clause-level attribute tables are recorded as unverified." }, { "id": "SRC-037", "title": "ETSI TS 119 182-1: Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.02.01_60/ts_11918201v010201p.pdf", "version_or_date": "V1.2.1, July 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:24:00Z", "relevance": "Defines the sigD header parameter identifying one or more detached data objects that are processed and concatenated to form the detached JWS payload (with HttpHeaders, ObjectIdByURI and ObjectIdByURIHash mechanisms) and the single etsiU unprotected header array. Publisher listing and version confirmed; clause-level text not machine-retrievable in this pass." }, { "id": "SRC-038", "title": "JSON Object Signing and Encryption (JOSE) IANA registries", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/jose/jose.xhtml", "version_or_date": "Registry, last updated 2026-05-22", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:19:00Z", "relevance": "Normative registry for JWS/JWE header parameters and algorithms under a Specification Required policy with designated experts — the governed identifier space for JOSE parameter names and the reference point for registry-snapshot pinning." }, { "id": "SRC-039", "title": "ETSI EN 319 122-1: Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.03.01_60/en_31912201v010301p.pdf", "version_or_date": "V1.3.1, June 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:04:00Z", "relevance": "Normative CAdES building blocks and baseline levels layered on RFC 5652 signed/unsigned attributes. Publisher listing and version confirmed; the PDF body returned HTTP 403 to automated retrieval, so attribute-level requirements are marked unverified and CMS-level facts are cited from RFC 5652 instead." }, { "id": "SRC-040", "title": "ETSI EN 319 132-1: Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.03.01_60/en_31913201v010301p.pdf", "version_or_date": "V1.3.1, July 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:25:00Z", "relevance": "Current normative XAdES specification superseding the 2003 W3C Note for qualifying-property definitions and baseline levels. Publisher listing and version confirmed; clause-level text not machine-retrievable in this pass, so XML qualifying-property naming is cited from the W3C Note and property placement from XML Signature 1.1." }, { "id": "SRC-041", "title": "ISO 32000-2:2020 Document management — Portable document format — Part 2: PDF 2.0", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/75839.html", "version_or_date": "Edition 2, December 2020 (reviewed and confirmed 2026)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:26:00Z", "relevance": "Defines the PDF signature dictionary with its Filter and SubFilter pair, ByteRange, incremental updates and document timestamps that PAdES profiles. Purchase-only from ISO (a no-cost sponsored copy is distributed by the PDF Association); clause-level content is paywalled and was not machine-retrievable, so PDF signature structure is treated as an unverified alignment target rather than a quoted requirement." }, { "id": "SRC-042", "title": "PAdES — PDF Advanced Electronic Signature", "organization": "PDF Tools AG", "url": "https://www.pdf-tools.com/pdf-knowledge/pades-pdf-advanced-electronic-signature/", "version_or_date": "Published 2023-02-21, updated 2025-02-06", "source_type": "secondary", "primary_source": false, "authority_tier": 4, "accessed_at": "2026-09-04T09:21:00Z", "relevance": "Vendor knowledge-base article used only to discover omissions: PAdES B-B to B-LTA level content, VRI/DSS long-term validation data, document timestamps, the ETSI TS 103 172 legacy profile still referenced by eIDAS, and ISO 14533-3 long-term PAdES profiles. Every claim taken from it is flagged as secondary and unconfirmed against the ETSI clause text." }, { "id": "SRC-043", "title": "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5280", "version_or_date": "May 2008, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Normative source for certification path validation inputs and algorithm (clause 6), basic constraints, name constraints, policy constraints, key usage and extended key usage, and the CRL profile including thisUpdate, nextUpdate, revocationDate, reason codes, certificateHold, removeFromCRL, delta CRLs and issuing distribution point (clause 5)." }, { "id": "SRC-044", "title": "RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6960", "version_or_date": "June 2013, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Normative source for CertID scope, good/revoked/unknown statuses (2.2), thisUpdate/nextUpdate/producedAt semantics (2.4), pre-produced responses (2.5), delegated responder authorization and id-kp-OCSPSigning and ocsp-nocheck (2.6, 4.2.2.2), response acceptance conditions (3.2), the nonce extension (4.4.1) and archive cutoff (4.4.4)." }, { "id": "SRC-045", "title": "RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc4158", "version_or_date": "September 2005, Informational", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Establishes the separation of path building from path validation, the existence of multiple candidate paths in mesh and bridge architectures, retrieval sources (AIA, SIA, LDAP, caches), sorting and elimination heuristics, loop control by repeated subject-name and key pairs, and separate path building for revocation signer certificates." }, { "id": "SRC-046", "title": "RFC 5914: Trust Anchor Format", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5914", "version_or_date": "June 2010, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Defines TrustAnchorInfo (pubKey, keyId, taTitle, certPath, exts) and CertPathControls (taName, certificate, policySet, policyFlags, nameConstr, pathLenConstraint), and the notion of a trust anchor list or store, grounding trust-anchor identity and anchor-carried path controls." }, { "id": "SRC-047", "title": "RFC 9608: No Revocation Available for X.509 Public Key Certificates", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9608", "version_or_date": "2024, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Defines the noRevAvail extension and modifies RFC 5280 path validation so revocation checking is skipped when noRevAvail or ocsp-nocheck is present; the counterexample proving that absent status evidence is not always incomplete evidence." }, { "id": "SRC-048", "title": "RFC 9919: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9919", "version_or_date": "2026, Proposed Standard; obsoletes RFC 5019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Normative source for nonce omission and the requirement to ignore a nonce when none was sent, mandatory nextUpdate for caching, GET and HTTP cache behaviour, pre-produced response distribution, and configurable clock-skew tolerance around nextUpdate." }, { "id": "SRC-049", "title": "RFC 7633: X.509v3 Transport Layer Security (TLS) Feature Extension", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7633", "version_or_date": "October 2015, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Shows that hard-fail on missing stapled status evidence is only well-founded when the certificate itself declares the required feature, and that a relying party can otherwise draw no conclusion from absent in-band status information." }, { "id": "SRC-050", "title": "Decentralized Identifiers (DIDs) v1.1", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/did-1.1/", "version_or_date": "Candidate Recommendation, 5 March 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Defines verification method properties (id, type, controller, publicKeyJwk, publicKeyMultibase) in clause 5.2 and the verification relationships authentication, assertionMethod, keyAgreement, capabilityInvocation and capabilityDelegation in clause 5.3, grounding non-X.509 verification-method binding and declared purpose." }, { "id": "SRC-051", "title": "DID Resolution v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/did-resolution/", "version_or_date": "Candidate Recommendation Draft, 28 August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Defines resolution options (accept, versionId, versionTime), resolution metadata (contentType, error), DID document metadata (created, updated, deactivated, versionId, nextVersionId, canonicalId, equivalentId) and error codes, grounding captured resolution inputs and version references without owning resolver operation." }, { "id": "SRC-052", "title": "Bitstring Status List v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Defines credentialStatus, BitstringStatusListEntry (statusListIndex, statusListCredential, statusSize, statusMessage) and statusPurpose values revocation, suspension, message and refresh, plus validFrom/validUntil, ttl and herd-privacy caching guidance for credential status evidence." }, { "id": "SRC-053", "title": "EU List of Trusted Lists (LOTL)", "organization": "European Commission", "url": "https://ec.europa.eu/tools/lotl/eu-lotl.xml", "version_or_date": "TSLSequenceNumber 393, TSLVersionIdentifier 6, retrieved 4 September 2026", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Live primary artifact demonstrating trust-list snapshot fields actually in use: TSLVersionIdentifier, TSLSequenceNumber, TSLType, SchemeOperatorName, SchemeTerritory, StatusDeterminationApproach, HistoricalInformationPeriod, ServiceDigitalIdentity with X509Certificate, TSLLocation and the ETSI TSL MIME type." }, { "id": "SRC-054", "title": "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates", "organization": "CA/Browser Forum", "url": "https://cabforum.org/working-groups/server/baseline-requirements/requirements/", "version_or_date": "Version 2.2.9, effective 6 August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T10:00:00Z", "relevance": "Root-program-facing operational requirements showing that a CA must make revocation information available for subordinate and subscriber certificates (clause 2.1), and evidence that publicly-trusted TLS practice constitutes one operational stance among several rather than a universal rule." }, { "id": "SRC-055", "title": "NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 - General", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final", "version_or_date": "May 2020 (Revision 5)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Source of security-strength framing and of the separation between key-management lifecycle (out of scope here) and the algorithm and key types employed by a signature." }, { "id": "SRC-056", "title": "NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/131/a/r2/final", "version_or_date": "March 2019 (Revision 2, final)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Currently final transition guidance: the basis for recording an algorithm's transition status and for distinguishing signature generation from signature verification when assigning that status." }, { "id": "SRC-057", "title": "NIST SP 800-131A Rev. 3 (Initial Public Draft), Transitioning the Use of Cryptographic Algorithms and Key Lengths", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd", "version_or_date": "2024-10-21 (initial public draft)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Draft proposing retirement of DSA signature generation and of SHA-1 and 224-bit hash functions, and the move from 112-bit to 128-bit security strength; cited as draft status, not as a conformance target." }, { "id": "SRC-058", "title": "NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/ir/8547/ipd", "version_or_date": "2024-11-12 (initial public draft)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Draft roadmap for migrating quantum-vulnerable signature algorithms to post-quantum standards; supports a recorded migration-state field pinned to a named policy rather than a universal date." }, { "id": "SRC-059", "title": "CBOR Object Signing and Encryption (COSE) - COSE Algorithms registry", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/cose/cose.xhtml", "version_or_date": "Last updated 2026-08-25", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Change-controlled registry of numeric algorithm labels with Name, Value, Description, Capabilities, Change Controller, Reference and a Recommended column carrying Yes / No / Deprecated states." }, { "id": "SRC-060", "title": "RFC 6979, Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6979.html", "version_or_date": "August 2013 (Informational)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Establishes that deterministic signatures remain fully compatible with plain DSA and ECDSA and that verifiers need not be aware of the nonce-derivation process, so randomness mode is not verifier-observable." }, { "id": "SRC-061", "title": "ETSI EN 319 102-1 V1.4.1, Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.04.01_60/en_31910201v010401p.pdf", "version_or_date": "V1.4.1 (2024-06)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Normative validation model: the TOTAL-PASSED / INDETERMINATE / TOTAL-FAILED indications with sub-indications, validation constraints including cryptographic sunset dates, validation time, proof of existence and the basic, long-term and archival validation processes." }, { "id": "SRC-062", "title": "ETSI TS 119 102-2 V1.4.1, Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_ts/119100_119199/11910202/01.04.01_60/ts_11910202v010401p.pdf", "version_or_date": "V1.4.1 (2023-06)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Defines the structure of a signature validation report, including validation objects used (trust anchors, revocation data, time-stamps) and a signature over the report, enabling inspection of the causes behind a status indication." }, { "id": "SRC-063", "title": "ETSI TS 119 312 V2.1.1, Electronic Signatures and Trust Infrastructures (ESI); Cryptographic Suites", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf", "version_or_date": "V2.1.1 (2026-06)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Defines a cryptographic signature suite as the combination of message-encoding function, hash function and signature scheme, and acts as the European algorithm-policy catalogue that a policy pin can cite." }, { "id": "SRC-064", "title": "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure (draft-ietf-lamps-pq-composite-sigs)", "organization": "IETF LAMPS Working Group", "url": "https://lamps-wg.github.io/draft-composite-sigs/draft-ietf-lamps-pq-composite-sigs.html", "version_or_date": "Editor's draft, 2026-06-15", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Defines composite algorithm identifiers and the rule that a valid result is output if and only if all component signatures validate, plus the EUF-CMA versus SUF-CMA security-property caveat; cited as draft." }, { "id": "SRC-065", "title": "ESSCertIDv2 Update for RFC 3161", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5816.html", "version_or_date": "RFC 5816, November 2010", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T08:12:00Z", "relevance": "Requires a TSA certificate identifier (ESSCertID or ESSCertIDv2) as a signerInfo attribute and mandates SigningCertificateV2 for any hash algorithm other than SHA-1; grounds algorithm agility in token-to-key binding." }, { "id": "SRC-066", "title": "Evidence Record Syntax (ERS)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc4998.html", "version_or_date": "RFC 4998, August 2007", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T08:18:00Z", "relevance": "EvidenceRecord, ArchiveTimeStamp, ArchiveTimeStampChain and ArchiveTimeStampSequence; reduced hash trees; time-stamp renewal versus hash-tree renewal; and the recommendation for redundant evidence records under different algorithms and authorities." }, { "id": "SRC-067", "title": "Extensible Markup Language Evidence Record Syntax (XMLERS)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6283.html", "version_or_date": "RFC 6283, July 2011", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T08:24:00Z", "relevance": "XML projection of evidence records with an explicit CanonicalizationMethod per chain, CryptographicInformationList for certificates and revocation data, and the same two renewal strategies; demonstrates container independence of the evidence semantics." }, { "id": "SRC-068", "title": "CMS Advanced Electronic Signatures (CAdES)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5126.html", "version_or_date": "RFC 5126, March 2008", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T08:44:00Z", "relevance": "Signature forms BES/EPES/T/C/X/A, validation-data attributes, grace period, arbitration model, and the explicit distinction that signing-time is a signer claim while a time-stamp token is proof of existence." }, { "id": "SRC-069", "title": "Certificate Transparency Version 2.0", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9162.html", "version_or_date": "RFC 9162, December 2021", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T08:50:00Z", "relevance": "Merkle tree, signed tree head/checkpoint, inclusion and consistency proofs, log identity and maximum merge delay, and the security position that logs enable detection of misissuance but do not themselves prove legitimacy." }, { "id": "SRC-070", "title": "Regulation (EU) No 910/2014 (eIDAS), Articles 32, 34 and 42", "organization": "European Union (text as published on legislation.gov.uk, The National Archives)", "url": "https://www.legislation.gov.uk/eur/2014/910/article/42", "version_or_date": "Regulation of 23 July 2014; retained-EU-law text accessed 2026-09-04", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:44:00Z", "relevance": "Article 32 requires the validation system to give the relying party the correct result and to let it detect security-relevant issues; Article 34 requires preservation to extend trustworthiness beyond the technological validity period; Article 42 requires time binding that precludes undetectable change and an accurate time source linked to UTC." }, { "id": "SRC-071", "title": "ETSI TS 119 172-1 - Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents", "organization": "ETSI", "url": "https://www.etsi.org/deliver/etsi_ts/119100_119199/11917201/01.01.01_60/ts_11917201v010101p.pdf", "version_or_date": "V1.1.1 (2015-07)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:12:00Z", "relevance": "Defines signature policy, signature applicability rules as business or legal fitness rules distinct from technical validation constraints, and the signature policy issuer role that signs the policy document. Supports policy pinning and the separation of policy authorship from signing and verification." }, { "id": "SRC-072", "title": "ETSI TS 119 511 - Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques", "organization": "ETSI", "url": "https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.02.01_60/ts_119511v010201p.pdf", "version_or_date": "V1.2.1 (2025-10)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:14:00Z", "relevance": "Preservation service policy, preservation profile and preservation evidence policy describing how preservation evidence is created and validated; supports the long-term evidence preservation obligation while keeping preservation service operation external." }, { "id": "SRC-073", "title": "Content Credentials: C2PA Technical Specification", "organization": "Coalition for Content Provenance and Authenticity (C2PA)", "url": "https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html", "version_or_date": "Version 2.2, May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T08:58:00Z", "relevance": "Claim signatures over host assets, X.509 signer credentials with a claim-signing EKU, validator-configured and default trust lists, RFC 3161 time-stamps that keep manifests valid after credential expiry, validation status codes at error/warning/informational levels, and correction by appended update manifests rather than in-place edit." }, { "id": "SRC-074", "title": "NARA Bulletin 2015-03: Guidance on Managing Digital Identity Authentication Records", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/bulletins/2015/2015-03.html", "version_or_date": "11 August 2015", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:09:00Z", "relevance": "Requires documenting how overwritten or expired certificates are managed, keeping records authentic, reliable and usable for their full life cycle, retaining digital identity authentication records as long as the business records they support, and removing authentication measures that impede access before archival transfer." }, { "id": "SRC-075", "title": "Records Management Guidance for Agencies Implementing Electronic Signature Technologies", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/electronic-signature-technology", "version_or_date": "18 October 2000 (superseded by NARA Bulletin 2015-03)", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T09:09:30Z", "relevance": "Enumerates the contextual records that must be retained to revalidate a signature later - certificates, the CRL current at signing, trust paths, trust verification records, certificate policies and practice statements, and algorithm details - plus the trustworthiness qualities of reliability, authenticity, integrity and usability. Marked superseded; used for the evidence-set enumeration, not for current US federal obligations." }, { "id": "SRC-076", "title": "Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (eIDAS)", "organization": "legislation.gov.uk (UK-retained revised text), original: European Parliament and Council", "url": "https://www.legislation.gov.uk/eur/2014/910/contents", "version_or_date": "Revised text as at 3 September 2026, with pending UK amendments", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:20:00Z", "relevance": "Article structure for jurisdictional regime pinning: Art. 22 trusted list, Art. 25 legal effects of electronic signatures, Art. 26 advanced signature requirements, Art. 32 validation of qualified electronic signatures, Art. 33 qualified validation service, Art. 34 qualified preservation service, Art. 35-40 seals, Art. 41-42 time stamps. The UK-retained revised text diverges from the EU consolidated text, evidencing why regime references must carry jurisdiction and effective interval." }, { "id": "SRC-077", "title": "Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates", "organization": "CA/Browser Forum", "url": "https://cabforum.org/working-groups/code-signing/documents/", "version_or_date": "Version 3.11, adopted by ballot CSCWG-32, 16 June 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T09:06:00Z", "relevance": "Industry-normative separation of subscriber key protection from CA operation, obligations to report suspected key compromise, bounded revocation investigation and action timelines, and the role of time-stamping in signature validity after certificate expiry or revocation. Binds publicly trusted code-signing CAs only." }, { "id": "SRC-078", "title": "Universal Electronic Records Management (ERM) Requirements", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/universalermrequirements", "version_or_date": "Version 3, June 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:10:00Z", "relevance": "Lifecycle-phase requirements covering capture, metadata, maintenance, transfer and disposal for born-digital and digitized records, separating program requirements from system requirements - the basis for treating retention schedules, transfer and disposal execution as an external records model this mixin only binds to." }, { "id": "SRC-079", "title": "RFC 6902: JavaScript Object Notation (JSON) Patch", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6902.html", "version_or_date": "April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T00:00:00Z", "relevance": "Atomic operation sequences (add, remove, replace, move, copy, test) with all-or-nothing application and the test operation as an optimistic-concurrency precondition — the format-neutral basis for this model's change-set and precondition rules." }, { "id": "SRC-080", "title": "Digital Signature Service (DSS) — Digital Building Blocks documentation", "organization": "European Commission, DG DIGIT (Digital Building Blocks)", "url": "https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/Digital+Signature+Service+-++DSS", "version_or_date": "DSS v6.5, August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T00:00:00Z", "relevance": "Public-authority first-party documentation of signature levels (B, B-T, B-LT, B-LTA), validation indications and sub-indications, diagnostic data, trusted-list handling and ETSI validation reports — the reference for recording status evidence and augmentation level as referenced outcomes rather than local computations." }, { "id": "SRC-081", "title": "in-toto Attestation Framework — Statement layer (v1)", "organization": "in-toto project (Cloud Native Computing Foundation)", "url": "https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md", "version_or_date": "Statement v1 (https://in-toto.io/Statement/v1)", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T00:00:00Z", "relevance": "Envelope/statement/predicate layering, subject as an array of resource descriptors that MUST carry a digest, and the rule that subjects are matched by digest and assumed immutable — the basis for subject binding and for treating a digest as a content address rather than an identity." }, { "id": "SRC-082", "title": "DSSE: Dead Simple Signing Envelope specification", "organization": "Secure Systems Lab (secure-systems-lab/dsse)", "url": "https://github.com/secure-systems-lab/dsse/blob/master/envelope.md", "version_or_date": "Version 1.0.2, 10 May 2024", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T00:00:00Z", "relevance": "Envelope fields (payload, payloadType, signatures with keyid and sig), authenticated payload type, multiple signatures as equivalent to separate envelopes, and the requirement that the exact verified payload bytes are the ones sent to the application layer — the basis for the byte-fidelity integrity rule." }, { "id": "SRC-083", "title": "NIST Special Publication 800-102: Recommendation for Digital Signature Timeliness", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/102/final", "version_or_date": "September 2009; withdrawn 1 July 2025", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T00:00:00Z", "relevance": "States that a purported signing time carried in a signed message gives no assurance unless the accuracy of the time can be trusted, and recommends trusted time-stamp authority tokens — the explicit basis for separating signer-claimed time from trusted evidence time. Its withdrawn status is recorded as a conflict rather than suppressed." }, { "id": "SRC-084", "title": "Verifiable Credential Data Integrity 1.0 — Securing the Integrity of Verifiable Credential Data", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/2025/REC-vc-data-integrity-20250515/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Normative structure of a proof (type, cryptosuite, verificationMethod, proofPurpose, created, expires, domain, challenge, nonce, previousProof, proofValue), the Add Proof algorithm, transformation/hashing/proof-serialization stages, unsecured versus secured documents, and proof sets versus proof chains." }, { "id": "SRC-085", "title": "RFC 9110: HTTP Semantics", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html", "version_or_date": "Internet Standard (STD 97), June 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Definition of idempotency and safe retry, entity-tags as strong versus weak validators, the If-Match precondition for lost-update prevention, and 412 Precondition Failed semantics — the basis for the optimistic-concurrency and idempotency preconditions on every mutation here." }, { "id": "SRC-086", "title": "PKCS #11 Specification Version 3.1", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/pkcs11-spec-v3.1-os.html", "version_or_date": "OASIS Standard, 23 July 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Signing operation sequence in which the mechanism and its parameters are fixed at initialisation, and the CKA_SENSITIVE, CKA_EXTRACTABLE and CKA_ALWAYS_AUTHENTICATE attributes that keep private keys inside the token and require authentication before key use." }, { "id": "SRC-087", "title": "Architectures and protocols for remote signature applications (CSC API v2.0)", "organization": "Cloud Signature Consortium", "url": "https://cloudsignatureconsortium.org/wp-content/uploads/2023/04/csc-api-v2.0.0.2.pdf", "version_or_date": "Version 2.0.0.2, October 2022", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Remote signing request surface: credentialID, signature activation data, the hashes array with hashAlgorithmOID, signAlgo and signAlgoParams, operationMode with asynchronous response correlation, validity_period, response_uri and clientData, with the private key held by the service and never released." }, { "id": "SRC-088", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Required date-time form with seconds and an explicit numeric offset or Z, rejection of unqualified local time as unacceptable for interoperability, and leap-second handling relevant to instants recorded around proof creation and expiry." }, { "id": "SRC-089", "title": "Data Integrity BBS Cryptosuites v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-di-bbs/", "version_or_date": "W3C Candidate Recommendation Draft, 2 September 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-04T12:00:00Z", "relevance": "Separates base proof creation by the issuer from derived proof creation by the holder, with mandatoryPointers, selectivePointers, presentationHeader and featureOption inputs, showing a proof can be produced without the issuer's private key — the reason sign and prove are modelled as one externalised executor operation." }, { "id": "SRC-090", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:20:00Z", "relevance": "Supplies invalidation semantics (Invalidation, wasInvalidatedBy, invalidatedAtTime, qualifiedInvalidation) as cessation of usability rather than destruction, and revision semantics (Revision, wasRevisionOf) for supersession as a derivation carrying substantial content forward." }, { "id": "SRC-091", "title": "RFC 9580: OpenPGP", "organization": "Internet Engineering Task Force (IETF) / RFC Editor", "url": "https://www.rfc-editor.org/rfc/rfc9580.html", "version_or_date": "Standards Track, July 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:24:00Z", "relevance": "Defines signature type 0x50 as a signature over another signature packet analogous to a notary seal, and the distinct revocation signature types 0x20, 0x28 and 0x30 with a reason-for-revocation subpacket; the clearest standards evidence that countersignature and key revocation are different mechanisms with different owners." }, { "id": "SRC-092", "title": "RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains", "organization": "Internet Engineering Task Force (IETF) / RFC Editor", "url": "https://www.rfc-editor.org/rfc/rfc9943.html", "version_or_date": "Standards Track, June 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:28:00Z", "relevance": "Defines Signed Statement, Receipt, Transparent Statement and Registration Policy; states that the statement sequence cannot be modified, deleted or reordered, that correction proceeds by registering a new statement under the same issuer and subject rather than by invalidating the old one, and that multiple issuers may make conflicting statements that relying parties resolve themselves." }, { "id": "SRC-093", "title": "Multi-Party Threshold Cryptography (NIST IR 8214 series project page)", "organization": "National Institute of Standards and Technology (NIST), Computer Security Division", "url": "https://csrc.nist.gov/projects/threshold-cryptography", "version_or_date": "NIST IR 8214C final, January 2026; project page current", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:34:00Z", "relevance": "States the interchangeability requirement that a threshold-produced signature must verify under the conventional verification algorithm, making it indistinguishable to a verifier from a single-party signature; the authority for separating threshold cryptography from M-of-N multi-signature participation." }, { "id": "SRC-094", "title": "The Idempotency-Key HTTP Header Field (draft-ietf-httpapi-idempotency-key-header)", "organization": "Internet Engineering Task Force (IETF), HTTP API Working Group", "url": "https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/", "version_or_date": "Revision 07, 15 October 2025; Internet-Draft, expired", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-09-04T09:36:00Z", "relevance": "Describes client-generated idempotency keys, server-side storage of the first result, replay of the stored response and rejection on request-fingerprint mismatch. Used only to name a common practice; it is an expired draft, so the normative anchor for retry safety remains RFC 9110." }, { "id": "SRC-095", "title": "ETSI TS 119 102-2 V1.3.1 Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report", "organization": "ETSI", "url": "https://www.etsi.org/deliver/etsi_ts/119100_119199/11910202/01.03.01_60/ts_11910202v010301p.pdf", "version_or_date": "V1.3.1 (2021-09)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:06:00Z", "relevance": "Defines the reportable structure of a validation result: per-signature validation report, validation status with main and sub indication, signature identifier, signer information, constraints evaluation report, validation time information and the validation objects (certificates, CRLs, OCSP responses, time-stamps, evidence records) used. Anchors the run-record and report-projection findings." }, { "id": "SRC-096", "title": "NIST Special Publication 800-131A Revision 2 Transitioning the Use of Cryptographic Algorithms and Key Lengths", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf", "version_or_date": "Revision 2, March 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:11:00Z", "relevance": "Acceptable, deprecated, disallowed and legacy-use categories and the asymmetry between signature generation and verification policy (for example SHA-1 disallowed for generation but permitted for legacy verification). Grounds algorithm-policy pinning and renewal-horizon calculation." }, { "id": "SRC-097", "title": "DSS Cookbook: Signature validation (esig/dss source documentation)", "organization": "European Commission, Digital Building Blocks (esig/dss project)", "url": "https://raw.githubusercontent.com/esig/dss/master/dss-cookbook/src/main/asciidoc/_chapters/signature-validation.adoc", "version_or_date": "master branch, accessed 2026-09-04", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-04T09:15:00Z", "relevance": "Enumerates validation levels (basic signatures, timestamps, long-term data, archival data), constraint groups, revocation freshness handling, cryptographic suite sunset dates with fail versus warn behaviour, and best-signature-time derivation. Used to identify operational parameters that must be pinned for a run to be reproducible." }, { "id": "SRC-098", "title": "ETSI TS 119 512 Electronic Signatures and Infrastructures (ESI); Protocols for trust service providers providing long-term data preservation services", "organization": "ETSI", "url": "https://www.etsi.org/deliver/etsi_ts/119500_119599/119512/01.02.01_60/ts_119512v010201p.pdf", "version_or_date": "V1.2.1 (2023-05)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-04T09:17:30Z", "relevance": "Protocol surface of a preservation service, including preservation object identifiers, evidence retrieval and deletion operations. Used to justify holding a stable external preservation identifier and to keep preservation execution and deletion outside this model. Direct automated download was refused, so no clause-level conformance is claimed." } ], "structure": { "bundles": [ { "id": "sig-core-bundle-proof-constitution", "name": "Proof constitution and cryptographic method", "description": "What a proof instance is as a record: its identity and host binding, its kind, its own state, and the method, parameters, value and verification-method reference that make it re-verifiable.", "rationale": "Every consulted container standard models a proof as a structured object carrying an identifier or signer reference, a type or cryptosuite, an algorithm identifier, a value and a key reference. Making these first-class, format-neutral fields is the precondition for any downstream reasoning about a proof.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008" ], "layers": [ { "id": "sig-core-layer-proof-identity-and-kind", "name": "Proof identity, kind and state", "description": "Identifies a proof instance independently of its host, its value and any timestamp; classifies the kind of proof it is; and records the state of the proof record itself.", "source_refs": [ "SRC-004", "SRC-006", "SRC-011" ], "findings": [ { "id": "sig-core-find-proof-record-identity", "name": "Proof instance identity and host binding", "description": "A proof is an identified value bound to exactly one host representation. Identity comes from the producing system or a governed IRI; a signing time, a file name or the proof value alone never designates the record.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007" ], "questions": [ { "id": "sig-core-q-proof-identifier", "text": "Which identifier authoritatively designates this proof instance, and which system assigned it?", "kind": "identity", "answer_data": [ "proof identifier value", "assigning system reference", "identifier scheme code", "reason code when a Dimension-minted identifier is used" ] }, { "id": "sig-core-q-proof-host-binding", "text": "Which host record or representation is this proof bound to, and is the binding enveloped, enveloping, detached or internally detached?", "kind": "relationship", "answer_data": [ "host resource reference", "binding mode code", "covered representation descriptor" ] }, { "id": "sig-core-q-proof-definition-boundary", "text": "What distinguishes this proof record from the host content it protects and from the verification material it merely references?", "kind": "definition", "answer_data": [ "proof record scope note", "excluded material list", "reference-only field list" ] }, { "id": "sig-core-q-proof-record-revision", "text": "How is a revision of the proof record distinguished from a newly created proof over the same host?", "kind": "provenance", "answer_data": [ "record version value", "supersedes reference", "creation basis code" ] } ], "data_elements": [ { "id": "sig-core-de-proof-id", "name": "Proof identifier", "description": "Identifier that designates this proof instance, assigned according to the model identity priority.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-proof-host-ref", "name": "Host representation reference", "description": "Reference to the host record, document or content stream that this proof covers.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "sig-core-de-proof-binding-mode", "name": "Binding mode", "description": "Coded attachment relationship between the proof and the host: enveloped, enveloping, detached or internally detached.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-006" ] }, { "id": "sig-core-de-proof-record-version", "name": "Proof record version", "description": "Version of the proof record's metadata, distinct from the immutable cryptographic content it describes.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-proof-supersedes-ref", "name": "Superseded proof reference", "description": "Reference to a prior proof record that this record replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Identity and host binding are pure reference and descriptor fields carried on or beside the host record. They have no independent serialized form of their own: the only serialized object involved is the proof value, which is declared as an artifact in the proof value and containment finding. Materializing an artifact here would either duplicate the host document, which this model does not own, or fork the serialized proof." }, { "id": "sig-core-find-proof-kind-classification", "name": "Proof kind classification", "description": "Classifies the instance as an asymmetric digital signature, a symmetric MAC, an unkeyed digest, an electronic seal, a time-stamp token, a selective-disclosure proof or a zero-knowledge attestation, because the properties each kind can support differ materially.", "source_refs": [ "SRC-006", "SRC-008", "SRC-009", "SRC-010", "SRC-011" ], "questions": [ { "id": "sig-core-q-proof-kind-value", "text": "Which proof kind does this instance belong to, drawn from a governed enumeration that keeps signature, MAC, digest, seal, time-stamp token and selective-disclosure proof distinct?", "kind": "classification", "answer_data": [ "proof kind code", "enumeration scheme reference" ] }, { "id": "sig-core-q-kind-origination-capability", "text": "Does the chosen kind support data-origin attribution provable to a third party, or only integrity and shared-key authentication?", "kind": "constraint", "answer_data": [ "origination capability code", "third-party provability flag", "justification note" ] }, { "id": "sig-core-q-kind-qualification-claim", "text": "What regime-specific qualification, if any, is claimed for this kind, and which authority defines that qualification?", "kind": "authority", "answer_data": [ "qualification claim code", "defining authority reference", "trusted-list reference" ] }, { "id": "sig-core-q-kind-external-type", "text": "Which external type identifier, object identifier or cryptosuite name expresses this kind in the container format in use?", "kind": "interoperability", "answer_data": [ "external type identifier", "identifier namespace", "container profile code" ] } ], "data_elements": [ { "id": "sig-core-de-proof-kind-code", "name": "Proof kind code", "description": "Coded kind of proof, keeping digital signature, MAC, digest, seal, time-stamp token, selective-disclosure proof and zero-knowledge attestation distinct.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-011" ] }, { "id": "sig-core-de-origination-capability", "name": "Origination capability", "description": "Whether the kind can support third-party-provable data origination, only limited origination, or none.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "sig-core-de-qualification-claim", "name": "Regime qualification claim", "description": "Optional claim that the proof meets a regulated category such as advanced or qualified signature, seal or time stamp.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "sig-core-de-external-type-identifier", "name": "External type identifier", "description": "Container-native type identifier, object identifier or cryptosuite name expressing the kind.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Classification is a set of coded values drawn from external registries and regulatory vocabularies. The authoritative definitions live in those registries; producing a local artifact would fork registry-owned content and create a stale parallel vocabulary that an agent could mistake for normative." }, { "id": "sig-core-find-proof-state", "name": "Proof record state and permitted transitions", "description": "The state of the proof record itself — drafted, issued, attached, superseded, withdrawn or flagged as having unverifiable material — kept strictly distinct from key revocation, credential status and host document status.", "source_refs": [ "SRC-004", "SRC-013" ], "questions": [ { "id": "sig-core-q-proof-state-value", "text": "Which state does this proof record currently hold, and what is the permitted transition set from that state?", "kind": "state", "answer_data": [ "proof state code", "permitted transition list", "state entered instant" ] }, { "id": "sig-core-q-proof-state-events", "text": "Which events cause a state transition, and which of those events originate outside this model?", "kind": "lifecycle", "answer_data": [ "transition event code", "originating model reference", "internal or external flag" ] }, { "id": "sig-core-q-proof-withdrawal", "text": "How is withdrawal of a proof recorded without asserting revocation of the underlying key or credential?", "kind": "exception", "answer_data": [ "withdrawal reason code", "withdrawal instant", "explicit non-assertion note" ] }, { "id": "sig-core-q-proof-state-authority", "text": "Who is entitled to change the state of this proof record, and under what authority?", "kind": "authority", "answer_data": [ "authorised role", "authority reference", "change actor reference" ] } ], "data_elements": [ { "id": "sig-core-de-proof-state", "name": "Proof record state", "description": "Current state of the proof record within its own lifecycle.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-state-changed-at", "name": "State change instant", "description": "Instant at which the current state was entered, recorded as an event time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "sig-core-de-state-change-reason", "name": "State change reason", "description": "Reason recorded for the most recent state transition, including explicit non-assertions.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-state-change-actor-ref", "name": "State change actor reference", "description": "Reference to the actor that performed the state transition; the actor record is owned elsewhere.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "State is a coded field plus a transition history held inline on the record. The externally produced evidence that motivates a transition — a revocation notice, a validation report, a retention decision — belongs to the credential, validation and retention models respectively, so no artifact is materialized here." } ] }, { "id": "sig-core-layer-method-and-value", "name": "Method, parameters, value and verification-method reference", "description": "The cryptographic method identifiers and parameters, the proof value with its encoding and coverage, and the reference that points at the material needed to verify.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-007", "SRC-008" ], "findings": [ { "id": "sig-core-find-method-and-parameters", "name": "Method, algorithm identifiers and parameters", "description": "Records the algorithm or cryptosuite identifier, hash function, parameter set and variant options needed to reproduce verification, and the strength claim against which algorithm sunset constraints are assessed.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-007", "SRC-013" ], "questions": [ { "id": "sig-core-q-method-identifier", "text": "Which algorithm or cryptosuite identifier, in which registry, states the method that produced this proof?", "kind": "definition", "answer_data": [ "method identifier value", "registry reference", "identifier version" ] }, { "id": "sig-core-q-method-parameters", "text": "Which parameter values must be known to reproduce verification, including hash function, parameter set, curve, salt length, context string and any pre-hash variant?", "kind": "requirement", "answer_data": [ "hash identifier", "parameter set code", "context string", "pre-hash variant flag" ] }, { "id": "sig-core-q-method-strength", "text": "What security strength or parameter category does the method claim, and against which published sunset or deprecation date is it assessed?", "kind": "measurement", "answer_data": [ "claimed security category", "assessed-against constraint reference", "sunset date" ] }, { "id": "sig-core-q-method-substitution", "text": "Is the method identifier itself cryptographically covered by the proof, so that algorithm substitution can be detected?", "kind": "security", "answer_data": [ "method protected flag", "covering field reference", "rejection rule for unsecured methods" ] } ], "data_elements": [ { "id": "sig-core-de-method-identifier", "name": "Method identifier", "description": "Registry-scoped identifier of the signature algorithm or cryptosuite used.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "sig-core-de-hash-identifier", "name": "Hash function identifier", "description": "Identifier of the digest algorithm applied to the covered representation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "sig-core-de-method-parameters", "name": "Method parameters", "description": "Structured parameter values needed to reproduce verification, such as parameter set, curve, salt length, context string or pre-hash variant.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "sig-core-de-claimed-security-category", "name": "Claimed security category", "description": "Security strength or category claimed for the parameter set in use.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "sig-core-de-method-protected-flag", "name": "Method identifier protected flag", "description": "Whether the method identifier is inside the cryptographically protected portion of the proof.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Method and parameter fields are coded values whose authoritative definitions are maintained by algorithm standards bodies and protocol registries. Copying algorithm specifications into a local artifact would create a divergent and unmaintainable second source for content this model explicitly does not own." }, { "id": "sig-core-find-proof-value-and-containment", "name": "Proof value, encoding and coverage", "description": "The proof value octets, the encoding and container serialization that carries them, and which header or attribute fields the value cryptographically covers versus which travel unprotected.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008", "SRC-010" ], "questions": [ { "id": "sig-core-q-proof-value-encoding", "text": "In which encoding and container serialization is the proof value recorded, and does that serialization permit a detached payload?", "kind": "interoperability", "answer_data": [ "proof value encoding code", "container profile code", "detached payload permitted flag" ] }, { "id": "sig-core-q-protected-coverage", "text": "Which header, attribute or metadata fields are cryptographically covered by this proof value, and which are unprotected?", "kind": "composition", "answer_data": [ "protected parameter list", "unprotected parameter list", "coverage determination basis" ] }, { "id": "sig-core-q-value-security-rules", "text": "Which values must be rejected outright, such as an unsecured or none algorithm, an ambiguous canonical form, or a value whose covered representation cannot be reconstructed?", "kind": "security", "answer_data": [ "rejection rule list", "ambiguity condition list" ] }, { "id": "sig-core-q-value-storage-integrity", "text": "How is the stored proof value shown to be byte-identical to the value captured at registration?", "kind": "quality", "answer_data": [ "capture digest algorithm", "capture digest value", "re-check outcome" ] } ], "data_elements": [ { "id": "sig-core-de-proof-value", "name": "Proof value", "description": "The byte-exact proof value as produced by the signing or proving process.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "sig-core-de-proof-value-encoding", "name": "Proof value encoding", "description": "Encoding applied to the proof value, such as a base encoding or a binary object encoding.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "sig-core-de-container-profile", "name": "Container profile", "description": "Container serialization profile that carries the proof value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-protected-parameter-set", "name": "Protected parameter set", "description": "The set of fields cryptographically covered by the proof value.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-core-de-unprotected-parameter-set", "name": "Unprotected parameter set", "description": "The set of fields carried alongside the proof but not covered by it.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "sig-core-de-capture-digest", "name": "Capture digest", "description": "Digest algorithm and value computed over the serialized proof at capture, used to detect storage-side alteration.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "sig-core-art-serialized-proof", "name": "Serialized proof object", "description": "The byte-exact serialized proof as emitted by the signing or proving process, retained unaltered because any re-serialization destroys verifiability.", "media_or_form": [ "JWS Compact Serialization", "JWS JSON Serialization", "CMS SignedData (DER)", "COSE_Sign or COSE_Sign1 (CBOR)", "DataIntegrityProof object embedded in a host document", "SD-JWT combined format with disclosures" ], "serial": false, "identity_strategy": "Designated by the identifier of its parent proof record plus the container profile code, and content-addressed by the capture digest over its exact octets. The digest is an attribute, not the designator.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "sig-core-find-verification-method-binding", "name": "Verification-method reference and binding", "description": "How the proof nominates the public key, certificate, verification method or key-binding confirmation needed to verify it, carried strictly as a reference with coverage metadata and no imported key or credential ownership.", "source_refs": [ "SRC-004", "SRC-007", "SRC-010", "SRC-006" ], "questions": [ { "id": "sig-core-q-verification-method-ref", "text": "Which verification method does this proof nominate, and in which resolvable reference form is it expressed?", "kind": "relationship", "answer_data": [ "verification method reference", "reference form code", "resolution endpoint reference" ] }, { "id": "sig-core-q-key-controller", "text": "Which controller or holder is asserted to control that verification method, and who makes that assertion?", "kind": "ownership", "answer_data": [ "controller reference", "asserting party reference", "assertion basis code" ] }, { "id": "sig-core-q-embedded-hints", "text": "Which verification material travels embedded as a hint rather than being resolved, and is that hint covered by the proof?", "kind": "evidence", "answer_data": [ "embedded hint set", "hint covered flag", "resolution preference rule" ] }, { "id": "sig-core-q-binding-trust-gap", "text": "What does this reference deliberately not establish about the key's trustworthiness, currency or revocation state?", "kind": "constraint", "answer_data": [ "explicit non-establishment list", "owning model reference", "consumer warning text" ] } ], "data_elements": [ { "id": "sig-core-de-verification-method-ref", "name": "Verification method reference", "description": "Reference to the public key, certificate or verification method required to verify the proof.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "sig-core-de-verification-method-form", "name": "Verification method reference form", "description": "Form of the reference, such as an issuer-and-serial reference, a key identifier, a certificate thumbprint, a key-set URL or a controller-document verification method URL.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "sig-core-de-key-controller-ref", "name": "Verification method controller reference", "description": "Reference to the party asserted to control the verification method.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-embedded-hint-set", "name": "Embedded verification hint set", "description": "Verification material carried inline as a hint, together with a flag stating whether the hint is covered by the proof.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "sig-core-de-key-binding-confirmation-ref", "name": "Key-binding confirmation reference", "description": "Reference to a holder key confirmation used by selective-disclosure presentations to bind a presentation to a holder key.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "The verification material itself — keys, certificates, controller documents, trusted lists — is created, published, rotated and revoked by the key and credential models. This finding carries only a reference, its form and its coverage flag. Materializing an artifact would copy externally governed material into this model and create a stale trust surface that could be relied on after the source had been revoked." } ] } ] }, { "id": "sig-core-bundle-attribution-and-meaning", "name": "Signer attribution and asserted meaning", "description": "Who the proof is attributed to, in which capacity and on whose behalf, for what declared purpose, and precisely which security and legal properties it does and does not assert.", "rationale": "Primary sources consistently state that a cryptographically successful check establishes only that a known key was used over unmodified data. Attribution to a party, the purpose of signing, and any legal effect are separate claims requiring separate evidence, so they are modelled as separate declarations rather than as consequences of verification.", "source_refs": [ "SRC-004", "SRC-007", "SRC-003", "SRC-011", "SRC-012" ], "layers": [ { "id": "sig-core-layer-signer-attribution", "name": "Signer roles and capacity", "description": "Separates the party a proof claims as signer, the actor that operated the signing process, the controller of the verification method, the subject of any credential, and the identity actually established by a completed verification.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-011" ], "findings": [ { "id": "sig-core-find-signer-role-separation", "name": "Claimed, operating, controlling and verified signer roles", "description": "Five roles that are routinely conflated are kept apart: claimed signer, signing actor, verification-method controller, credential subject, and the verified signer identity that only a completed verification can establish.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-007" ], "questions": [ { "id": "sig-core-q-claimed-signer", "text": "Which party does the proof claim as its signer, and in which field is that claim carried?", "kind": "identity", "answer_data": [ "claimed signer reference", "carrying field reference", "claim covered flag" ] }, { "id": "sig-core-q-signing-actor", "text": "Which actor or system operated the signing process, and is it distinct from the claimed signer?", "kind": "provenance", "answer_data": [ "signing actor reference", "distinct-from-claimed flag", "operating environment reference" ] }, { "id": "sig-core-q-verified-signer", "text": "Which signer identity, if any, was actually established by a completed verification, and against which verification method?", "kind": "validation", "answer_data": [ "verified signer reference", "establishing verification reference", "verification method used" ] }, { "id": "sig-core-q-role-conflict", "text": "How is a discrepancy between claimed signer, credential subject and verified identity recorded rather than silently resolved?", "kind": "exception", "answer_data": [ "discrepancy code", "affected role list", "handling rule reference" ] }, { "id": "sig-core-q-role-record-ownership", "text": "Which external party records are referenced for each role, and which model owns each of them?", "kind": "ownership", "answer_data": [ "role to reference map", "owning model reference per role" ] } ], "data_elements": [ { "id": "sig-core-de-claimed-signer-ref", "name": "Claimed signer reference", "description": "Reference to the party the proof claims as signer, as carried in the proof.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-011" ] }, { "id": "sig-core-de-signing-actor-ref", "name": "Signing actor reference", "description": "Reference to the actor or system that operated the signing process.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "sig-core-de-credential-subject-ref", "name": "Credential subject reference", "description": "Reference to the subject of any credential invoked in relation to the proof; the credential itself is owned elsewhere.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "sig-core-de-verified-signer-ref", "name": "Verified signer reference", "description": "Reference to the signer identity established by a completed verification, populated only when such a verification has been recorded.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-attribution-discrepancy", "name": "Attribution discrepancy code", "description": "Coded record of a mismatch between claimed signer, credential subject and verified identity.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "All five roles resolve to references into party, credential and verification models that this mixin does not own. The finding contributes the separation and the discrepancy record, both of which are inline fields; creating an artifact would imply this model holds authoritative party or credential content." }, { "id": "sig-core-find-signer-capacity-and-representation", "name": "Signer capacity and on-behalf-of representation", "description": "Whether the signer is a natural person, a legal person, a device or an automated agent, in what stated capacity, and whether the proof is made on behalf of another party under an external mandate.", "source_refs": [ "SRC-011", "SRC-005", "SRC-013" ], "questions": [ { "id": "sig-core-q-signer-party-type", "text": "Is the signer a natural person, a legal person, a device or an automated agent, and does that choice change the applicable proof kind?", "kind": "classification", "answer_data": [ "signer party type code", "implied proof kind constraint", "regime note" ] }, { "id": "sig-core-q-stated-capacity", "text": "In what stated role or capacity is the signer acting, as declared within the proof?", "kind": "definition", "answer_data": [ "stated capacity text", "capacity vocabulary reference", "capacity covered flag" ] }, { "id": "sig-core-q-on-behalf-of", "text": "Is the proof made on behalf of another party, and which reference records the represented party?", "kind": "relationship", "answer_data": [ "represented party reference", "representation type code" ] }, { "id": "sig-core-q-mandate-evidence", "text": "Which external mandate, delegation or authority record is cited for the representation, and is it evaluated anywhere in this record?", "kind": "authority", "answer_data": [ "mandate evidence reference", "owning model reference", "evaluated-here flag set to false" ] } ], "data_elements": [ { "id": "sig-core-de-signer-party-type", "name": "Signer party type", "description": "Coded type of the signing party: natural person, legal person, device or automated agent.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "sig-core-de-stated-capacity", "name": "Stated signing capacity", "description": "Role or capacity the signer declares within the proof.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-represented-party-ref", "name": "Represented party reference", "description": "Reference to the party on whose behalf the proof is made.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "sig-core-de-mandate-evidence-ref", "name": "Mandate evidence reference", "description": "Reference to the external mandate or authority record cited for the representation, carried without evaluation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Capacity and representation are claims expressed as coded values and references. The mandate, power of attorney or authorization record that would substantiate a representation is created, maintained and evaluated by the authority and credential models, so this finding deliberately holds no local artifact that could be mistaken for that evidence." } ] }, { "id": "sig-core-layer-asserted-meaning", "name": "Proof purpose and asserted properties", "description": "The declared reason a proof was created and the explicit, individually declared statement of which security and legal properties it supports and which it does not.", "source_refs": [ "SRC-004", "SRC-003", "SRC-008", "SRC-011", "SRC-012" ], "findings": [ { "id": "sig-core-find-proof-purpose-and-commitment", "name": "Proof purpose, commitment type and scope of use", "description": "Records the declared reason for the proof — such as authentication, assertion, capability invocation or delegation, or a commitment type such as proof of origin, receipt or approval — with the domain, challenge and nonce that limit where it may be accepted.", "source_refs": [ "SRC-004", "SRC-013" ], "questions": [ { "id": "sig-core-q-declared-purpose", "text": "Which declared proof purpose or commitment type does this proof carry, and from which governed vocabulary is it drawn?", "kind": "classification", "answer_data": [ "proof purpose code", "commitment type code", "vocabulary reference" ] }, { "id": "sig-core-q-purpose-scope-limits", "text": "Which security domain, audience or challenge limits the contexts in which this proof may be accepted?", "kind": "constraint", "answer_data": [ "security domain values", "challenge value", "nonce value", "replay limitation note" ] }, { "id": "sig-core-q-purpose-check-ownership", "text": "Which party checks that the declared purpose matches the intended use, and where is that check performed?", "kind": "process", "answer_data": [ "checking party reference", "checking model reference", "performed-here flag set to false" ] }, { "id": "sig-core-q-purpose-absent", "text": "How is a proof handled when no purpose is declared or the declared purpose is unrecognised?", "kind": "exception", "answer_data": [ "missing purpose handling rule", "unrecognised purpose handling rule" ] } ], "data_elements": [ { "id": "sig-core-de-proof-purpose", "name": "Proof purpose", "description": "Declared reason the proof was created, drawn from a governed purpose vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-commitment-type", "name": "Commitment type", "description": "Signed indication of signer intent, such as proof of origin, receipt, delivery or approval.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-security-domain", "name": "Security domain", "description": "Domain or audience within which the proof is intended to be accepted.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-challenge-value", "name": "Challenge value", "description": "One-time value supplied by a relying party to limit replay of the proof.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-nonce-value", "name": "Nonce value", "description": "Random value included to reduce linkability or to bind a presentation to an exchange.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Purpose, commitment and scope limiters are inline coded and literal values carried within the proof structure. The signature policy or validation policy that gives a commitment type its operational meaning is authored and evaluated by the validation-policy model, so no local artifact is produced for it." }, { "id": "sig-core-find-asserted-property-separation", "name": "Separation of asserted security and legal properties", "description": "Per-property declaration of integrity, authenticity, origin attribution, approval, authorization, non-repudiation support and legal effect, each with its own basis and evidence reference, so that a successful cryptographic check is never read as asserting all of them.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-008", "SRC-011", "SRC-012" ], "questions": [ { "id": "sig-core-q-property-set", "text": "Which of integrity, authenticity, origin attribution, approval, authorization, non-repudiation support and legal effect does this proof actually assert?", "kind": "requirement", "answer_data": [ "asserted property list", "per-property assertion flag" ] }, { "id": "sig-core-q-property-basis", "text": "For each asserted property, is the basis the cryptographic check, a declared purpose, an external policy, or an external legal determination?", "kind": "evidence", "answer_data": [ "per-property basis code", "supporting evidence reference", "evidence sufficiency note" ] }, { "id": "sig-core-q-property-nonassertion", "text": "Which properties are explicitly not asserted, and how is that non-assertion made machine-readable to a consumer?", "kind": "constraint", "answer_data": [ "non-asserted property list", "consumer-visible non-assertion field" ] }, { "id": "sig-core-q-nonrepudiation-conditions", "text": "What additional conditions must hold before non-repudiation support may be claimed, given that a signature alone does not establish when it was created?", "kind": "quality", "answer_data": [ "required condition list", "trusted time evidence reference", "key control assurance reference" ] }, { "id": "sig-core-q-legal-effect-owner", "text": "Which applicable law or forum determines legal effect, and why is that determination excluded from this record?", "kind": "ownership", "answer_data": [ "applicable law reference", "forum reference", "exclusion rationale note" ] } ], "data_elements": [ { "id": "sig-core-de-asserted-property", "name": "Asserted property", "description": "One security or legal property the proof asserts, declared individually rather than inferred.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "sig-core-de-property-basis", "name": "Property basis", "description": "Basis on which each asserted property rests: cryptographic check, declared purpose, external policy or external legal determination.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "sig-core-de-non-asserted-property", "name": "Explicitly non-asserted property", "description": "Property the proof explicitly does not assert, recorded so consumers cannot infer it.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "sig-core-de-legal-effect-forum-ref", "name": "Legal effect forum reference", "description": "Reference to the applicable law or forum that would determine legal effect; the determination itself is out of boundary.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "This finding contributes a structured declaration matrix held inline on the proof record. Every substantiating item it points at — a validation report, a policy, a trusted time attestation, a court or regulatory determination — is produced and owned by another model, so declaring a local artifact would misrepresent the record as evidence rather than as a set of scoped claims." } ] } ] }, { "id": "sig-core-bundle-composition-time-status", "name": "Proof composition, time claims and recorded status", "description": "How multiple proofs relate to one another, what a proof claims about time, and how a verification outcome produced elsewhere is recorded against the proof.", "rationale": "Container standards distinguish unordered proof sets from ordered chains and countersignatures; timeliness guidance separates signer-asserted time from externally attested proof of existence; and verification results are defined structures produced by a validation application outside the proof itself.", "source_refs": [ "SRC-004", "SRC-006", "SRC-003", "SRC-009", "SRC-013" ], "layers": [ { "id": "sig-core-layer-proof-composition", "name": "Composition, cardinality and dependency", "description": "Cardinality and dependency rules distinguishing single proofs, independent co-signature sets, ordered countersignatures and chains, endorsements, and threshold or multi-party proofs.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008" ], "findings": [ { "id": "sig-core-find-composition-pattern-and-cardinality", "name": "Multi-proof composition patterns", "description": "Distinguishes an unordered set of independent proofs over the same content, an ordered chain in which each proof covers the previous one, an endorsement that signs another proof's value rather than the content, and a threshold or multi-party proof that yields one proof from several participants.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008" ], "questions": [ { "id": "sig-core-q-composition-pattern", "text": "Which composition pattern applies here: single proof, unordered co-signature set, ordered chain, endorsement of another proof, or threshold and multi-party proof?", "kind": "composition", "answer_data": [ "composition pattern code", "pattern rationale note" ] }, { "id": "sig-core-q-composition-dependency", "text": "Which earlier proof does this proof depend on, and does it cover that proof's value or only the same underlying content?", "kind": "relationship", "answer_data": [ "previous proof reference", "covers-previous-value flag", "dependency edge list" ] }, { "id": "sig-core-q-composition-cardinality", "text": "What minimum and maximum number of participating proofs or parties satisfies the requirement, and is a partial set meaningful on its own?", "kind": "constraint", "answer_data": [ "required participant count", "participant total", "partial set meaningfulness rule" ] }, { "id": "sig-core-q-partial-failure", "text": "How is the outcome recorded when some members of a set verify successfully and others do not?", "kind": "exception", "answer_data": [ "per-member outcome list", "aggregate handling rule", "threshold satisfied flag" ] }, { "id": "sig-core-q-order-evidence", "text": "What evidence establishes the claimed order of a chain, given that a signer-supplied time does not?", "kind": "evidence", "answer_data": [ "order evidence type", "covering proof reference", "proof-of-existence reference" ] } ], "data_elements": [ { "id": "sig-core-de-composition-pattern", "name": "Composition pattern", "description": "Coded pattern describing how this proof relates to other proofs over the same host.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "sig-core-de-previous-proof-ref", "name": "Previous proof reference", "description": "Reference to a proof this proof depends on or covers, establishing chain or endorsement order.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "sig-core-de-member-proof-ref", "name": "Member proof reference", "description": "Reference to a member proof of a composite set or chain.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-core-de-required-participant-count", "name": "Required participant count", "description": "Minimum number of participating proofs or parties that must be present for the composite to be satisfied.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-participant-total", "name": "Participant total", "description": "Total number of participants defined for a threshold or multi-party arrangement.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-threshold-satisfied", "name": "Threshold satisfied flag", "description": "Whether the declared participation threshold has been met by recorded member proofs.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "sig-core-art-proof-composition-manifest", "name": "Proof set or chain manifest", "description": "A manifest listing the member proofs of a composite proof, their dependency edges, their order where ordering applies, and the satisfied participation threshold.", "media_or_form": [ "proof array within an embedded-proof host document", "JWS JSON Serialization signatures array", "CMS SignerInfos collection with countersignature unsigned attributes", "container manifest listing member proof identifiers and edges" ], "serial": true, "identity_strategy": "Designated by the composite proof identifier. Ordered members carry a zero-padded sequence index appended to that identifier reflecting dependency order only; the index never encodes a date, a signer name or a status.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-core-layer-time-and-status", "name": "Time claims and recorded verification status", "description": "Separates a signer-asserted signing instant from externally attested proof of existence, and from the recorded status of a verification performed by another party.", "source_refs": [ "SRC-003", "SRC-004", "SRC-009", "SRC-013" ], "findings": [ { "id": "sig-core-find-signing-instant-claim", "name": "Claimed signing instant and proof-of-existence reference", "description": "The signing time inside a proof is a signer claim, not evidence. It is recorded as a claim alongside any declared expiry, references to external proof-of-existence evidence, and the separate instant at which this record observed the proof.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006", "SRC-009" ], "questions": [ { "id": "sig-core-q-claimed-instant", "text": "What instant does the proof claim as its creation time, and in which time representation is that claim expressed?", "kind": "temporal", "answer_data": [ "claimed signing instant", "source field reference", "claim covered flag" ] }, { "id": "sig-core-q-time-evidence", "text": "Which external proof-of-existence evidence corroborates the claimed instant, and precisely what does that evidence attest?", "kind": "evidence", "answer_data": [ "proof-of-existence reference", "attested instant", "attestation scope note" ] }, { "id": "sig-core-q-validity-window", "text": "Does the proof declare an expiry or validity window, and how does that differ from the host record's own validity period?", "kind": "constraint", "answer_data": [ "proof expiry instant", "host validity reference", "independence note" ] }, { "id": "sig-core-q-observation-time", "text": "At what instant was this proof observed or ingested, and how is that kept distinct from the claimed signing instant?", "kind": "provenance", "answer_data": [ "record observation instant", "ingesting system reference", "separation rule reference" ] }, { "id": "sig-core-q-time-reliance-decision", "text": "Under what conditions may the claimed instant be relied upon, and who makes that decision?", "kind": "decision", "answer_data": [ "reliance condition list", "deciding party reference", "trust basis code" ] } ], "data_elements": [ { "id": "sig-core-de-claimed-signing-instant", "name": "Claimed signing instant", "description": "Signer-asserted creation time of the proof, stored as an unverified claim.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "sig-core-de-proof-expires-at", "name": "Proof expiry instant", "description": "Instant after which the proof declares itself no longer usable, independent of host record validity.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-core-de-proof-of-existence-ref", "name": "Proof-of-existence reference", "description": "Reference to external evidence, such as a time-stamp token, attesting that the proof or its content existed before a stated instant.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-013" ] }, { "id": "sig-core-de-record-observed-at", "name": "Record observation instant", "description": "Instant at which this model captured or ingested the proof, always recorded separately from any claimed event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "sig-core-de-time-claim-trust-basis", "name": "Time claim trust basis", "description": "Coded basis on which the claimed instant may be relied upon, such as signer assertion only or corroborated by external attestation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Time-stamp tokens and other proof-of-existence evidence are generated and signed by a time-stamping authority and are themselves separate proof instances governed by their own issuing model. Materializing them here would take ownership of an external trust service's output, so this finding holds only the claimed instant, the observation instant, declared expiry and references." }, { "id": "sig-core-find-verification-status-record", "name": "Recorded verification status", "description": "An explicit, never-defaulted status carried against the proof: the outcome an external verifier returned, when it was evaluated, under which referenced policy, what it covered, and how long it may be relied on.", "source_refs": [ "SRC-004", "SRC-013", "SRC-005" ], "questions": [ { "id": "sig-core-q-status-value", "text": "What explicit verification status does this record carry, drawn from an enumeration that includes not-yet-verified and an indeterminate outcome?", "kind": "state", "answer_data": [ "verification status code", "sub-status code", "enumeration reference" ] }, { "id": "sig-core-q-status-provenance", "text": "Which verifier produced this outcome, at which evaluation instant, and under which referenced validation policy?", "kind": "provenance", "answer_data": [ "verifier reference", "evaluation instant", "validation policy reference" ] }, { "id": "sig-core-q-status-staleness", "text": "For how long may a recorded outcome be relied on before re-verification is required, and what invalidates it earlier?", "kind": "quality", "answer_data": [ "status valid-until instant", "invalidating condition list", "re-verification trigger" ] }, { "id": "sig-core-q-status-scope", "text": "Which checks does the recorded outcome cover, and which checks were outside the verifier's declared scope?", "kind": "constraint", "answer_data": [ "covered check list", "out-of-scope check list", "coverage caveat note" ] }, { "id": "sig-core-q-status-access", "text": "Who may read or write the recorded status, and what must be captured whenever it changes?", "kind": "access", "answer_data": [ "read scope", "write role", "required change record fields" ] } ], "data_elements": [ { "id": "sig-core-de-verification-status", "name": "Verification status", "description": "Explicit outcome recorded against the proof, including not-yet-verified, passed, failed and indeterminate.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-004" ] }, { "id": "sig-core-de-verification-substatus", "name": "Verification sub-status", "description": "Finer-grained sub-indication accompanying a failed or indeterminate outcome.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-verification-evaluated-at", "name": "Verification evaluation instant", "description": "Instant at which the external verification was performed, recorded as the event time of that check.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-verifier-ref", "name": "Verifier reference", "description": "Reference to the party or application that produced the recorded outcome.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-validation-policy-ref", "name": "Validation policy reference", "description": "Reference to the validation policy or constraint set the verifier applied; the policy is owned by the validation model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-validation-report-ref", "name": "Validation report reference", "description": "Reference to the externally produced validation report that details the outcome.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-core-de-status-valid-until", "name": "Status reliance limit", "description": "Instant beyond which the recorded outcome must not be relied on without re-verification.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The authoritative validation report is generated by a signature validation application under a validation policy owned by the validation model, and the record of who checked what and when belongs to the referenced audit model. Reproducing either here would claim ownership of evaluation and of an audit trail, so this finding carries only inline status fields and references to the external report and policy." } ] } ] }, { "id": "sig-payload-protected-object", "name": "Protected object and binding evidence", "description": "What is placed under protection, how the protected representation is identified, whether it is bound directly or by digest, and over which scope the binding evidence was produced.", "rationale": "Every cited signature standard begins by fixing an unambiguous protected input: CMS fixes an encapsulated content type with a message-digest attribute, JWS fixes a concatenated signing input, COSE fixes a Sig_structure, XML Signature fixes Reference digests inside SignedInfo, Data Integrity fixes a transformed and hashed document, and C2PA requires at least one hard binding. Grouping subject, descriptor, binding mode, digest evidence and scope reflects that shared normative core while leaving the host and the cryptography outside.", "source_refs": [ "SRC-007", "SRC-006", "SRC-008", "SRC-016", "SRC-004", "SRC-017" ], "layers": [ { "id": "sig-payload-subject-anchoring", "name": "Protected subject anchoring", "description": "Non-owning declaration of the unit placed under protection and of the specific representation, version and type that the binding pins.", "source_refs": [ "SRC-006", "SRC-016", "SRC-004" ], "findings": [ { "id": "sig-payload-subject-declaration", "name": "Protected subject declaration", "description": "States exactly which host statement, artifact version, field set, named graph or event occurrence is placed under protection, the topology of the proof relative to it (enveloped, enveloping or detached), and which parts of the host record are deliberately outside the protected subject. The host reference is carried; the host is never owned.", "source_refs": [ "SRC-006", "SRC-008", "SRC-016", "SRC-004" ], "questions": [ { "id": "sig-payload-q-subject-unit", "text": "Which single unit - host statement, artifact version, field set, named graph or event occurrence - is placed under protection by this proof?", "kind": "definition", "answer_data": [ "protected subject kind code", "subject boundary statement", "host record reference" ] }, { "id": "sig-payload-q-subject-host-link", "text": "Through which reference is the protected unit reached without this model assuming the host's storage or lifecycle?", "kind": "relationship", "answer_data": [ "host model identifier", "host record reference", "reference resolution contract" ] }, { "id": "sig-payload-q-subject-topology", "text": "Is the proof enveloped within, enveloping over, or detached from the protected unit, and where does its carrier sit?", "kind": "classification", "answer_data": [ "envelope topology code", "carrier location reference", "detachment note" ] }, { "id": "sig-payload-q-subject-multiplicity", "text": "When more than one payload unit is covered by a single proof, how is each unit bound and enumerated separately?", "kind": "composition", "answer_data": [ "ordered reference list", "per-reference binding descriptor identifier", "aggregation rule" ] }, { "id": "sig-payload-q-subject-exclusions", "text": "Which parts of the host record are deliberately not part of the protected subject at all?", "kind": "constraint", "answer_data": [ "excluded part list", "exclusion justification", "responsible owner reference" ] } ], "data_elements": [ { "id": "sig-payload-de-subject-kind", "name": "Protected subject kind", "description": "Classifier for the protected unit: statement, artifact version, field set, named graph, event occurrence or opaque octet sequence.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-016", "SRC-004" ] }, { "id": "sig-payload-de-host-reference", "name": "Host record reference", "description": "Non-owning reference to the host record or records that carry the protected unit, resolvable through the referenced host model.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "sig-payload-de-envelope-topology", "name": "Envelope topology", "description": "Whether the proof is enveloped, enveloping or detached relative to the protected unit.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "sig-payload-de-subject-boundary-note", "name": "Subject boundary note", "description": "Explicit statement of what the protected subject includes and excludes, written so a relying party can reconstruct the same unit.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] } ], "artifacts": [ { "id": "sig-payload-art-subject-descriptor", "name": "Protected subject descriptor", "description": "Format-neutral record naming the protected unit, its topology relative to the proof and its declared boundary, cited by every binding descriptor, digest evidence entry and scope manifest for that proof.", "media_or_form": [ "structured descriptor record", "envelope header block within a signature structure", "detached descriptor document accompanying the proof" ], "serial": false, "identity_strategy": "Use the authoritative master-system identifier of the host record and version where one exists; otherwise a governed IRI in the Dimension namespace; otherwise a Dimension-assigned ULID. A version label or a date is never the identifier.", "source_refs": [ "SRC-006", "SRC-016", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "sig-payload-content-descriptor", "name": "Content identity, version and type descriptor", "description": "Pins which representation of the logical content is protected: authoritative content identifier, version, master-system reference, declared content type and content length, plus whether the representation is immutable. CMS requires the signed content-type attribute to match the encapsulated content type; JWS and COSE carry content-type hints that are advisory unless made critical.", "source_refs": [ "SRC-007", "SRC-006", "SRC-008", "SRC-017" ], "questions": [ { "id": "sig-payload-q-content-identifier", "text": "Which authoritative master-system identifier and version designate the exact protected representation?", "kind": "identity", "answer_data": [ "content identifier", "content version label", "master-system reference" ] }, { "id": "sig-payload-q-content-type", "text": "Which declared content type governs interpretation of the protected octets, and is that type value itself inside the protected input?", "kind": "classification", "answer_data": [ "content type code", "type registry reference", "type protection flag" ] }, { "id": "sig-payload-q-content-length", "text": "What content length is recorded for the protected representation, and is it protected evidence or advisory metadata?", "kind": "measurement", "answer_data": [ "content length in octets", "length protection flag", "measurement basis note" ] }, { "id": "sig-payload-q-content-version-drift", "text": "How is the protected representation distinguished from a later revision of the same logical content?", "kind": "temporal", "answer_data": [ "version discriminator", "representation immutability flag", "effective-from instant of the representation" ] }, { "id": "sig-payload-q-content-type-registry", "text": "Which governed registry or namespace supplies the content-type and identifier vocabularies used here?", "kind": "interoperability", "answer_data": [ "registry reference", "registry version", "local mapping note" ] } ], "data_elements": [ { "id": "sig-payload-de-content-identifier", "name": "Content identifier", "description": "Authoritative identifier of the protected representation, taken from the system of record for that content.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "sig-payload-de-content-version", "name": "Content version label", "description": "Version or revision designation of the protected representation as issued by the master system; never used alone as the identifier.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-017" ] }, { "id": "sig-payload-de-master-system-reference", "name": "Master-system reference", "description": "Reference to the system of record that issues the content identifier and version and can supply the retrievable octets.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-018" ] }, { "id": "sig-payload-de-content-type-code", "name": "Declared content type", "description": "Media type, content-format identifier or content-type object identifier declared for the protected octets, with a flag stating whether the value sits inside the protected input.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-006", "SRC-008" ] }, { "id": "sig-payload-de-content-length", "name": "Content length in octets", "description": "Recorded octet length of the protected representation, used as a cheap mismatch check and never as a substitute for digest evidence.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-017" ] }, { "id": "sig-payload-de-representation-immutability", "name": "Representation immutability flag", "description": "States whether the master system guarantees the identified representation is immutable, which determines whether a locator alone can be trusted.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-018" ] } ], "artifacts": [], "inline_only_rationale": "The content identifier, version, master-system reference, type and length are reference data owned by the system of record for the protected content. Materialising them as a separate stored artifact would create a second, divergent copy of a master record that this model does not own and cannot keep current, and would invite relying parties to trust the copy instead of resolving the master. The values are therefore held inline on the binding descriptor as pointers plus advisory measurements, with the digest evidence - not this descriptor - carrying the cryptographic weight." } ] }, { "id": "sig-payload-binding-evidence", "name": "Binding mode, digest evidence and protection scope", "description": "How the protected input is constituted: carried directly or bound by digest, over the whole object or a selected part, with recorded digest algorithm and value.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-009", "SRC-016", "SRC-017" ], "findings": [ { "id": "sig-payload-binding-mode", "name": "Direct versus digest-based binding mode", "description": "Records whether the protected octets are carried inside the protected input (as in a JWS payload or CMS encapsulated content) or bound indirectly through a digest reference (as in an XML Signature Reference, a C2PA hashed URI or a time-stamp MessageImprint), and how a detached payload or an immutable external resource is pinned so a verifier obtains the identical octets.", "source_refs": [ "SRC-014", "SRC-006", "SRC-008", "SRC-009", "SRC-016", "SRC-018" ], "questions": [ { "id": "sig-payload-q-binding-directness", "text": "Is the payload bound directly as octets inside the protected input, or indirectly through a digest over a referenced object?", "kind": "definition", "answer_data": [ "binding mode code", "protected input construction reference", "payload carriage flag" ] }, { "id": "sig-payload-q-detached-retrieval", "text": "When the payload is detached, by what contract does a verifier obtain byte-for-byte the same octets that were protected?", "kind": "process", "answer_data": [ "payload supply contract reference", "unchanged-transport obligation", "responsible party reference" ] }, { "id": "sig-payload-q-external-pin", "text": "For an external resource, which combination of locator, digest, algorithm and declared type constitutes the immutable pin?", "kind": "evidence", "answer_data": [ "resource locator", "pin digest algorithm and value", "declared media type", "pin completeness flag" ] }, { "id": "sig-payload-q-binding-guarantee-limit", "text": "What does this binding explicitly not guarantee about a dereferenced resource beyond digest equality?", "kind": "constraint", "answer_data": [ "guarantee limitation statement", "dereference risk note", "residual-trust assumption" ] }, { "id": "sig-payload-q-payload-supply-ownership", "text": "Which party is accountable for supplying the detached payload at verification time?", "kind": "ownership", "answer_data": [ "accountable party reference", "supply agreement reference", "escalation path on non-supply" ] } ], "data_elements": [ { "id": "sig-payload-de-binding-mode-code", "name": "Binding mode", "description": "Whether the payload is bound directly as carried octets or indirectly through digest reference, and whether it is attached or detached.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-008", "SRC-016" ] }, { "id": "sig-payload-de-payload-carriage-flag", "name": "Payload carriage and encoding flag", "description": "States whether the payload is present in the carrier and in which encoding it entered the protected input, since the encoding choice alters the protected bytes.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-008" ] }, { "id": "sig-payload-de-reference-locator", "name": "Payload reference locator", "description": "Locator for a referenced or detached payload; may be absent where the receiving application is expected to know the object identity by agreement.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-payload-de-external-resource-pin", "name": "External resource pin", "description": "Composite pin of locator, digest algorithm, digest value and declared type that makes an external resource reference immutable in effect.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-018" ] }, { "id": "sig-payload-de-payload-supply-contract", "name": "Payload supply contract reference", "description": "Reference to the agreement naming who supplies detached octets, in what form and with what unchanged-transport obligation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] } ], "artifacts": [ { "id": "sig-payload-art-binding-descriptor", "name": "Payload binding descriptor", "description": "Format-neutral record stating the binding mode, carriage and encoding of the payload, the reference locators used and the explicit limits of what the binding guarantees.", "media_or_form": [ "structured binding record", "reference element within a signature structure", "assertion entry within a provenance manifest" ], "serial": false, "identity_strategy": "Authoritative master-system identifier of the proof record where the proof registry issues one; otherwise a governed IRI derived from the subject descriptor identifier; otherwise a Dimension-assigned ULID.", "source_refs": [ "SRC-006", "SRC-008", "SRC-016" ] }, { "id": "sig-payload-art-external-pin-record", "name": "External resource pin record", "description": "Record pinning an external resource by locator plus digest, declared type and length, retained so later dereferences can be checked against the representation that was actually protected.", "media_or_form": [ "structured pin record", "integrity metadata attribute on a resource reference", "hashed URI entry" ], "serial": false, "identity_strategy": "Governed content-addressed identifier formed from the pinned digest algorithm and value where the Dimension permits content addressing; otherwise the master-system identifier of the pinned resource; otherwise a Dimension-assigned ULID.", "source_refs": [ "SRC-017", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "sig-payload-digest-evidence", "name": "Digest method and value evidence", "description": "Records the digest algorithm identifier drawn from a governed registry, the digest value and its encoding, any parallel digests recorded for agility, and a precise statement of the octet stream the digest was taken over. The digest is computed by an external provider; this model retains the evidence and the description of its input.", "source_refs": [ "SRC-006", "SRC-009", "SRC-016", "SRC-004", "SRC-017", "SRC-018" ], "questions": [ { "id": "sig-payload-q-digest-algorithm", "text": "Which digest algorithm identifier, drawn from which governed registry and version, produced the recorded digest?", "kind": "interoperability", "answer_data": [ "digest algorithm identifier", "registry reference and version", "identifier form note" ] }, { "id": "sig-payload-q-digest-value-form", "text": "What is the recorded digest value and in which encoding and length is it expressed?", "kind": "measurement", "answer_data": [ "digest value", "digest encoding label", "expected digest length in octets" ] }, { "id": "sig-payload-q-digest-input-statement", "text": "Over exactly which octet stream was this digest taken, and where is that determination recorded?", "kind": "evidence", "answer_data": [ "digest input description", "canonicalization or transform algorithm identifier", "scope manifest reference" ] }, { "id": "sig-payload-q-digest-multiplicity", "text": "When several digests cover the same payload, which one governs and by what selection rule?", "kind": "decision", "answer_data": [ "digest entry set", "selection rule statement", "governing digest reference" ] }, { "id": "sig-payload-q-digest-strength-status", "text": "How is a weakened or superseded digest algorithm flagged without altering the historical binding evidence?", "kind": "quality", "answer_data": [ "algorithm strength status code", "status assertion source", "status observation instant" ] } ], "data_elements": [ { "id": "sig-payload-de-digest-algorithm-id", "name": "Digest algorithm identifier", "description": "Registry-governed identifier of the digest algorithm, recorded verbatim in its published form as an object identifier, URI, registry integer or suite name.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-009", "SRC-016" ] }, { "id": "sig-payload-de-digest-value", "name": "Digest value", "description": "The digest octets as produced by the external digest provider, stored without re-encoding.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-016", "SRC-017" ] }, { "id": "sig-payload-de-digest-encoding", "name": "Digest value encoding label", "description": "Explicit label for how the digest value is serialized in this record, so comparison never depends on an assumed encoding.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-018" ] }, { "id": "sig-payload-de-digest-input-description", "name": "Digest input description", "description": "Statement of the octet stream digested, including the canonicalization or transform algorithm identifier applied beforehand and the scope manifest that selected the input.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-004" ] }, { "id": "sig-payload-de-digest-strength-status", "name": "Digest algorithm strength status", "description": "Advisory status of the algorithm as current, deprecated or broken, observed at a recorded instant; never rewrites the digest evidence itself.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "sig-payload-art-digest-evidence-record", "name": "Digest evidence record", "description": "Immutable record of one digest over one described input: algorithm identifier, value, encoding, input description and observation instant. Multiple records may exist for the same payload under different algorithms.", "media_or_form": [ "structured digest record", "message-digest attribute within a signed attribute set", "digest element within a reference structure", "integrity metadata expression" ], "serial": false, "identity_strategy": "Master-system identifier of the proof record where issued; otherwise a governed content-addressed identifier combining the algorithm identifier and digest value; otherwise a Dimension-assigned ULID.", "source_refs": [ "SRC-006", "SRC-016", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "sig-payload-scope-selection", "name": "Whole-object versus selected-part protection scope", "description": "Declares whether the whole object is protected or an explicitly selected part, and expresses the selection so any verifier reconstructs an identical input: byte ranges with exclusions, named boxes, node sets, field sets or subgraphs. Records the unprotected remainder and the requirement that excluded regions cannot change how the protected part is interpreted.", "source_refs": [ "SRC-007", "SRC-016", "SRC-004", "SRC-017" ], "questions": [ { "id": "sig-payload-q-scope-mode", "text": "Is the protection scope the entire object or an explicitly selected part of it?", "kind": "classification", "answer_data": [ "scope mode code", "scope summary statement", "selection completeness flag" ] }, { "id": "sig-payload-q-scope-selection-expression", "text": "How are included and excluded regions, boxes or fields expressed so a verifier reconstructs the identical selection?", "kind": "composition", "answer_data": [ "selection expression language identifier", "included region list", "excluded region list" ] }, { "id": "sig-payload-q-scope-structured-selection", "text": "How is a selection expressed when the payload is a field set or graph rather than a byte range?", "kind": "relationship", "answer_data": [ "structured selection descriptor", "node or property path set", "graph or dataset reference" ] }, { "id": "sig-payload-q-scope-remainder", "text": "Which parts of the host object remain outside the protected scope and may change without invalidating this proof?", "kind": "state", "answer_data": [ "unprotected remainder description", "mutability expectation", "downstream warning text" ] }, { "id": "sig-payload-q-scope-exclusion-safety", "text": "What prevents a change inside an excluded region from altering how the protected part is interpreted?", "kind": "security", "answer_data": [ "exclusion constraint statement", "permitted excluded content rule", "padding and length constraint" ] } ], "data_elements": [ { "id": "sig-payload-de-scope-mode", "name": "Protection scope mode", "description": "Whether the binding covers the whole object or a selected part.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-payload-de-selection-language", "name": "Selection expression language identifier", "description": "Identifier of the language or convention used to express the selection, such as a byte-range list, box identifier list, node-set transform or property path set.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-payload-de-included-region", "name": "Included region descriptor", "description": "Ordered descriptors of the regions, boxes, nodes or properties inside the protected scope.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-payload-de-excluded-region", "name": "Excluded region descriptor", "description": "Descriptors of regions deliberately outside the digest input, each with the constraint on what such a region is permitted to contain.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "sig-payload-de-unprotected-remainder", "name": "Unprotected remainder statement", "description": "Plain statement of what a relying party must not assume is protected by this binding.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] } ], "artifacts": [ { "id": "sig-payload-art-scope-manifest", "name": "Protected scope manifest", "description": "Record enumerating the included and excluded parts of the protected object together with the selection language and the constraints on excluded content, sufficient for an independent party to rebuild the identical digest input.", "media_or_form": [ "structured scope manifest", "hash assertion with exclusion ranges", "transform chain description within a reference", "manifest of sub-references" ], "serial": false, "identity_strategy": "Master-system identifier of the proof record where issued; otherwise a governed IRI derived from the subject descriptor identifier and scope ordinal; otherwise a Dimension-assigned ULID.", "source_refs": [ "SRC-016", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-payload-binding-parameters", "name": "Bound parameters, dependency and failure semantics", "description": "Which parameters sit inside the protected input and which do not, which of them must be understood, what purpose and context the proof is bound to, and how the exact protected input is preserved and failed on when it cannot be reproduced.", "rationale": "Each cited standard treats the parameter partition as security-critical: JWS and COSE forbid critical parameters outside the protected bucket and make unknown critical parameters fatal, COSE requires protected-bucket precedence, CMS mandates specific signed attributes and forbids content-type inside a countersignature, and Data Integrity binds proof purpose, domain, challenge and expiry. COSE countersignatures and Data Integrity proof chains both require the exact finalized prior input, which makes preservation and explicit failure a distinct, testable concern.", "source_refs": [ "SRC-007", "SRC-014", "SRC-006", "SRC-008", "SRC-015", "SRC-004" ], "layers": [ { "id": "sig-payload-parameter-binding", "name": "Parameter partition and semantic binding", "description": "The split between protected and unprotected parameters with its criticality rules, and the purpose, audience and validity parameters bound into the protected input.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-004" ], "findings": [ { "id": "sig-payload-parameter-partition", "name": "Protected and unprotected parameter partition with criticality", "description": "Classifies every proof parameter as inside or outside the protected input, marks the subset that must be understood or the proof rejected, and fixes the precedence rule when the same parameter appears in both positions. Records how a relying party registers that it did not understand a critical parameter.", "source_refs": [ "SRC-007", "SRC-014", "SRC-006", "SRC-008", "SRC-016" ], "questions": [ { "id": "sig-payload-q-parameter-positions", "text": "Which proof parameters sit inside the protected input and which are carried outside it?", "kind": "composition", "answer_data": [ "protected parameter name list", "unprotected parameter name list", "position assignment rationale" ] }, { "id": "sig-payload-q-critical-set", "text": "Which protected parameters are marked critical, so a party unable to process them must reject the proof?", "kind": "requirement", "answer_data": [ "critical parameter name list", "criticality declaration location", "rejection obligation statement" ] }, { "id": "sig-payload-q-parameter-precedence", "text": "When one parameter appears in both a protected and an unprotected position, which value governs?", "kind": "decision", "answer_data": [ "precedence rule statement", "conflict detection outcome", "duplicate parameter record" ] }, { "id": "sig-payload-q-unknown-critical-handling", "text": "How does a relying party record that a critical parameter was not understood?", "kind": "exception", "answer_data": [ "unknown critical parameter list", "outcome code", "reporting party reference" ] }, { "id": "sig-payload-q-advisory-parameters", "text": "Which parameters are advisory only and must never carry a security decision on their own?", "kind": "quality", "answer_data": [ "advisory parameter list", "advisory-use warning", "supporting standard citation" ] } ], "data_elements": [ { "id": "sig-payload-de-protected-parameter-name", "name": "Protected parameter name", "description": "Name or label of a parameter inside the protected input and therefore covered by the proof.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-payload-de-unprotected-parameter-name", "name": "Unprotected parameter name", "description": "Name or label of a parameter carried alongside the proof but outside the protected input.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-006", "SRC-008" ] }, { "id": "sig-payload-de-critical-parameter-name", "name": "Critical parameter name", "description": "Parameter declared must-be-understood; declaring it outside the protected input is invalid.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-014", "SRC-008" ] }, { "id": "sig-payload-de-parameter-precedence-rule", "name": "Parameter precedence rule", "description": "Recorded rule that a value found in the protected position governs and an unprotected duplicate is advisory at best.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "sig-payload-de-advisory-parameter-flag", "name": "Advisory parameter flag", "description": "Marks a parameter whose value the governing standard defines as advisory and not subject to validation.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "The partition is not a separate stored object: it is a property of the proof envelope produced by the referenced proof-method and serialization models, where the protected bucket is exactly the octet range that entered the signing computation. Emitting a standalone artifact would create a second copy of that parameter set which could drift from the envelope, and any drift would silently change what a relying party believes was covered. The partition is therefore held as inline classification metadata pointing at positions within the envelope, so the envelope remains the only authority on what was protected." }, { "id": "sig-payload-purpose-context", "name": "Proof purpose, audience context and validity-window binding", "description": "Binds the declared purpose of the proof, the audience or domain it is intended for, any challenge or nonce tying it to a request occurrence, externally supplied authenticated data bound without being carried, and an expiry inside the protected input - where the chosen proof method relies on these. Distinguishes proof expiry from the host content's own validity period.", "source_refs": [ "SRC-007", "SRC-006", "SRC-008", "SRC-004" ], "questions": [ { "id": "sig-payload-q-proof-purpose", "text": "For which declared purpose is this protected payload bound, and which uses are thereby excluded?", "kind": "authority", "answer_data": [ "proof purpose code", "purpose registry reference", "excluded-use statement" ] }, { "id": "sig-payload-q-audience-domain", "text": "Which audience, domain or context value is bound so the proof cannot be replayed in another setting?", "kind": "security", "answer_data": [ "audience or domain value set", "binding position", "replay limitation note" ] }, { "id": "sig-payload-q-challenge-occurrence", "text": "Which challenge or nonce ties this protected payload to one specific request occurrence?", "kind": "event", "answer_data": [ "challenge or nonce value", "issuing party reference", "occurrence reference" ] }, { "id": "sig-payload-q-proof-expiry", "text": "Which expiry instant is bound inside the protected input, and how does it differ from the host content's own validity period?", "kind": "temporal", "answer_data": [ "proof expiry instant", "host validity period reference", "distinction statement" ] }, { "id": "sig-payload-q-external-authenticated-data", "text": "Which externally supplied data is authenticated by the proof without being carried inside the payload?", "kind": "provenance", "answer_data": [ "external authenticated data reference", "construction rule reference", "supplying party reference" ] } ], "data_elements": [ { "id": "sig-payload-de-proof-purpose", "name": "Proof purpose", "description": "Declared purpose for which the proof is intended, expressed as a registry-governed value a relying party checks before use.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-payload-de-audience-context", "name": "Audience or domain value", "description": "One or more context values naming where the proof is meant to be used.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-payload-de-challenge-value", "name": "Challenge or nonce value", "description": "Value tying the proof to a specific request occurrence; expected whenever an audience or domain is bound.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-payload-de-proof-expiry-instant", "name": "Bound proof expiry instant", "description": "Expiry instant carried inside the protected input, recorded as an absolute time value; evaluating whether it has passed belongs to the referenced verification model.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-payload-de-external-authenticated-data", "name": "External authenticated data reference", "description": "Reference to application-supplied data authenticated by the proof but transported outside the object, with the construction rule that makes it unambiguous.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "These are scalar parameter values whose meaning exists only inside the protected input of a specific proof; their security property comes from being covered by that proof, not from being stored anywhere. Extracting them into a separate artifact would produce an unprotected copy that looks authoritative while carrying none of the binding, tempting consumers to read purpose or expiry from the copy rather than from the covered position. They are therefore recorded inline with an explicit note of which position each value occupies, and their evaluation is left to the referenced verification model." } ] }, { "id": "sig-payload-input-continuity", "name": "Protected-input continuity and failure semantics", "description": "Preservation of the exact protected input for dependent proofs, and the explicit failure states that replace any substitution when the payload cannot be reproduced.", "source_refs": [ "SRC-006", "SRC-015", "SRC-016", "SRC-004" ], "findings": [ { "id": "sig-payload-input-preservation-failure", "name": "Protected-input preservation and binding failure states", "description": "Fixes which form of the protected input - full octet sequence, canonical serialization or digest - is preserved so dependent countersignatures and proof chains bind the identical input, how a dependent proof references it, and the explicit failure states recorded when a payload is missing, mutable, ambiguous or resolves to a different version. Substituting an empty, default or nearest-match value is prohibited.", "source_refs": [ "SRC-006", "SRC-015", "SRC-016", "SRC-004", "SRC-017" ], "questions": [ { "id": "sig-payload-q-preserved-form", "text": "Which exact form of the protected input is preserved for dependent proofs: full octets, canonical serialization or digest alone?", "kind": "retention", "answer_data": [ "preserved form code", "preserved input reference", "sufficiency justification" ] }, { "id": "sig-payload-q-dependent-reference", "text": "How does a dependent countersignature or chained proof reference the prior protected input or signature value?", "kind": "relationship", "answer_data": [ "dependent proof reference", "reference construction rule", "chain ordinal" ] }, { "id": "sig-payload-q-target-finality", "text": "What evidence shows the target was cryptographically finalized before a dependent proof was taken over it?", "kind": "validation", "answer_data": [ "finality assertion", "target digest at time of dependence", "observation instant" ] }, { "id": "sig-payload-q-failure-state", "text": "What outcome is recorded when the referenced payload is unresolvable, mutable, ambiguous or of a different version?", "kind": "state", "answer_data": [ "binding failure code", "failure detail text", "affected descriptor reference" ] }, { "id": "sig-payload-q-substitution-prohibition", "text": "Which substitutions are prohibited outright rather than recorded as a degraded result?", "kind": "constraint", "answer_data": [ "prohibited substitution list", "prohibition rationale", "escalation obligation" ] } ], "data_elements": [ { "id": "sig-payload-de-preserved-form-code", "name": "Preserved protected-input form", "description": "Which form of the protected input was retained: full octet sequence, canonical serialization or digest only.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-015" ] }, { "id": "sig-payload-de-preserved-input", "name": "Preserved protected input", "description": "Retained octets of the protected input, held only where dependent proofs require the full bytes and where the host record's classification permits retention.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "sig-payload-de-preserved-digest-reference", "name": "Preserved digest reference", "description": "Reference to the digest evidence record that stands in for the protected input when the full octets are not retained.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "sig-payload-de-dependent-proof-reference", "name": "Dependent proof reference", "description": "Reference from a countersignature or chained proof to the prior proof or protected input it binds, with its ordinal in the chain.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-015", "SRC-004" ] }, { "id": "sig-payload-de-binding-failure-code", "name": "Binding failure code", "description": "Explicit failure classifier: payload unresolvable, payload mutable, payload ambiguous, version mismatch, digest mismatch, scope irreproducible or critical parameter not understood.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-004", "SRC-017" ] }, { "id": "sig-payload-de-failure-observation-instant", "name": "Failure observation instant", "description": "Time at which the failure was observed, recorded separately from the time the protected input was originally fixed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-004" ] } ], "artifacts": [ { "id": "sig-payload-art-preserved-input-record", "name": "Preserved protected-input record", "description": "Ordered record retaining the exact protected input or its digest at the moment a dependent proof was taken, one per position in a countersignature or proof chain.", "media_or_form": [ "structured preserved-input record", "retained octet blob referenced by digest", "chained proof entry referencing a prior proof" ], "serial": true, "identity_strategy": "Master-system identifier of the proof chain entry where the proof registry issues one; otherwise a governed IRI formed from the parent proof identifier plus the immutable chain ordinal; otherwise a Dimension-assigned ULID. The ordinal is a position, never a date.", "source_refs": [ "SRC-006", "SRC-015", "SRC-004" ] }, { "id": "sig-payload-art-binding-failure-record", "name": "Binding failure record", "description": "Record of an explicit binding failure with its classifier, detail, affected descriptor and observation instant, created instead of any empty or substituted payload value.", "media_or_form": [ "structured failure record", "negative validation outcome entry", "annotation attached to a binding descriptor" ], "serial": false, "identity_strategy": "Master-system identifier of the observing system's incident record where one exists; otherwise a governed IRI derived from the affected descriptor identifier and failure ordinal; otherwise a Dimension-assigned ULID.", "source_refs": [ "SRC-016", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-c14n-bundle-protected-bytes", "name": "Reproducible Protected-Bytes Derivation", "description": "Everything an agent needs to reconstruct, byte for byte, the octets that a signature or proof actually protects: the ordered transform chain, the pinned and versioned algorithm identifiers with their bound parameters, and the representation-level normalization decisions that change the protected bytes without changing the perceived content.", "rationale": "Primary signing specifications sign a derived byte string rather than a source document. The JWS Signing Input, the COSE Sig_structure, the HTTP signature base and the XML Signature reference-processing model all interpose an ordered transform stage between the subject and the digest. Unless that stage is recorded with identifiers, versions, parameters and media types, verification is not reproducible and the derivation, not the primitive, becomes the weak point.", "source_refs": [ "SRC-019", "SRC-020", "SRC-021", "SRC-004", "SRC-007", "SRC-008", "SRC-022", "SRC-016" ], "layers": [ { "id": "sig-c14n-layer-transform-chain", "name": "Transform chain declaration and algorithm pinning", "description": "The ordered chain from selected input to protected bytes: each step's position, presence semantics, governed algorithm identifier, version, bound parameters, input and output media types, the externally executed implementation that produced the result, and the digest that makes the output falsifiable.", "source_refs": [ "SRC-004", "SRC-007", "SRC-008", "SRC-016", "SRC-030", "SRC-017" ], "findings": [ { "id": "sig-c14n-finding-chain-record", "name": "Ordered transform and canonicalization chain record", "description": "The indexed sequence of transform steps applied between a selected input and the protected bytes, together with the digest of those bytes. Step presence is three-valued: a step may be absent from the declaration, declared as an explicit identity or no-op transform, or declared as a substantive transform. XML Signature reference processing shows the distinction is not cosmetic, since an octet stream with no Transforms is digested directly while a declared canonicalization step converts a node-set to octets.", "source_refs": [ "SRC-016", "SRC-007", "SRC-008", "SRC-004", "SRC-017" ], "questions": [ { "id": "sig-c14n-q-chain-order", "text": "What is the exact ordered sequence of transform steps applied between the selected input and the protected bytes?", "kind": "composition", "answer_data": [ "Step index within the chain", "Step algorithm identifier", "Step input media type", "Step output media type" ] }, { "id": "sig-c14n-q-step-presence", "text": "Is each position an explicit identity or no-op transform, a substantive transform, or absent from the declaration entirely?", "kind": "classification", "answer_data": [ "Step presence enumeration: absent, identity, substantive", "Justification note for a declared identity step", "Acknowledgement that no default step may be assumed for an unstated position" ] }, { "id": "sig-c14n-q-protected-digest", "text": "Which digest algorithm and value identify the protected byte sequence that the chain produced?", "kind": "identity", "answer_data": [ "Digest algorithm identifier", "Digest value over the protected octets", "Protected octet length" ] }, { "id": "sig-c14n-q-chain-reproduce", "text": "Can an independent implementation reproduce the recorded protected bytes byte for byte from the declared inputs and steps?", "kind": "validation", "answer_data": [ "Reproducibility determination", "Recomputed digest supplied by an external processor", "Divergence description where the digests differ" ] }, { "id": "sig-c14n-q-chain-supersession", "text": "When a chain declaration changes, which prior record does it supersede and from which instant is each version effective?", "kind": "lifecycle", "answer_data": [ "Chain record version identifier", "Superseded record reference", "Effective-from instant in RFC 3339 form with seconds and an explicit offset" ] } ], "data_elements": [ { "id": "sig-c14n-de-chain-step-index", "name": "Chain step index", "description": "Ordinal position of a transform step in the chain, fixing the order in which each output feeds the next step.", "value_kind": "number", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "sig-c14n-de-step-presence-kind", "name": "Step presence kind", "description": "Three-valued declaration distinguishing an absent step from an explicit identity or no-op step and from a substantive transform.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016", "SRC-030" ] }, { "id": "sig-c14n-de-protected-digest-alg", "name": "Protected-bytes digest algorithm", "description": "Registry-sourced identifier of the hash algorithm applied to the chain output.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-017" ] }, { "id": "sig-c14n-de-protected-digest-value", "name": "Protected-bytes digest value", "description": "Digest over the protected octet sequence, used as a content address for reproducibility comparison but never as the record identifier.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-c14n-de-chain-record-version", "name": "Chain record version identifier", "description": "Identifier of this version of the chain declaration, to which derivation records bind.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-017" ] } ], "artifacts": [ { "id": "sig-c14n-artifact-chain-manifest", "name": "Canonicalization chain manifest", "description": "The versioned, ordered declaration of every transform step with its presence kind, algorithm identifier, parameters and media types, sufficient for an independent processor to re-derive the protected bytes.", "media_or_form": [ "structured declaration record", "human-readable specification excerpt" ], "serial": true, "identity_strategy": "Chain manifest identifier issued by the adopting Dimension's canonicalization register as the authoritative master system; where no such register exists, a governed IRI; failing both, a UUID or ULID minted by the adopting Dimension. The version component is appended and is never a date.", "source_refs": [ "SRC-016", "SRC-004", "SRC-030" ] }, { "id": "sig-c14n-artifact-protected-bytes-record", "name": "Protected-bytes derivation record", "description": "The record of one derivation outcome: the chain manifest version applied, the protected octet length, the digest algorithm identifier and digest value, and the instants at which the derivation occurred and was recorded.", "media_or_form": [ "digest record", "octet-sequence descriptor" ], "serial": true, "identity_strategy": "Master-system derivation record identifier bound to exactly one chain manifest version identifier; the digest value is carried as a content address alongside it, never in place of it.", "source_refs": [ "SRC-007", "SRC-008", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "sig-c14n-finding-algorithm-pin", "name": "Versioned algorithm identifiers, parameters and implementation pins", "description": "For each declared step, the governed URI or registered name of the algorithm, the version or edition intended, the named parameter values bound versus left at specification defaults, and the external implementation, version and configuration that actually produced the bytes. Canonical XML 2.0 makes the case concrete: one algorithm URI with four mandatory parameters and documented defaults, so an identifier alone does not determine output.", "source_refs": [ "SRC-030", "SRC-021", "SRC-004", "SRC-020", "SRC-017" ], "questions": [ { "id": "sig-c14n-q-alg-identifier", "text": "Which governed URI or registered name identifies each transform algorithm, and which version or edition of it is intended?", "kind": "identity", "answer_data": [ "Algorithm URI or registered cryptosuite name", "Algorithm version or edition label", "Reference to the defining specification and its publication status" ] }, { "id": "sig-c14n-q-alg-parameters", "text": "Which named parameter values are bound for each parameterised algorithm, and which are left at specification defaults?", "kind": "constraint", "answer_data": [ "Parameter name", "Bound value", "Default-applied flag", "Internal hash algorithm where the algorithm is hash-parameterised" ] }, { "id": "sig-c14n-q-impl-pin", "text": "Which external implementation, version and configuration produced the recorded protected bytes?", "kind": "provenance", "answer_data": [ "Implementation product identifier", "Implementation version", "Configuration or profile identifier", "Derivation event instant in RFC 3339 form with seconds and an explicit offset" ] }, { "id": "sig-c14n-q-alg-interop", "text": "Which conformance test vectors demonstrate that independent implementations of the pinned algorithm and parameter set agree?", "kind": "interoperability", "answer_data": [ "Test vector set reference", "Input fixture identifier", "Expected canonical output digest", "Implementations that passed" ] } ], "data_elements": [ { "id": "sig-c14n-de-algorithm-uri", "name": "Transform algorithm identifier", "description": "Governed URI or registered name of a transform, canonicalization or cryptosuite algorithm, taken unchanged from its defining authority.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-030", "SRC-004" ] }, { "id": "sig-c14n-de-algorithm-parameter", "name": "Bound algorithm parameter", "description": "A named parameter and its bound value for a parameterised algorithm, such as prefix rewriting, text-node trimming or the internal hash algorithm.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-030", "SRC-021" ] }, { "id": "sig-c14n-de-default-applied-flag", "name": "Specification default applied", "description": "Flag recording that a parameter was deliberately left at its specification default rather than omitted by oversight.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-030" ] }, { "id": "sig-c14n-de-implementation-pin", "name": "Implementation pin", "description": "Product, version and configuration of the external processor that executed the chain, recorded so a divergence can be attributed rather than argued.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-028" ] } ], "artifacts": [ { "id": "sig-c14n-artifact-profile-reference", "name": "Referenced canonicalization profile or cryptosuite definition", "description": "The external normative document that defines a pinned algorithm or cryptosuite, referenced by its governed identifier together with the publication status and version relied upon.", "media_or_form": [ "referenced normative specification", "registry entry" ], "serial": true, "identity_strategy": "Governed algorithm URI or registered cryptosuite name published by the defining authority, used verbatim and never re-minted locally; local records carry the reference, not a copy.", "source_refs": [ "SRC-020", "SRC-030", "SRC-021", "SRC-004" ] }, { "id": "sig-c14n-artifact-implementation-pin-record", "name": "Implementation pin and conformance vector record", "description": "The record of which processor build and configuration produced a derivation, plus the conformance vectors and their outcomes used to show that independent implementations agree.", "media_or_form": [ "structured record", "test vector set" ], "serial": true, "identity_strategy": "Master-system pin record identifier; where the processor publishes a governed build identifier that value is carried as a secondary reference.", "source_refs": [ "SRC-022", "SRC-021", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-c14n-layer-normalization-semantics", "name": "Representation normalization semantics", "description": "The declarations that determine which lexically different inputs are treated as the same protected bytes: character and Unicode handling, line endings and whitespace, ordering and duplicate keys, numeric and date lexical forms, namespace context and graph-level canonicalization. Stated per declaration so that no single host syntax is privileged.", "source_refs": [ "SRC-019", "SRC-020", "SRC-021", "SRC-025", "SRC-028", "SRC-029", "SRC-030" ], "findings": [ { "id": "sig-c14n-finding-lexical-normalization", "name": "Character encoding, Unicode, line-ending and whitespace declarations", "description": "Declared treatment of input character encoding, output octet encoding, Unicode normalization form and the Unicode version under which it was computed, line-break normalization and whitespace trimming. These change the protected bytes without changing perceived content, and some are irreversible: compatibility normalization erases formatting distinctions and prevents round-trip conversion.", "source_refs": [ "SRC-019", "SRC-020", "SRC-025", "SRC-028", "SRC-030" ], "questions": [ { "id": "sig-c14n-q-encoding-decl", "text": "Which character encoding is assumed for the input and which octet encoding is produced for the protected bytes?", "kind": "definition", "answer_data": [ "Input character encoding label", "Output octet encoding", "Byte-order-mark handling rule" ] }, { "id": "sig-c14n-q-unicode-form", "text": "Which Unicode normalization form, if any, is applied, and under which Unicode version was it computed?", "kind": "constraint", "answer_data": [ "Normalization form: none, NFC, NFD, NFKC or NFKD", "Unicode version used", "Handling of unassigned code points whose normalization may change across versions" ] }, { "id": "sig-c14n-q-whitespace-rule", "text": "How are line endings and insignificant whitespace treated before the digest is taken?", "kind": "requirement", "answer_data": [ "Line-break normalization rule", "Whitespace trimming parameter and its default", "Handling of preserve directives such as xml:space" ] }, { "id": "sig-c14n-q-lexical-lossiness", "text": "Which of these normalizations are lossy for the host representation and therefore recorded as irreversible?", "kind": "quality", "answer_data": [ "Irreversible normalization flag", "Description of the distinctions erased", "Round-trip test outcome" ] } ], "data_elements": [ { "id": "sig-c14n-de-input-charset", "name": "Declared input character encoding", "description": "Character encoding assumed for the input before any transform is applied.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-020", "SRC-028" ] }, { "id": "sig-c14n-de-output-octet-encoding", "name": "Protected-bytes octet encoding", "description": "Octet encoding of the chain output, which for the cited canonicalization schemes is UTF-8.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-020" ] }, { "id": "sig-c14n-de-unicode-normalization-form", "name": "Unicode normalization form", "description": "Normalization form applied, including the explicit value none, since neither Canonical XML nor JCS mandates normalization.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] }, { "id": "sig-c14n-de-unicode-version", "name": "Unicode version of record", "description": "Unicode version under which normalization was computed, needed because strings containing unassigned code points may normalize differently later.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "sig-c14n-de-whitespace-rule", "name": "Whitespace and line-ending rule", "description": "Declared line-break normalization and whitespace trimming behaviour, including whether trimming is enabled by default.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-020", "SRC-030", "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "These are parameter values that qualify steps already carried in the chain manifest and have no meaning detached from the step they qualify. Materialising them as separately addressable artifacts would create a second copy of the derivation's parameters that could drift from the manifest and be mistaken for authoritative, and the normalization rules themselves are owned by their defining specifications, which are referenced rather than reproduced." }, { "id": "sig-c14n-finding-structural-normalization", "name": "Ordering, duplicate keys, lexical value forms and graph normalization", "description": "Declared treatment of member, attribute and namespace ordering, duplicate key disposition, numeric and date lexical forms, namespace or prefix context when a fragment is detached, and graph-level canonicalization for dataset-shaped inputs. The cited rules are mutually incompatible across syntaxes, so the declaration names which rule set applies rather than asserting a universal ordering.", "source_refs": [ "SRC-019", "SRC-020", "SRC-021", "SRC-028", "SRC-029", "SRC-030" ], "questions": [ { "id": "sig-c14n-q-key-ordering", "text": "What deterministic ordering rule applies to map keys, object members, attributes and namespace declarations?", "kind": "constraint", "answer_data": [ "Ordering rule identifier", "Collation basis such as UTF-16 code units of unescaped names or bytewise order of encoded keys", "Scope of ordering: recursive or top level only" ] }, { "id": "sig-c14n-q-duplicate-keys", "text": "How is a duplicate key or repeated member handled, and is a duplicate a hard failure?", "kind": "exception", "answer_data": [ "Duplicate-key disposition: reject, first wins or last wins", "Validity profile reference such as I-JSON or CBOR validity", "Failure code emitted to the external evaluator" ] }, { "id": "sig-c14n-q-value-lexical-form", "text": "Which lexical forms are mandated for numbers, booleans and date or time values in the canonical output?", "kind": "requirement", "answer_data": [ "Number serialization rule", "Numeric range or precision limit", "Date and time lexical rule, recorded in RFC 3339 form with seconds and an explicit offset in this model's own records", "Shortest-form or preferred-serialization requirement" ] }, { "id": "sig-c14n-q-graph-normalization", "text": "For graph-shaped input, which dataset canonicalization algorithm and internal hash algorithm produce the deterministic labelling?", "kind": "interoperability", "answer_data": [ "Dataset canonicalization algorithm identifier", "Internal hash algorithm", "Canonical serialization form", "Iteration or complexity limit guarding against poison datasets" ] }, { "id": "sig-c14n-q-namespace-context", "text": "How is namespace or prefix context handled when signed content is detached from its enclosing document?", "kind": "relationship", "answer_data": [ "Namespace inheritance mode", "Prefix rewrite parameter value", "Inclusive prefix list", "Declaration of whether QName values inside text or attribute content are recognised" ] } ], "data_elements": [ { "id": "sig-c14n-de-key-ordering-rule", "name": "Deterministic ordering rule", "description": "Identifier of the ordering rule applied to keys, members, attributes or namespace nodes, together with its collation basis.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-020", "SRC-029" ] }, { "id": "sig-c14n-de-duplicate-key-disposition", "name": "Duplicate key disposition", "description": "Declared handling of duplicate keys or repeated members, needed because parser behaviour is otherwise unpredictable and validity is protocol-defined.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-028", "SRC-029", "SRC-019" ] }, { "id": "sig-c14n-de-number-serialization-rule", "name": "Numeric and value lexical rule", "description": "Rule governing the lexical form of numbers, booleans and temporal values in canonical output, including precision limits and shortest-form requirements.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-028", "SRC-029" ] }, { "id": "sig-c14n-de-graph-canon-algorithm", "name": "Dataset canonicalization algorithm", "description": "Identifier of the graph canonicalization algorithm and its internal hash algorithm, applicable only to dataset-shaped inputs.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "sig-c14n-de-namespace-handling-mode", "name": "Namespace and prefix handling mode", "description": "Declared namespace inheritance, prefix rewriting and QName-awareness behaviour for detachable content.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-030" ] } ], "artifacts": [], "inline_only_rationale": "Ordering, duplicate-key and lexical-form decisions are declarative parameters bound to specific chain steps and to the syntax family each step operates on. They are not independently retrievable objects and cannot be validated outside the manifest that names the algorithm they qualify, so they are held inline; the normative rules they select remain in their defining specifications, which are referenced as alignments." } ] } ] }, { "id": "sig-c14n-bundle-context-security", "name": "Input Binding and Canonicalization Context Security", "description": "What the derivation was computed over and what it is valid for: how the reference was resolved, which parts of the input were covered or excluded, which information the chain irreversibly discarded, and which context, purpose, type and criticality values keep this derivation from being reused, replayed or relocated into another setting.", "rationale": "The cited security considerations put most practical attacks at this layer rather than in the primitive: only what is signed is secure, message component source ambiguity, signature wrapping, algorithm and cross-token confusion, substitution, and cross-protocol reuse where domain separation is absent. Each has a declarative counterpart - resolution context, coverage and exclusion record, purpose and domain binding, explicit typing, criticality marking and complexity limits - that must exist and be readable before any external evaluator can act on it.", "source_refs": [ "SRC-004", "SRC-022", "SRC-016", "SRC-023", "SRC-024", "SRC-025", "SRC-026", "SRC-027", "SRC-017" ], "layers": [ { "id": "sig-c14n-layer-input-binding", "name": "Input resolution, coverage and fidelity", "description": "The context needed to know exactly which octets or nodes entered the chain: reference expression, base URI and how it was established, fragment interpretation, comparison level and dereferencing permission; and the record of coverage, exclusions, irreversible loss and the retained pre-transform representation.", "source_refs": [ "SRC-022", "SRC-016", "SRC-023", "SRC-024", "SRC-017" ], "findings": [ { "id": "sig-c14n-finding-input-resolution", "name": "Reference, base URI and fragment resolution context", "description": "The declarations that fix what a reference resolved to at derivation time: the reference expression, the base URI and the precedence rule by which it was established, the media type governing fragment interpretation, whether resolution was same-document or external, and the rung of the URI comparison ladder at which two references count as the same input. Signer and verifier reaching different values here is a documented failure mode.", "source_refs": [ "SRC-024", "SRC-016", "SRC-022", "SRC-020", "SRC-023" ], "questions": [ { "id": "sig-c14n-q-base-uri-source", "text": "Which base URI applied when relative references were resolved, and by which precedence rule was it established?", "kind": "provenance", "answer_data": [ "Base URI value", "Establishment rule: embedded in content, encapsulating entity, retrieval URI or application default", "Handling of in-scope base overrides such as xml:base and the fixup applied" ] }, { "id": "sig-c14n-q-fragment-semantics", "text": "How is the fragment component interpreted, and which media type determines that interpretation?", "kind": "definition", "answer_data": [ "Fragment expression", "Governing media type", "Same-document versus external resolution mode", "Whether comments and expanded content are included" ] }, { "id": "sig-c14n-q-uri-comparison", "text": "At which rung of the URI comparison ladder are two references treated as identifying the same input?", "kind": "validation", "answer_data": [ "Comparison level: simple string, syntax-based, scheme-based or protocol-based", "Percent-encoding normalization rule", "Case normalization rule" ] }, { "id": "sig-c14n-q-source-agreement", "text": "Do the signer and the verifier obtain the referenced component from the same source, and how is that agreement established?", "kind": "interoperability", "answer_data": [ "Component source declaration", "Intermediary or proxy rewriting note", "Agreed original value or its digest" ] }, { "id": "sig-c14n-q-external-retrieval", "text": "Is external dereferencing permitted for this reference, and which component is authorised to perform it?", "kind": "authority", "answer_data": [ "External-retrieval permitted flag", "Authorised retrieving component reference", "Digest of the retrieved representation", "Entity-resolution prohibition acknowledgement" ] } ], "data_elements": [ { "id": "sig-c14n-de-reference-expression", "name": "Input reference expression", "description": "The URI reference or component identifier naming the data object that entered the chain.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016", "SRC-022" ] }, { "id": "sig-c14n-de-base-uri", "name": "Effective base URI", "description": "The base URI in force when relative references were resolved at derivation time.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-020" ] }, { "id": "sig-c14n-de-base-uri-establishment", "name": "Base URI establishment rule", "description": "Which precedence level supplied the base URI, recorded because the same reference resolves differently under different levels.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "sig-c14n-de-resolution-mode", "name": "Resolution mode", "description": "Whether the reference resolved same-document or externally, and whether retrieval was permitted.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-023" ] }, { "id": "sig-c14n-de-uri-comparison-level", "name": "URI comparison level", "description": "The equivalence rung applied when deciding that two references denote the same input.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [], "inline_only_rationale": "Resolution context is pure reference data: it points at a subject owned by the payload model and records how the pointer was interpreted. The retrieved representation itself is not held here, and dereferencing is performed by an external component that is merely named. Materialising this as an artifact would imply that this model stores or serves the referenced content, which would cross the payload boundary." }, { "id": "sig-c14n-finding-selection-fidelity", "name": "Coverage, exclusions and irreversible-transform record", "description": "Which parts of the input the chain covers and which are deliberately excluded, expressed as a selection or exclusion map, together with the record of steps that discard information not reconstructible from the protected bytes and a reference plus digest for the retained pre-transform representation. Exclusion-list rather than inclusion-list framing is the pattern that survives adversarial review, because it prevents unbound content being added without changing the binding.", "source_refs": [ "SRC-017", "SRC-016", "SRC-023", "SRC-020", "SRC-025", "SRC-022" ], "questions": [ { "id": "sig-c14n-q-coverage-extent", "text": "Which byte ranges, nodes or message components does the chain cover, and which are excluded?", "kind": "composition", "answer_data": [ "Selection expression or covered-component list", "Exclusion range or exclusion list", "Exclusion reason code", "Padding or placeholder handling where offsets are not yet known" ] }, { "id": "sig-c14n-q-irreversible-delta", "text": "Which declared steps discard information that cannot be reconstructed from the protected bytes?", "kind": "evidence", "answer_data": [ "Irreversible step index", "Description of the discarded information", "Pre-transform representation reference and digest", "Retaining model reference" ] }, { "id": "sig-c14n-q-uncovered-risk", "text": "What content can change without changing the protected bytes, and has that been accepted for the declared purpose?", "kind": "security", "answer_data": [ "Uncovered-content description", "Impact statement", "Acceptance reference and the accepting role", "Residual risk note" ] }, { "id": "sig-c14n-q-selection-stability", "text": "Does the selection expression still select the same content when the host document is restructured or the fragment is relocated?", "kind": "state", "answer_data": [ "Selection stability determination", "Position or ancestry constraint accompanying any name-based selector", "Re-evaluation result reference", "Empty-selection detection outcome" ] } ], "data_elements": [ { "id": "sig-c14n-de-selection-expression", "name": "Coverage selection expression", "description": "Expression or list naming the covered components, nodes or ranges that enter the chain.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-022" ] }, { "id": "sig-c14n-de-exclusion-range", "name": "Exclusion entry", "description": "A declared excluded byte range, box or component, with its reason, used where a binding cannot cover the whole input.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "sig-c14n-de-irreversible-step-flag", "name": "Irreversible step flag", "description": "Marks a chain step whose effect cannot be reversed from the protected bytes, such as compatibility normalization or text trimming.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-025", "SRC-030" ] }, { "id": "sig-c14n-de-pretransform-representation-ref", "name": "Pre-transform representation reference", "description": "Reference and digest identifying the retained original host representation held by the payload model, against which coverage claims can be checked.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-023" ] } ], "artifacts": [ { "id": "sig-c14n-artifact-selection-exclusion-map", "name": "Selection and exclusion map", "description": "The structured statement of exactly which parts of the input are covered and which are excluded, with reasons, in whichever addressing scheme the input family uses.", "media_or_form": [ "structured record", "byte-range or component table", "node selection expression" ], "serial": true, "identity_strategy": "Master-system map identifier bound to one chain manifest version; where the input family publishes a governed assertion label, that label is carried as a secondary reference.", "source_refs": [ "SRC-017", "SRC-016" ] }, { "id": "sig-c14n-artifact-fidelity-record", "name": "Derivation fidelity record", "description": "The record of irreversible steps, discarded information, uncovered content and the reference plus digest of the retained pre-transform representation, so that a coverage claim remains falsifiable after the fact.", "media_or_form": [ "structured record", "narrative note" ], "serial": true, "identity_strategy": "Master-system fidelity record identifier bound to one chain manifest version; it carries a reference to the retained representation rather than the representation itself.", "source_refs": [ "SRC-023", "SRC-025", "SRC-020" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-c14n-layer-context-security", "name": "Context binding and fail-closed posture", "description": "The values that separate this derivation from every other use of the same key and algorithm, and the declarations that require an external evaluator to refuse rather than proceed: domain separation and purpose binding, explicit typing, external additional authenticated data, criticality marking, complexity limits and recorded divergence.", "source_refs": [ "SRC-021", "SRC-004", "SRC-007", "SRC-008", "SRC-023", "SRC-026", "SRC-027" ], "findings": [ { "id": "sig-c14n-finding-domain-binding", "name": "Domain separation and purpose or context binding", "description": "The values mixed into the protected bytes so that a derivation cannot be lifted into another setting: a domain separation tag or structure context label, the declared proof purpose, the domain or audience, a challenge or nonce, an explicit type label, and externally supplied additional authenticated data. All must sit in the protected region; attributes taken from an unprotected region are never bound.", "source_refs": [ "SRC-026", "SRC-004", "SRC-008", "SRC-027", "SRC-007", "SRC-022" ], "questions": [ { "id": "sig-c14n-q-domain-tag", "text": "Which domain separation string or structure context label is incorporated into the protected bytes, and how is it made unique and versioned?", "kind": "security", "answer_data": [ "Domain separation tag or context text string", "Uniqueness construction rule including application name and version", "Suite or encoding identifier component", "Byte encoding of the tag" ] }, { "id": "sig-c14n-q-purpose-binding", "text": "For which declared purpose are these protected bytes valid, and which values bind them to an audience, domain or session?", "kind": "authority", "answer_data": [ "Proof purpose value", "Domain or audience value", "Challenge or nonce value", "Prior-proof reference where proofs are chained" ] }, { "id": "sig-c14n-q-explicit-type", "text": "Which explicit type label distinguishes this protected structure from other structures the same key may protect?", "kind": "classification", "answer_data": [ "Explicit type label", "Content type label", "Reference to the mutually exclusive validation rule for this type" ] }, { "id": "sig-c14n-q-external-aad", "text": "Which externally supplied additional authenticated data is bound into the derivation, and is an empty value distinguishable from an absent one?", "kind": "composition", "answer_data": [ "External additional authenticated data value or reference", "Empty-versus-absent determination", "Position of the binding within the protected structure" ] }, { "id": "sig-c14n-q-freshness-window", "text": "Which instants bound the period in which these protected bytes are acceptable?", "kind": "temporal", "answer_data": [ "Creation instant in RFC 3339 form with seconds and an explicit offset", "Expiry instant", "Acceptance window duration", "Conversion note where the source format uses integer epoch seconds or a schema dateTime" ] } ], "data_elements": [ { "id": "sig-c14n-de-domain-separation-tag", "name": "Domain separation tag or context label", "description": "The application-unique, versioned string or structure context label incorporated into the protected bytes to prevent cross-protocol reuse.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-008" ] }, { "id": "sig-c14n-de-proof-purpose", "name": "Declared proof purpose", "description": "The purpose for which the derivation is valid, acting as a safeguard against reuse for a different purpose.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-c14n-de-domain-audience", "name": "Bound domain or audience", "description": "Security domain, audience or application tag to which the protected bytes are locked.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-022", "SRC-027" ] }, { "id": "sig-c14n-de-challenge-nonce", "name": "Challenge or nonce", "description": "One-time value bound into the derivation to constrain replay within a time window.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-022", "SRC-023" ] }, { "id": "sig-c14n-de-explicit-type-label", "name": "Explicit type label", "description": "Type declaration distinguishing this protected structure from other structures the same key protects.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027", "SRC-007" ] }, { "id": "sig-c14n-de-external-aad", "name": "External additional authenticated data", "description": "Externally supplied data bound into the derivation, with an explicit distinction between a zero-length value and an absent one.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "sig-c14n-de-created-instant", "name": "Derivation creation instant", "description": "Instant at which the protected bytes were created, recorded separately from the instant this model observed or ingested the record.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-022" ] } ], "artifacts": [], "inline_only_rationale": "Context-binding values must live inside the protected byte structure itself to have any effect. Extracting them into separately addressable artifacts would create a second copy outside the protected region that could drift from the bound values and be mistaken for authoritative, which is precisely the unprotected-attribute failure the cited specifications warn against. The acceptance decision these values feed is made by the referenced verification and policy models, not here." }, { "id": "sig-c14n-finding-threat-posture", "name": "Criticality declarations, complexity limits and divergence evidence", "description": "The per-derivation declaration of which steps and parameters are critical and must be understood or the derivation refused, which canonicalization-layer attack classes the chain claims to resist and by which declared mechanism, which input-complexity limits keep derivation bounded against poison inputs, and what evidence is recorded when two implementations diverge. This model declares and records; refusal, evaluation and enforcement are executed elsewhere.", "source_refs": [ "SRC-007", "SRC-008", "SRC-023", "SRC-021", "SRC-027", "SRC-030", "SRC-022" ], "questions": [ { "id": "sig-c14n-q-critical-steps", "text": "Which chain steps and parameters are marked critical so that an unrecognised one must be refused rather than ignored?", "kind": "requirement", "answer_data": [ "Critical step or parameter label list", "Must-understand flag", "Declared failure disposition", "Requirement that every critical label also appear in the protected region" ] }, { "id": "sig-c14n-q-threat-coverage", "text": "Which canonicalization-layer attack classes does this derivation claim to resist, and by which declared mechanism?", "kind": "security", "answer_data": [ "Attack class: replay, substitution, wrapping or relocation, parser differential, confused deputy, cross-protocol reuse", "Reference to the declaration that mitigates it", "Residual risk note" ] }, { "id": "sig-c14n-q-complexity-limits", "text": "Which input complexity limits bound the derivation so that a hostile input cannot exhaust the processor?", "kind": "constraint", "answer_data": [ "Nesting depth limit", "Node, quad or component count limit", "Iteration or time budget", "Limit-exceeded disposition" ] }, { "id": "sig-c14n-q-transform-allowlist", "text": "Which transform algorithms are admissible for this derivation, and which are refused outright?", "kind": "decision", "answer_data": [ "Admitted algorithm identifier list", "Refused algorithm identifier list, typically covering programmable transforms", "Deciding authority reference", "Decision instant" ] }, { "id": "sig-c14n-q-divergence-report", "text": "When two implementations derive different protected bytes from the same declared input, what evidence is recorded?", "kind": "evidence", "answer_data": [ "Divergence event instant in RFC 3339 form with seconds and an explicit offset", "Observation or ingestion instant recorded separately", "Diverging implementation pins", "Differing digest values and the disputed step index" ] } ], "data_elements": [ { "id": "sig-c14n-de-critical-step-label", "name": "Critical step or parameter label", "description": "Label of a step or parameter declared must-understand, so that an evaluator encountering an unrecognised one refuses the derivation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-c14n-de-threat-class-claim", "name": "Resisted attack class claim", "description": "Declared attack class the derivation claims to resist, paired with the declaration that provides the resistance.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023", "SRC-027", "SRC-022" ] }, { "id": "sig-c14n-de-complexity-limit", "name": "Input complexity limit", "description": "Declared bound on depth, size, node or quad count, iterations or time budget for the derivation.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-023", "SRC-028" ] }, { "id": "sig-c14n-de-admitted-algorithm-list", "name": "Admitted transform allow-list reference", "description": "Reference to the list of transform algorithms admissible for this derivation, maintained by the canonicalization profile owner.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023", "SRC-030" ] }, { "id": "sig-c14n-de-divergence-observation", "name": "Divergence observation", "description": "Record of a reproduction mismatch, carrying the event instant, the separate observation instant, the diverging pins and the disputed step.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "This finding records declarations and observations, not enforcement. The evaluator that refuses an unrecognised critical step, the runtime that applies complexity limits, and the audit trail that stores the outcome are owned by referenced models. Publishing these declarations as artifacts of this model would present a second, non-authoritative enforcement surface that could be mistaken for the operative policy, so they are carried inline and consumed by the models that own evaluation and enforcement." } ] } ] }, { "id": "sig-proj-binding-forms", "name": "Proof Binding Forms and Attachment Topology", "description": "The concern of where a proof physically sits relative to the octets it covers and relative to its host artifact, how a consumer discovers and reconstructs those octets, and which declared parameters are inside or outside the integrity boundary.", "rationale": "Every signature specification examined defines its own vocabulary for the same three underlying arrangements — proof inside the data, data inside the proof, and proof separate from the data — and each defines a different mechanism for locating detached content and for marking parameters as protected. Because RFC 9052 states outright that structures including a context string in the signing input cannot be converted, and RFC 7515 states that Compact Serialization can carry neither an unprotected header nor multiple signatures, binding form and parameter placement must be modelled explicitly before any interoperability claim can be made.", "source_refs": [ "SRC-007", "SRC-008", "SRC-006", "SRC-016", "SRC-004", "SRC-013" ], "layers": [ { "id": "sig-proj-attachment-topology", "name": "Attachment Topology and Multi-Proof Structure", "description": "Classification of the binding form for a proof instance and the structural arrangement when more than one proof covers the same subject, including peer signatures, countersignatures and ordered chains.", "source_refs": [ "SRC-007", "SRC-008", "SRC-015", "SRC-006", "SRC-016", "SRC-004", "SRC-013" ], "findings": [ { "id": "sig-proj-form-classification", "name": "Binding form classification and per-projection availability", "description": "Records which binding form a proof instance uses — enveloped (proof inside the covered data), enveloping (covered data inside the proof), detached (proof and data separate), or internally detached (both in one container without nesting) — at which level the classification applies, and whether the chosen target projection can express it at all. Form availability is projection-specific and asymmetric: XML Signature defines all three classical forms, CMS supports enveloping and detached via omitted eContent, PAdES packaging is enveloped at document level while the embedded CMS is detached over a byte range, and Data Integrity attaches the proof as a property of the secured document.", "source_refs": [ "SRC-006", "SRC-016", "SRC-004", "SRC-034", "SRC-036", "SRC-013" ], "questions": [ { "id": "sig-proj-q-form-kind", "text": "Which binding form does this proof instance use, and at which level (payload level or host-artifact level) is that classification asserted?", "kind": "classification", "answer_data": [ "Binding form code from a closed local vocabulary (enveloped, enveloping, detached, internally-detached)", "Level at which the form is asserted (payload, host artifact, container)", "Free-text note where the two levels disagree" ] }, { "id": "sig-proj-q-form-containment", "text": "What does the host artifact actually contain — the proof only, the covered data only, or both — and where inside it does the proof node or dictionary sit?", "kind": "composition", "answer_data": [ "Containment indicator for proof and for covered data", "Attachment point expressed in the host's own addressing scheme (element path, dictionary key, object index, JSON member)", "Reference to the host artifact record" ] }, { "id": "sig-proj-q-form-prohibited", "text": "Which binding forms are unavailable for the declared target projection, and which specification statement establishes that unavailability?", "kind": "constraint", "answer_data": [ "List of unsupported form codes for the projection", "Citation with specification identifier, version and clause where retrievable", "Verification status of the citation (verified or unverified)" ] }, { "id": "sig-proj-q-form-choice", "text": "On what recorded criteria was this binding form chosen over the alternatives that the projection does support?", "kind": "decision", "answer_data": [ "Selection rationale text", "Constraint drivers considered (payload size, host immutability, consumer capability, archival requirement)", "Identifier of the principal or role that made the selection" ] } ], "data_elements": [ { "id": "sig-proj-binding-form-code", "name": "Binding form code", "description": "Closed-vocabulary code for the arrangement of proof and covered data.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-013" ] }, { "id": "sig-proj-target-projection-code", "name": "Target projection code", "description": "Identifier of the concrete signature binding family the record refers to (CMS/CAdES, XMLDSig/XAdES, JWS/JAdES, COSE, PDF/PAdES, Data Integrity).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-006", "SRC-016", "SRC-004" ] }, { "id": "sig-proj-form-support-flag", "name": "Form supported by projection", "description": "Whether the declared binding form is expressible in the declared target projection.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-006" ] }, { "id": "sig-proj-form-selection-note", "name": "Form selection rationale", "description": "Recorded reason for choosing this binding form, including the constraints that excluded the alternatives.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Binding form classification is a small set of coded assertions about an existing proof instance and its host. It produces no document of its own: the concrete encoding lives in the projection templates, and the host artifact is owned by the host model. Materialising a separate artifact here would duplicate the projection template and invite a stored classification to drift from the instance it describes." }, { "id": "sig-proj-multisig-topology", "name": "Multi-proof topology, ordering and countersignature targets", "description": "Records how many proofs cover the same subject and how they relate: unordered peers, ordered chains where each proof references its predecessor, and countersignatures that cover another proof's cryptographic value rather than the payload. The distinction is load-bearing because CMS carries multiple SignerInfos and a countersignature unsigned attribute, COSE separates COSE_Sign from COSE_Sign1 and moved countersignatures into a separate specification with changed coverage, JWS General JSON Serialization carries a signatures array that Compact Serialization cannot represent, and Data Integrity distinguishes proof sets from proof chains linked by previousProof.", "source_refs": [ "SRC-007", "SRC-008", "SRC-015", "SRC-006", "SRC-016", "SRC-004", "SRC-035" ], "questions": [ { "id": "sig-proj-q-multi-count", "text": "How many proofs cover this subject, and which of them are peers versus proofs taken over another proof's signature value?", "kind": "relationship", "answer_data": [ "Count of proofs bound to the subject", "Per-proof role code (peer, countersignature, archive timestamp, document timestamp)", "Reference from each countersignature to its target proof" ] }, { "id": "sig-proj-q-multi-order", "text": "Is the multi-proof arrangement unordered or ordered, and which element carries the ordering?", "kind": "composition", "answer_data": [ "Topology kind (set or chain)", "Ordering mechanism identifier (previousProof reference, nesting depth, attribute position)", "Sequence index per proof where an order exists" ] }, { "id": "sig-proj-q-multi-capacity", "text": "Does the declared serialization variant physically permit the recorded number of proofs, or would expressing them force a structural change to the instance?", "kind": "constraint", "answer_data": [ "Maximum proofs expressible by the declared variant", "Structural change required if exceeded", "Blocking indicator when the change would alter the signing input" ] }, { "id": "sig-proj-q-multi-coverage-evidence", "text": "What evidence records that a countersignature covers the target proof's cryptographic value and not merely the same payload?", "kind": "evidence", "answer_data": [ "Countersignature coverage descriptor (target signature value, target protected attributes, payload)", "Specification citation for the countersignature construction used", "Version marker distinguishing countersignature constructions with different coverage" ] } ], "data_elements": [ { "id": "sig-proj-proof-count", "name": "Bound proof count", "description": "Number of distinct proofs bound to the same covered subject in this instance.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "sig-proj-topology-kind", "name": "Multi-proof topology kind", "description": "Whether the proofs form an unordered set, an ordered chain, or a nested countersignature structure.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-015" ] }, { "id": "sig-proj-countersign-target-ref", "name": "Countersignature target reference", "description": "Reference from a countersigning proof to the proof whose cryptographic value it covers.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-006", "SRC-035" ] }, { "id": "sig-proj-proof-order-index", "name": "Proof order index", "description": "Position of a proof within an ordered chain, present only when the topology is a chain.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Multi-proof topology is a relationship graph over proof records that already exist in the adopting Dimension. It is expressed as references and ordering indices, not as a separate document, and each proof's own bytes belong to its projection instance. Emitting a topology artifact would create a second, unsigned copy of a structure whose authority derives entirely from the signed instances themselves." } ] }, { "id": "sig-proj-payload-binding", "name": "Payload Discovery and Signing-Input Declarations", "description": "How a consumer locates the exact octets a proof covers, and which declared transformation, context and encoding facts are needed to reconstruct the signing input without executing it here.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-006", "SRC-016", "SRC-004", "SRC-036", "SRC-037" ], "findings": [ { "id": "sig-proj-payload-discovery", "name": "Detached payload discovery and reference descriptors", "description": "Records the descriptors a consumer needs to find and confirm detached content: URI or locator, digest algorithm and value, transform chain, byte range, HTTP header set, and the concatenation order when several objects form one payload. XML Signature dereferences Reference URIs with same-document and fragment rules and allows at most one Reference to omit the URI; JAdES sigD identifies one or more detached objects that are processed and concatenated into the payload; COSE places a nil object and makes unchanged transport an application responsibility; CMS omits eContent entirely; and PAdES binds by a ByteRange over the host file. Resolution itself is performed by the referenced runtime.", "source_refs": [ "SRC-007", "SRC-008", "SRC-006", "SRC-016", "SRC-036", "SRC-037", "SRC-013" ], "questions": [ { "id": "sig-proj-q-payload-identity", "text": "Which identifier or locator designates each detached payload object, and does it come from a master system, a governed IRI scheme or a Dimension-assigned identifier?", "kind": "identity", "answer_data": [ "Locator value with its scheme", "Identifier class (master-system, governed IRI, Dimension ULID)", "Identifier stability statement" ] }, { "id": "sig-proj-q-payload-inputs", "text": "Which resolution inputs must a consumer be given to reconstruct the exact signed octets from the locator?", "kind": "process", "answer_data": [ "Ordered transform or processing chain identifiers", "Byte range or fragment expression", "HTTP header names and order where a header-based mechanism is used", "Concatenation order for multi-object payloads" ] }, { "id": "sig-proj-q-payload-unresolvable", "text": "What is recorded when a detached reference cannot be dereferenced or resolves to octets whose digest does not match the declared value?", "kind": "exception", "answer_data": [ "Resolution state code (resolved, unresolvable, digest-mismatch, ambiguous)", "Observation time of the resolution attempt", "Identifier of the external resolver that reported the outcome" ] }, { "id": "sig-proj-q-payload-mediation", "text": "Is the payload bound through a declared digest or directly over transmitted octets, and what substitution risk does that choice carry?", "kind": "quality", "answer_data": [ "Binding mediation code (digest-mediated, octet-direct)", "Digest algorithm identifier in its native identifier space", "Recorded risk note on payload substitution or transport mutation" ] } ], "data_elements": [ { "id": "sig-proj-payload-locator", "name": "Payload locator", "description": "URI, fragment, byte range or other locator identifying a detached payload object.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-037", "SRC-036" ] }, { "id": "sig-proj-payload-digest-value", "name": "Payload digest value", "description": "Declared digest of the payload object as carried by the binding; integrity metadata only, never an identifier.", "value_kind": "binary", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-037" ] }, { "id": "sig-proj-payload-digest-method", "name": "Payload digest method identifier", "description": "Digest algorithm identifier recorded verbatim in the identifier space of the source projection (OID, URI, string token or integer label).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-032", "SRC-006" ] }, { "id": "sig-proj-payload-object-order", "name": "Payload object concatenation order", "description": "Ordered list establishing how multiple detached objects are combined into a single payload.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-037" ] }, { "id": "sig-proj-resolution-failure-state", "name": "Reference resolution state", "description": "Externally reported state of the most recent attempt to resolve a detached reference, with its observation time.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "These are reference descriptors that point at octets held by the host or payload model. The model must not copy the payload, because a copy would be a second candidate for the signing input and could silently diverge from the signed octets. Keeping the descriptors inline, with resolution delegated to the external resolver, preserves a single authoritative source for the covered bytes." }, { "id": "sig-proj-signing-input", "name": "Transformation, canonicalization and signing-input declarations", "description": "Records the declared method by which covered data becomes the octets actually signed: the canonicalization or transformation algorithm and the structure it operates over, any context string or externally supplied authenticated data folded into the input, and payload-encoding flags. The projections diverge sharply — Canonical XML over an XPath node-set with an enveloped-signature transform, DER-encoded SignedAttrs in CMS, a CBOR Sig_structure whose first element is a context string plus external_aad, a base64url concatenation in JWS that changes shape when b64 is false, and RDF Dataset Canonicalization or JCS for Data Integrity with a mandatory error when a JSON-LD processor drops data. All computation is external.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-006", "SRC-016", "SRC-004" ], "questions": [ { "id": "sig-proj-q-transform-method", "text": "Which transformation or canonicalization algorithm is declared, and over which node-set, octet range or dataset does it operate?", "kind": "definition", "answer_data": [ "Transformation method identifier in its native identifier space", "Structure the method consumes (node-set, octet stream, RDF dataset, CBOR item)", "Ordered position of the method within a transform chain" ] }, { "id": "sig-proj-q-signing-context", "text": "Which context string or externally supplied authenticated data is folded into the signing input without being transmitted inside the proof?", "kind": "security", "answer_data": [ "Context string value where the projection defines one", "Reference to the external authenticated data and its construction rule", "Statement of how sender and recipient agree on that construction" ] }, { "id": "sig-proj-q-transform-determinism", "text": "Under which recorded conditions does the declared transformation become lossy or non-deterministic, and how is that condition captured rather than silently accepted?", "kind": "validation", "answer_data": [ "Enumerated non-determinism conditions (dropped terms, comment handling, whitespace, encoding variance)", "Required error behaviour cited from the defining specification", "Condition state as reported by the external processor" ] }, { "id": "sig-proj-q-transform-portability", "text": "Can the declared transformation chain be expressed in the target projection, and if not, what blocking reason is recorded?", "kind": "interoperability", "answer_data": [ "Target-projection equivalent method identifier or an unmapped marker", "Blocking reason code", "Reference to the loss ledger entry raised by the mismatch" ] } ], "data_elements": [ { "id": "sig-proj-transform-method-id", "name": "Transformation method identifier", "description": "Identifier of a declared transformation or canonicalization step, recorded verbatim from its defining specification.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016", "SRC-004", "SRC-008" ] }, { "id": "sig-proj-signing-input-context", "name": "Signing-input context string", "description": "Projection-defined context value that participates in the signing input and distinguishes structure variants.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "sig-proj-external-aad-ref", "name": "External authenticated data reference", "description": "Reference to data that is authenticated by the proof but transmitted outside it, together with its agreed construction rule.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "sig-proj-encoding-flag", "name": "Payload encoding flag", "description": "Declared payload-encoding behaviour that alters signing-input construction, such as the JWS b64 parameter.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "The signing input is an emergent byte string produced by an external processor; storing it here would create an unsigned duplicate that could be mistaken for the authoritative input. Only the declarations needed to reconstruct it are held, as inline coded values and references, so that reconstruction remains the runtime's responsibility." } ] }, { "id": "sig-proj-protected-parameters", "name": "Parameter Protection, Criticality and Key Carriage", "description": "Which declared parameters sit inside the integrity boundary, which must be understood by a consumer, and how the signer, key and accompanying evidence are referenced by the binding.", "source_refs": [ "SRC-007", "SRC-008", "SRC-031", "SRC-006", "SRC-016", "SRC-004", "SRC-035" ], "findings": [ { "id": "sig-proj-parameter-protection", "name": "Protected versus unprotected placement and critical-parameter declaration", "description": "Records, per declared parameter, whether it is integrity protected, whether it is marked as must-understand, and whether it may be added or replaced after signing. The projections implement one pattern with different mechanics: JWS keeps protected and unprotected header members disjoint and requires crit to appear only in the protected header; COSE treats a crit label absent from the protected bucket as a fatal error and reserves core algorithm labels from omission rules; CMS separates DER-encoded signedAttrs from unsignedAttrs; XAdES splits signed from unsigned qualifying properties and XML Signature only protects SignatureProperties that a SignedInfo Reference actually covers; JAdES confines all unprotected content to a single etsiU array.", "source_refs": [ "SRC-007", "SRC-008", "SRC-006", "SRC-016", "SRC-035", "SRC-037" ], "questions": [ { "id": "sig-proj-q-param-placement", "text": "For each declared parameter, is it inside the integrity boundary or in an unprotected or unsigned container?", "kind": "classification", "answer_data": [ "Parameter name in its native identifier space", "Protection class (protected, unprotected, signed-property, unsigned-property, unreferenced)", "Container identifier within the instance" ] }, { "id": "sig-proj-q-param-must-understand", "text": "Which parameters must a consumer understand in order to process the proof, and are they listed in the projection's critical-parameter mechanism?", "kind": "requirement", "answer_data": [ "List of must-understand parameter names", "Presence in the projection's criticality list", "Specification rule that mandates listing" ] }, { "id": "sig-proj-q-param-unsupported", "text": "What must a consumer do on meeting a critical parameter it does not implement, and where is that outcome recorded?", "kind": "exception", "answer_data": [ "Required consumer behaviour cited from the defining specification", "Outcome code recorded by the external processor", "Reference to the conformance report entry" ] }, { "id": "sig-proj-q-param-post-signing", "text": "Which parameters may be added or replaced after signing without invalidating the proof, and which are immutable?", "kind": "state", "answer_data": [ "Post-signing mutability class per parameter", "Permitted augmentation categories (timestamps, validation data, certificate values)", "Immutability assertion for parameters inside the signing input" ] }, { "id": "sig-proj-q-param-trust-use", "text": "Which parameters feed a trust decision and therefore must not be accepted from an unprotected container?", "kind": "security", "answer_data": [ "Parameters flagged as trust-relevant", "Protection status of each flagged parameter", "Risk note where a trust-relevant parameter is unprotected" ] } ], "data_elements": [ { "id": "sig-proj-parameter-name", "name": "Declared parameter name", "description": "Name or label of a parameter carried by the binding, recorded verbatim in its native identifier space.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-006" ] }, { "id": "sig-proj-parameter-protection-class", "name": "Parameter protection class", "description": "Whether the parameter is integrity protected, unprotected, a signed property, an unsigned property or present but unreferenced.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-016", "SRC-035" ] }, { "id": "sig-proj-critical-flag", "name": "Critical parameter flag", "description": "Whether the parameter is declared as must-understand through the projection's criticality mechanism.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-proj-post-signing-mutability", "name": "Post-signing mutability class", "description": "Whether the parameter may be added, replaced or must remain unchanged after the proof is produced.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-037" ] } ], "artifacts": [], "inline_only_rationale": "Parameter placement and criticality are per-parameter assertions about an instance that already exists in a concrete encoding. The authoritative copy of each parameter is inside the signed structure; recording it here as inline coded values keeps this model descriptive. A separate artifact would be an unsigned restatement of protected content and would create a forgeable second source." }, { "id": "sig-proj-key-identity-carriage", "name": "Signer and key identification mechanisms and carried evidence references", "description": "Records how a binding points at the verification key or signing certificate and what supporting evidence it carries. The mechanisms are not interchangeable: JWS offers kid, jwk, jku, x5c, x5u and thumbprint headers; COSE defines x5bag, x5chain, x5t and x5u with the end-entity identification required to be integrity protected, and warns that kid values are not unique; CMS identifies the signer by issuerAndSerialNumber or subjectKeyIdentifier with certificates and CRLs in the SignedData; XML Signature uses KeyInfo, KeyValue and KeyInfoReference; Data Integrity uses a verificationMethod URL checked against a controller. Carried certificate, revocation and timestamp material is recorded as evidence references only.", "source_refs": [ "SRC-007", "SRC-008", "SRC-031", "SRC-006", "SRC-016", "SRC-004", "SRC-036" ], "questions": [ { "id": "sig-proj-q-key-mechanism", "text": "By which mechanism does this binding identify the verification key or signing certificate, and is that mechanism resolvable without out-of-band data?", "kind": "identity", "answer_data": [ "Key reference mechanism code", "Mechanism value as carried", "Self-contained or out-of-band resolution indicator" ] }, { "id": "sig-proj-q-key-provenance", "text": "Where did the carried certificate, chain or key material originate, and is it held as a copy, a reference or a digest?", "kind": "provenance", "answer_data": [ "Carriage mode (embedded copy, URI reference, thumbprint)", "Source system or issuer reference for the carried material", "Ingestion time at which this model recorded the carriage fact" ] }, { "id": "sig-proj-q-key-equivalence", "text": "Does the target projection offer an equivalent key-identification parameter, and what is lost if it does not?", "kind": "interoperability", "answer_data": [ "Target-projection equivalent parameter or unmapped marker", "Description of the degraded identification (for example chain reduced to a thumbprint)", "Loss ledger entry reference" ] }, { "id": "sig-proj-q-key-protection", "text": "Is the key-identification parameter integrity protected in this binding, and if not, what risk note is recorded?", "kind": "constraint", "answer_data": [ "Protection status of the key-identification parameter", "Specification requirement about protecting it", "Recorded risk note and its owning role" ] } ], "data_elements": [ { "id": "sig-proj-key-reference-mechanism", "name": "Key reference mechanism", "description": "Code for the mechanism a binding uses to point at the verification key or signing certificate.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-031", "SRC-006", "SRC-004" ] }, { "id": "sig-proj-key-reference-value", "name": "Key reference value", "description": "The carried identifier value, recorded verbatim without normalisation, such as a kid, subject key identifier, thumbprint or verification method URL.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-008", "SRC-006", "SRC-004" ] }, { "id": "sig-proj-carried-cert-evidence-ref", "name": "Carried certificate or revocation evidence reference", "description": "Reference to certificate, chain, revocation or timestamp material carried by the binding, held as a pointer into the PKI or time-stamp model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-031", "SRC-006", "SRC-036" ] }, { "id": "sig-proj-key-param-protected-flag", "name": "Key parameter protected flag", "description": "Whether the key-identification parameter is inside the integrity boundary of this binding.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-031", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Only pointers and carriage facts belong here. Certificates, chains, revocation responses and timestamp tokens are authoritative artifacts of the PKI and time-stamp models; duplicating their bytes into this model would create a competing copy whose freshness and trust status this model has no mandate to determine. Inline references keep ownership where the relation contract places it." } ] } ] }, { "id": "sig-proj-projection-interop", "name": "Proof Projections, Loss and Conformance Reporting", "description": "The concern of expressing one logical proof in a concrete binding, of recording exactly what each expression loses, and of deciding whether movement between bindings is permitted, blocked, or permitted only under recorded loss acceptance.", "rationale": "The examined bindings are alternative projections of overlapping but non-identical concepts, and none is canonical. RFC 9052 states that COSE_Sign and COSE_Sign1 cannot be converted because the structure identity is part of the signing input; RFC 7515 gives Compact Serialization no syntax for an unprotected header; RFC 7797 forbids b64=false in JWTs and forbids '.' in unencoded compact payloads; RFC 8118 uses one media type for every PDF version; and W3C VC-JOSE-COSE registers alternative securing mechanisms while saying nothing about converting between them. Losses and blocking conditions must therefore be recorded per source-target pair as first-class content.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-033", "SRC-004", "SRC-034", "SRC-038" ], "layers": [ { "id": "sig-proj-projection-matrix", "name": "Projection Profiles, Templates and the Loss Ledger", "description": "Per-projection encoding profiles with their template requirements, and the ledger of what each source-to-target projection pair loses.", "source_refs": [ "SRC-007", "SRC-008", "SRC-006", "SRC-016", "SRC-004", "SRC-036", "SRC-037", "SRC-038", "SRC-039", "SRC-040", "SRC-041" ], "findings": [ { "id": "sig-proj-projection-profile", "name": "Projection profile and encoding template requirements", "description": "Declares, for each target binding, a versioned profile fixing the serialization variant, required and forbidden parameters, the identifier space used for methods, the media type and content-type parameter, and the governing specification edition. The profile is a declaration, not an encoder: the referenced runtime performs the encoding. The identifier space differs by projection — ASN.1 OIDs in CMS, algorithm URIs in XML Signature, registered string tokens from the IANA JOSE registries in JWS, integer labels from the COSE registry, and cryptosuite string tokens in Data Integrity — so no profile may be treated as a model-wide default.", "source_refs": [ "SRC-007", "SRC-008", "SRC-032", "SRC-006", "SRC-016", "SRC-004", "SRC-034", "SRC-036", "SRC-037", "SRC-038", "SRC-039", "SRC-040", "SRC-041" ], "questions": [ { "id": "sig-proj-q-profile-identity", "text": "Which identifier names this projection profile, and which registry or specification governs that identifier?", "kind": "identity", "answer_data": [ "Profile identifier following the model identity priority", "Governing registry or specification with its edition", "Owner package that published the profile" ] }, { "id": "sig-proj-q-profile-variant", "text": "Which serialization variant, structural tag or container placement does the profile fix?", "kind": "composition", "answer_data": [ "Variant code (compact, flattened JSON, general JSON, single-signer tag, multi-signer tag, incremental-update revision, proof property)", "Container placement rule", "Constraint on the number of proofs the variant admits" ] }, { "id": "sig-proj-q-profile-parameters", "text": "Which parameters does the profile require, which does it forbid, and which does it leave to the adopting Dimension?", "kind": "requirement", "answer_data": [ "Required parameter list with protection class", "Forbidden parameter list with reason", "Open parameter list delegated to the adopter" ] }, { "id": "sig-proj-q-profile-identifier-space", "text": "In which identifier space does this profile express algorithms and methods, and how are their parameters carried?", "kind": "classification", "answer_data": [ "Identifier space code (OID, URI, registered string token, integer label, cryptosuite token)", "Whether parameters are folded into the identifier or carried separately", "Registry snapshot reference for the identifier space" ] }, { "id": "sig-proj-q-profile-media-type", "text": "Which media type and content-type parameter must accompany an instance produced under this profile?", "kind": "interoperability", "answer_data": [ "Registered media type string", "Content-type or type parameter value carried inside the proof", "Statement of whether the media type distinguishes the serialization variant" ] } ], "data_elements": [ { "id": "sig-proj-profile-id", "name": "Projection profile identifier", "description": "Stable identifier of a versioned projection profile, assigned under the model identity priority and never derived from a date.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-038", "SRC-036" ] }, { "id": "sig-proj-serialization-variant", "name": "Serialization variant code", "description": "The concrete structural variant the profile fixes within its binding family.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-004" ] }, { "id": "sig-proj-method-identifier-space", "name": "Method identifier space", "description": "The identifier space in which the profile expresses algorithm and method identifiers.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-032", "SRC-006", "SRC-016", "SRC-038" ] }, { "id": "sig-proj-profile-media-type", "name": "Profile media type", "description": "Registered media type, and any internal content-type parameter, associated with instances of this profile.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-033", "SRC-034", "SRC-007" ] }, { "id": "sig-proj-profile-spec-citation", "name": "Governing specification citation", "description": "Specification identifier, edition or version, and clause reference where retrievable, plus a verification status flag for paywalled or non-retrievable clauses.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-036", "SRC-039", "SRC-040", "SRC-041" ] } ], "artifacts": [ { "id": "sig-proj-cms-cades-template", "name": "CMS/CAdES encoding template", "description": "Template declaring the SignedData shape for a profile: encapsulated or omitted eContent, mandatory content-type and message-digest signed attributes, DER-encoded SignedAttrs, signer identification form, certificate and CRL carriage, unsigned attributes for countersignatures and timestamps, and the baseline level targeted. Clause-level CAdES attribute tables are marked unverified where the ETSI text was not machine-retrievable.", "media_or_form": [ "ASN.1 SignedData structure (DER or BER encoding)", "application/pkcs7-signature or application/pkcs7-mime instance", "Attribute profile table with baseline level" ], "serial": false, "identity_strategy": "Master-system identifier of the profile in the issuing signing service where one exists; otherwise the governed IRI minted by the owner package under its controlled namespace; otherwise a Dimension-assigned ULID. Never a date, version label or digest.", "source_refs": [ "SRC-006", "SRC-009", "SRC-039" ] }, { "id": "sig-proj-xmldsig-xades-template", "name": "XMLDSig/XAdES encoding template", "description": "Template declaring the ds:Signature shape: CanonicalizationMethod and SignatureMethod URIs, Reference set with transform chains and URI usage, enveloped-signature transform where applicable, ds:Object and Manifest placement, KeyInfo form, and QualifyingProperties attachment with the typed SignedProperties reference and the signed/unsigned property split.", "media_or_form": [ "XML ds:Signature element", "XAdES QualifyingProperties within ds:Object", "Transform and canonicalization URI list" ], "serial": false, "identity_strategy": "Master-system identifier where the signing service holds one; otherwise a governed IRI in the owner's namespace reusing W3C and ETSI identifiers verbatim for standard components; otherwise a Dimension-assigned ULID. Never a date.", "source_refs": [ "SRC-016", "SRC-035", "SRC-040" ] }, { "id": "sig-proj-jws-jades-template", "name": "JWS/JAdES encoding template", "description": "Template declaring the JWS shape: serialization variant, protected and unprotected header membership with the disjointness rule, crit list, b64 usage and its restrictions, key-identification headers, detached payload handling, and for JAdES the sigD detached-object mechanism and the single etsiU unprotected array.", "media_or_form": [ "JWS Compact Serialization string", "JWS General or Flattened JSON Serialization object", "application/jose or application/jose+json instance", "Header parameter profile table" ], "serial": false, "identity_strategy": "Master-system profile identifier where available; otherwise a governed IRI, with header parameter names taken verbatim from the IANA JOSE registry snapshot; otherwise a Dimension-assigned ULID. Never a date.", "source_refs": [ "SRC-007", "SRC-014", "SRC-037", "SRC-038" ] }, { "id": "sig-proj-cose-template", "name": "COSE encoding template", "description": "Template declaring the COSE shape: single-signer or multi-signer structure with its CBOR tag, protected and unprotected bucket membership, integer algorithm labels, crit label constraints, detached payload as a nil object, external authenticated data construction, X.509 carriage parameters and countersignature form with its coverage semantics.", "media_or_form": [ "COSE_Sign or COSE_Sign1 CBOR structure", "Tagged CBOR item (tag 98 or tag 18)", "application/cose instance", "Header label profile table" ], "serial": false, "identity_strategy": "Master-system profile identifier where available; otherwise a governed IRI, with header labels and algorithm values taken verbatim from the IANA COSE registry snapshot; otherwise a Dimension-assigned ULID. Never a date.", "source_refs": [ "SRC-008", "SRC-015", "SRC-031", "SRC-032" ] }, { "id": "sig-proj-pades-template", "name": "PDF/PAdES encoding template", "description": "Template declaring the PDF signature shape: signature dictionary with its Filter and SubFilter pair, the ByteRange covering the file except the signature octets, placement in an incremental update revision, document timestamp revisions, and Document Security Store carriage of validation material for the targeted baseline level. ISO clause content is paywalled and ETSI clause text was not machine-retrievable, so structural requirements are recorded as an unverified alignment target.", "media_or_form": [ "PDF signature dictionary within an incremental update", "Detached CMS object referenced by SubFilter", "application/pdf host instance", "Document Security Store entry set" ], "serial": false, "identity_strategy": "Master-system identifier from the signing or archiving service where one exists; otherwise a governed IRI naming the PAdES baseline level and profile; otherwise a Dimension-assigned ULID. Never a date and never the PDF revision number.", "source_refs": [ "SRC-033", "SRC-036", "SRC-041", "SRC-042" ] }, { "id": "sig-proj-data-integrity-template", "name": "W3C Data Integrity encoding template", "description": "Template declaring the proof property shape: proof type and cryptosuite token, verification method reference, proof purpose, optional created, expires, domain, challenge and nonce, proofValue encoding, proof-set versus proof-chain arrangement with previousProof linkage, and the required transformation with its mandatory error on dropped data.", "media_or_form": [ "JSON or JSON-LD secured document with a proof property", "DataIntegrityProof object or array", "Cryptosuite and context reference list" ], "serial": false, "identity_strategy": "Master-system identifier of the issuing service where available; otherwise the governed IRI of the cryptosuite and profile, with the cryptosuite token treated as an opaque governed string even when it embeds a year; otherwise a Dimension-assigned ULID. Never a date as identifier.", "source_refs": [ "SRC-004", "SRC-034" ] } ], "inline_only_rationale": null }, { "id": "sig-proj-loss-ledger", "name": "Projection loss ledger and loss reporting", "description": "Records, per source-to-target projection pair, which of the enumerated loss classes are triggered and with what severity. The enumerated classes are: proof purpose or commitment, signer and key identity, signed properties, canonicalization and transformation, detached references, countersignatures, timestamps, certificate and revocation evidence, multi-signature topology, and long-term validation material. Losses are structural facts about the pair, not judgements about a particular instance, and their acceptance is an owner decision recorded against the ledger entry.", "source_refs": [ "SRC-007", "SRC-008", "SRC-015", "SRC-006", "SRC-009", "SRC-016", "SRC-004", "SRC-035", "SRC-036", "SRC-042" ], "questions": [ { "id": "sig-proj-q-loss-classes", "text": "Which enumerated loss classes does this source-to-target pair trigger, and at what severity is each recorded?", "kind": "measurement", "answer_data": [ "Triggered loss class codes", "Severity per class (none, degraded, dropped, inexpressible)", "Aggregate blocking indicator derived from severities" ] }, { "id": "sig-proj-q-loss-element", "text": "Which concrete parameter, property or structure is dropped, downgraded or re-encoded for each triggered class?", "kind": "evidence", "answer_data": [ "Source element name in its native identifier space", "Target element name or an explicit absence marker", "Description of the downgrade where the target expresses a weaker form" ] }, { "id": "sig-proj-q-loss-cause", "text": "Is a given loss caused by the target projection's own structure or only by the options selected in the chosen profile?", "kind": "relationship", "answer_data": [ "Cause class (structural or profile-option)", "Reference to the profile option that could remove a profile-caused loss", "Specification citation supporting the structural cause" ] }, { "id": "sig-proj-q-loss-assessment-time", "text": "When was this loss assessment made, against which profile and specification versions, and when was it last re-checked?", "kind": "temporal", "answer_data": [ "Assessment event time in RFC 3339 with seconds and offset", "Ingestion time at which the assessment was recorded", "Source and target profile versions in force at assessment", "Most recent re-check time" ] }, { "id": "sig-proj-q-loss-acceptance", "text": "Who owns the decision to accept a recorded loss, and where is that acceptance captured?", "kind": "ownership", "answer_data": [ "Accepting role or principal identifier", "Acceptance scope (this pair, this profile version, this instance class)", "Reference to the acceptance record and its expiry" ] } ], "data_elements": [ { "id": "sig-proj-loss-class-code", "name": "Loss class code", "description": "Code from the closed enumeration of projection loss classes covering purpose, identity, signed properties, canonicalization, detached references, countersignatures, timestamps, certificate and revocation evidence, multi-signature topology and long-term validation material.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-015", "SRC-009", "SRC-035" ] }, { "id": "sig-proj-loss-severity", "name": "Loss severity", "description": "Graded severity of a triggered loss class for the pair under assessment.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-008", "SRC-007" ] }, { "id": "sig-proj-lost-element-ref", "name": "Lost or downgraded element reference", "description": "Reference to the specific source element affected and to its target counterpart or absence marker.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "sig-proj-loss-assessment-event-time", "name": "Loss assessment event time", "description": "Time at which the assessment was performed, recorded separately from the time it was ingested into this model.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-proj-loss-acceptance-owner", "name": "Loss acceptance owner", "description": "Role or principal that accepted a recorded loss, with the scope and expiry of that acceptance.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "sig-proj-loss-report", "name": "Projection loss report", "description": "Issued report for one source-to-target projection pair listing every triggered loss class with severity, the affected elements, the structural or profile-option cause, the profile and specification versions assessed, the assessment and ingestion times, and any recorded acceptance. Reports are append-only and superseded by reference; they describe expressive capability and do not assert that any instance was validated.", "media_or_form": [ "Structured loss record set keyed by source-target pair", "Human-readable loss summary rendering", "Machine-readable loss class enumeration with severities" ], "serial": true, "identity_strategy": "Master-system report identifier from the issuing system where one exists; otherwise a governed IRI under the owner namespace combining the source and target profile identifiers with a monotonic sequence value; otherwise a Dimension-assigned ULID. Sequence values are integers or ULIDs and never dates.", "source_refs": [ "SRC-008", "SRC-004", "SRC-036" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-proj-conformance-fallback", "name": "Conversion Safety, Conflicts and Version Distinction", "description": "Whether movement between bindings is permitted at all, how ambiguity and conflicting embedded evidence are handled, and how the three independent version axes are kept apart.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-033", "SRC-004", "SRC-034", "SRC-036" ], "findings": [ { "id": "sig-proj-conversion-safety", "name": "Round-trip impossibility, unsafe fallback, media-type ambiguity and evidence conflicts", "description": "Records the verdict for a proposed movement between bindings and the conditions that block it. Grounded blocking conditions include: COSE single-signer and multi-signer structures cannot be converted because the structure identity is part of the signing input; JWS Compact Serialization has no syntax for an unprotected header and admits only one signature; an unencoded JWS payload may not contain '.' in compact form and may not appear in a JWT at all; a PDF instance carries the same media type for every version so the binding cannot be inferred from the type alone. It also records conflicts when embedded evidence duplicates or contradicts itself, and the fallback paths that are forbidden because they would silently weaken the proof.", "source_refs": [ "SRC-007", "SRC-014", "SRC-008", "SRC-006", "SRC-033", "SRC-016", "SRC-004", "SRC-034", "SRC-038" ], "questions": [ { "id": "sig-proj-q-conversion-verdict", "text": "Is movement from the source binding to the target binding permitted, blocked, or permitted only under a recorded loss acceptance?", "kind": "decision", "answer_data": [ "Verdict code (permitted, conditional, blocked)", "Referenced loss report identifier", "Condition text and the role that may satisfy it" ] }, { "id": "sig-proj-q-roundtrip-block", "text": "Which specific structural or cryptographic facts make a byte-identical round trip impossible for this pair?", "kind": "constraint", "answer_data": [ "Blocking condition codes", "Specification citation for each condition", "Statement of whether re-signing rather than re-encoding would be required" ] }, { "id": "sig-proj-q-forbidden-fallback", "text": "Which fallback paths are explicitly forbidden because they would silently weaken or reinterpret the proof?", "kind": "security", "answer_data": [ "Forbidden fallback path descriptors", "Weakening mechanism described (dropped criticality, unprotected trust parameter, downgraded topology)", "Enforcement expectation delegated to the referenced runtime" ] }, { "id": "sig-proj-q-media-ambiguity", "text": "How is the concrete binding of an instance determined when its media type does not identify the serialization variant or profile?", "kind": "interoperability", "answer_data": [ "Disambiguation inputs (magic bytes, structural tag, internal type parameter, out-of-band profile reference)", "Ambiguity flag with residual risk note", "Required explicit profile declaration for the exchange" ] }, { "id": "sig-proj-q-evidence-conflict", "text": "When embedded evidence duplicates or contradicts itself, which item governs and how is the conflict captured?", "kind": "validation", "answer_data": [ "Conflict type (duplicate timestamp, differing certificate copy, contradictory revocation data, repeated parameter)", "Governing item selection rule declared by the profile", "Conflict record with the identifier of the external component that reported it" ] } ], "data_elements": [ { "id": "sig-proj-conversion-verdict", "name": "Conversion verdict", "description": "Recorded verdict for a proposed movement between two bindings.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-007" ] }, { "id": "sig-proj-blocking-condition-code", "name": "Blocking condition code", "description": "Coded reason why a byte-identical or semantically faithful conversion is impossible for the pair.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "sig-proj-media-type-ambiguity-flag", "name": "Media type ambiguity flag", "description": "Whether the instance's media type is insufficient to determine its serialization variant or profile.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-033", "SRC-034" ] }, { "id": "sig-proj-evidence-conflict-record", "name": "Embedded evidence conflict record", "description": "Record of duplicated or contradictory evidence found in an instance, with the governing-item rule applied and the reporting component.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-036" ] }, { "id": "sig-proj-forbidden-fallback-path", "name": "Forbidden fallback path", "description": "Descriptor of a conversion or degradation path that must never be taken automatically.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-007" ] } ], "artifacts": [ { "id": "sig-proj-conformance-report", "name": "Binding conformance report", "description": "Issued report aggregating externally produced encoder, parser and validator results for a profile or an instance class, together with the conversion verdict, blocking conditions, ambiguity flags and evidence conflicts. It records results by reference with their producing component and its own provenance; it neither executes nor re-runs validation, and it asserts alignment findings rather than a claim of conformance.", "media_or_form": [ "Structured conformance record set with external result references", "Human-readable conformance summary rendering", "Verdict and blocking-condition enumeration" ], "serial": true, "identity_strategy": "Master-system report identifier from the issuing conformance system where one exists; otherwise a governed IRI under the owner namespace bound to the profile identifier plus a monotonic sequence; otherwise a Dimension-assigned ULID. Never a date and never a digest.", "source_refs": [ "SRC-016", "SRC-007", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "sig-proj-version-distinction", "name": "Binding profile version, logical proof version and host artifact version", "description": "Keeps three independent version axes apart. The binding profile version tracks the projection profile and the specification edition it was authored against, such as an ETSI deliverable version or a W3C cryptosuite token that may embed a year but is treated as an opaque governed string. The logical proof version tracks the model-level description of the proof itself. The host artifact version tracks the containing document, which for PDF is signalled only by the file header because the media type is identical for every version. Confusing the axes produces false compatibility claims.", "source_refs": [ "SRC-033", "SRC-004", "SRC-036", "SRC-037", "SRC-038", "SRC-040", "SRC-041" ], "questions": [ { "id": "sig-proj-q-version-axes", "text": "Which three version values apply to this record, and where is each of them recorded?", "kind": "identity", "answer_data": [ "Binding profile version value and location", "Logical proof version value and location", "Host artifact version value and location" ] }, { "id": "sig-proj-q-version-effect", "text": "What changes when only the binding profile version advances while the logical proof content is unchanged?", "kind": "state", "answer_data": [ "Affected fields and templates", "Whether existing instances remain readable under the new profile version", "Recorded compatibility verdict for the version step" ] }, { "id": "sig-proj-q-version-resign", "text": "Which version changes require producing a new proof rather than re-encoding the existing one?", "kind": "lifecycle", "answer_data": [ "Change classes that alter the signing input", "Change classes confined to unprotected containers", "Referenced runtime obligation for producing the new proof" ] }, { "id": "sig-proj-q-version-provenance", "text": "Which specification edition and which registry snapshot were in force when this binding was produced?", "kind": "provenance", "answer_data": [ "Specification identifier and edition or version", "Registry snapshot reference with its own retrieval time", "Verification status where the clause text is paywalled or was not retrievable" ] } ], "data_elements": [ { "id": "sig-proj-profile-version", "name": "Binding profile version", "description": "Version of the projection profile and template set in force for this record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-036", "SRC-037", "SRC-040" ] }, { "id": "sig-proj-logical-proof-version", "name": "Logical proof version", "description": "Version of the model-level proof description, independent of any binding or host.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-proj-host-artifact-version", "name": "Host artifact version", "description": "Version of the containing artifact as declared by the host model, recorded here only as a reference value.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-033", "SRC-041" ] }, { "id": "sig-proj-registry-snapshot-ref", "name": "Registry snapshot reference", "description": "Reference to the registry state used for parameter and algorithm identifiers, with the time that state was observed.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-038", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The three version values are coordinates on records owned elsewhere: the profile version belongs to the projection template artifact, the host version belongs to the host artifact model, and the logical version belongs to the proof record. Holding them inline as reference values keeps a single authoritative source for each while still making the distinction explicit and queryable." } ] } ] }, { "id": "sig-chain-trust-path-bundle", "name": "Trust-path and verification-method context", "description": "Everything needed to state which verification method a signature depends on, how that method is reached from a trust anchor, and under which anchor-level and path-level constraints that reachability was recorded.", "rationale": "Path building and path validation are distinct concerns (SRC-045), and both are meaningless without a pinned anchor and anchor-carried controls (SRC-046). Non-X.509 verification methods reach the same question through a different binding (SRC-050), so the binding form must be modelled before the chain. Grouping these three concerns keeps the reachability question separate from the status question, which changes on a different clock.", "source_refs": [ "SRC-043", "SRC-045", "SRC-046", "SRC-050" ], "layers": [ { "id": "sig-chain-method-binding-layer", "name": "Verification-method reference and declared purpose", "description": "How the signature record points at the material used to verify it, in each supported binding form, and what that material declares about the purposes it may be used for.", "source_refs": [ "SRC-043", "SRC-050", "SRC-051" ], "findings": [ { "id": "sig-chain-method-reference-finding", "name": "Verification-method reference and resolution inputs", "description": "The reference that identifies the verification key material for a signature — a raw public key, an X.509 end-entity certificate, a verifiable credential, or a DID URL — together with the resolution inputs supplied and the resolution metadata and version reference returned. The external record itself is owned and operated by its issuer, controller or DID method; this finding captures the pointer and what was observed when it was retrieved.", "source_refs": [ "SRC-043", "SRC-050", "SRC-051" ], "questions": [ { "id": "sig-chain-q-method-identity", "text": "Which identifier resolves the verification method used for this signature, and in which identifier space is that identifier authoritative?", "kind": "identity", "answer_data": [ "Verification-method identifier, DID URL, or issuer name plus certificate serial number", "Identifier space or namespace authority", "Controller or issuer identifier" ] }, { "id": "sig-chain-q-method-binding-form", "text": "Which binding form carries the verification key: bare public key, X.509 certificate, verifiable credential, or DID document entry?", "kind": "classification", "answer_data": [ "Binding form code", "Key material encoding such as SubjectPublicKeyInfo, publicKeyJwk or publicKeyMultibase", "Media type of the retrieved representation" ] }, { "id": "sig-chain-q-method-resolution", "text": "What resolution inputs were supplied and what resolution metadata was returned when the verification method was retrieved?", "kind": "provenance", "answer_data": [ "Resolution options supplied, such as accept, versionId or versionTime", "Resolution metadata returned, including contentType and any error code", "Retrieval endpoint and retrieval observation time" ] }, { "id": "sig-chain-q-method-version", "text": "Which version of the verification-method record was in effect, and how would a later version be distinguished from the one actually used?", "kind": "temporal", "answer_data": [ "Document versionId and nextVersionId, or certificate validity interval", "Created and updated timestamps of the external record", "Deactivated or superseded flag as reported by the source" ] } ], "data_elements": [ { "id": "sig-chain-de-verification-method-ref", "name": "Verification method reference", "description": "Authoritative pointer to the verification key material relied on by this signature.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-043", "SRC-050" ] }, { "id": "sig-chain-de-binding-form", "name": "Binding form code", "description": "Which form of verification-method binding applies: raw key, X.509 certificate, credential or DID document entry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-043", "SRC-050" ] }, { "id": "sig-chain-de-key-material-encoding", "name": "Key material encoding", "description": "Encoding of the public key as retrieved, for example SubjectPublicKeyInfo, publicKeyJwk or publicKeyMultibase.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-050" ] }, { "id": "sig-chain-de-resolution-metadata", "name": "Resolution metadata capture", "description": "Options supplied to and metadata returned by the external resolution step, captured verbatim.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-051" ] }, { "id": "sig-chain-de-method-version-ref", "name": "Verification method version reference", "description": "Version identifier or validity interval that pins which state of the external record was used.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-050", "SRC-051" ] } ], "artifacts": [], "inline_only_rationale": "The verification-method record is created, versioned and published by an external certificate authority, credential issuer or DID method, and copying it here would duplicate a record whose lifecycle this model does not own. What this finding contributes is purely reference and observation data: the pointer, the binding form, the options supplied to resolution, the metadata returned and the version pinned. Where certificate bytes are actually retained, they are retained as part of the certification path certificate set in the path layer, not duplicated here." }, { "id": "sig-chain-method-constraint-finding", "name": "Declared purpose and usage constraints of the verification method", "description": "What the verification method itself declares about the operations it may be used for, and what relying-party behaviour it demands — key usage bits, extended key usage purposes, DID verification relationships, and certificate-declared mandatory relying-party features. Whether a mismatch is tolerated is a policy decision made elsewhere; this finding records the declaration and the observed mismatch.", "source_refs": [ "SRC-043", "SRC-049", "SRC-050" ], "questions": [ { "id": "sig-chain-q-method-purpose", "text": "For which purposes was this verification method authorized, and where is each authorization declared?", "kind": "authority", "answer_data": [ "keyUsage bits asserted", "extendedKeyUsage purpose identifiers", "DID verification relationships such as authentication or assertionMethod" ] }, { "id": "sig-chain-q-method-purpose-mismatch", "text": "What is recorded when the declared purpose does not cover the operation this signature was actually used for?", "kind": "exception", "answer_data": [ "Purpose mismatch flag", "Declared purpose set", "Purpose the signature was relied on for" ] }, { "id": "sig-chain-q-method-feature-demand", "text": "Does the verification method assert a mandatory relying-party feature such as stapled status evidence?", "kind": "requirement", "answer_data": [ "Declared mandatory feature identifiers", "Criticality of the declaring extension", "Whether the feature was satisfied in the observed exchange" ] }, { "id": "sig-chain-q-method-controller", "text": "Which controller or issuer asserts control over this verification method, and how is that assertion evidenced?", "kind": "ownership", "answer_data": [ "Controller or issuer identifier", "Control assertion location, such as the controller property or issuer distinguished name", "Reference to the evidence supporting the control assertion" ] } ], "data_elements": [ { "id": "sig-chain-de-key-usage-set", "name": "Key usage set", "description": "Key usage bits asserted by the verification method for this signature.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-chain-de-extended-key-usage-set", "name": "Extended key usage set", "description": "Extended key usage purpose identifiers asserted by the verification method.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-044" ] }, { "id": "sig-chain-de-verification-relationship", "name": "Verification relationship", "description": "Declared relationship such as authentication, assertionMethod, keyAgreement, capabilityInvocation or capabilityDelegation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-050" ] }, { "id": "sig-chain-de-mandatory-relying-party-feature", "name": "Mandatory relying-party feature", "description": "Feature the certificate demands of a relying party, such as required stapled status evidence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-049" ] }, { "id": "sig-chain-de-controller-ref", "name": "Controller reference", "description": "Reference to the controller or issuer asserting control over the verification method.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-050", "SRC-043" ] } ], "artifacts": [], "inline_only_rationale": "These are declarations already carried inside an external certificate, credential or DID document; extracting them into a separate artifact would create a second, divergable copy of bytes this model does not own. They are recorded as normalized inline fields alongside a pointer to the declaring extension or property, so a reader can re-derive them from the captured path certificate set when needed." } ] }, { "id": "sig-chain-path-anchor-layer", "name": "Certification path, constraints and trust-anchor context", "description": "The candidate paths considered, the path actually selected and by which builder, the constraint inputs and recorded per-path outcomes, and the trust anchor and trust-store snapshot that terminated the path.", "source_refs": [ "SRC-043", "SRC-045", "SRC-046", "SRC-053" ], "findings": [ { "id": "sig-chain-path-candidate-finding", "name": "Candidate certification paths, retrieval provenance and selection", "description": "The set of candidate paths assembled toward a trust anchor, where each intermediate certificate came from, which candidate was selected, and by which external path builder on what recorded ordering criteria. Path building is a search that may yield several defensible answers in mesh and bridge architectures, so the alternatives and the selection basis are context in their own right.", "source_refs": [ "SRC-043", "SRC-045" ], "questions": [ { "id": "sig-chain-q-path-candidates", "text": "Which candidate certification paths were assembled for this signature, and how is each candidate identified?", "kind": "composition", "answer_data": [ "Candidate path identifier", "Ordered certificate references forming the candidate", "Candidate path length" ] }, { "id": "sig-chain-q-path-retrieval", "text": "From which store, extension or protocol message was each intermediate certificate obtained?", "kind": "provenance", "answer_data": [ "Retrieval source such as authority information access, subject information access, directory, local cache or embedded certificate bag", "Retrieval endpoint or container reference", "Retrieval observation time" ] }, { "id": "sig-chain-q-path-selection", "text": "Which candidate path was selected, by which builder, and on what recorded ordering or elimination criteria?", "kind": "decision", "answer_data": [ "Selected candidate identifier", "Path builder identity and version", "Recorded sorting and elimination criteria applied" ] }, { "id": "sig-chain-q-path-loop-control", "text": "How were repeated subject-name and public-key pairs detected and excluded from candidate paths?", "kind": "constraint", "answer_data": [ "Loop-control rule applied", "Excluded candidate references", "Basis on which repetition was detected" ] } ], "data_elements": [ { "id": "sig-chain-de-candidate-path-id", "name": "Candidate path identifier", "description": "Local identifier for one assembled candidate certification path.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-045" ] }, { "id": "sig-chain-de-path-certificate-ref", "name": "Path certificate reference", "description": "Ordered reference to a certificate in a candidate path, by issuer name and serial number.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-043" ] }, { "id": "sig-chain-de-path-retrieval-source", "name": "Path certificate retrieval source", "description": "Where a path certificate was obtained from, including the extension or store used.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-045" ] }, { "id": "sig-chain-de-selected-path-ref", "name": "Selected path reference", "description": "Reference to the candidate path selected for the recorded determination.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-045" ] }, { "id": "sig-chain-de-path-builder-identity", "name": "Path builder identity", "description": "Identity and version of the external component that assembled and ordered the candidates.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-045" ] } ], "artifacts": [ { "id": "sig-chain-art-path-certificate-set", "name": "Certification path certificate set", "description": "The captured, byte-preserving set of certificates forming the candidate and selected paths, retained so the path can be re-presented to a validator without re-contacting directories or authority information access endpoints.", "media_or_form": [ "DER-encoded X.509 certificate sequence", "PEM-encoded certificate chain", "CMS SignedData certificates set", "Certificate bag embedded in the signed data object", "JSON Web Key set or credential collection for non-X.509 bindings" ], "serial": false, "identity_strategy": "Each contained certificate is identified by the authoritative master-system identifier assigned by its issuing certification authority — issuer name plus certificate serial number. The captured set as a whole is identified by a digest over the concatenated DER bytes in path order, with a Dimension-assigned ULID used only as a local handle. No issue date or validity bound is used as an identifier.", "source_refs": [ "SRC-043", "SRC-045" ] } ], "inline_only_rationale": null }, { "id": "sig-chain-path-constraint-finding", "name": "Path validation inputs and recorded constraint outcomes", "description": "The initial inputs supplied to path validation and the per-certificate and per-path constraint outcomes recorded afterwards: basic constraints and path length, name constraints against tested name forms, certificate policies and policy mappings, and unrecognized critical extensions. The algorithm is executed by an external validator; this finding records what was fed in and what came back so the determination is reproducible.", "source_refs": [ "SRC-043", "SRC-046" ], "questions": [ { "id": "sig-chain-q-constraint-inputs", "text": "Which initial path-validation inputs were supplied for this determination?", "kind": "requirement", "answer_data": [ "Initial policy set", "Initial explicit-policy, policy-mapping-inhibit and any-policy-inhibit flags", "Initial permitted subtrees and initial excluded subtrees" ] }, { "id": "sig-chain-q-constraint-basic", "text": "What basic-constraints and path-length outcome was recorded for each certification authority certificate in the selected path?", "kind": "constraint", "answer_data": [ "Certification authority boolean per certificate", "Path length constraint value per certificate", "Recorded outcome per certificate position" ] }, { "id": "sig-chain-q-constraint-names", "text": "Which name constraints applied, and which subject and alternative name forms were tested against them?", "kind": "relationship", "answer_data": [ "Permitted subtrees in force at each position", "Excluded subtrees in force at each position", "Name forms tested and the per-name result" ] }, { "id": "sig-chain-q-constraint-policy", "text": "Which certificate policies and policy mappings survived to the end of the selected path?", "kind": "classification", "answer_data": [ "Authorities-constrained or user-constrained policy set at path end", "Policy mapping records applied along the path", "Explicit-policy state at path end" ] }, { "id": "sig-chain-q-constraint-critical-unknown", "text": "How is an unrecognized critical extension encountered in the path recorded?", "kind": "exception", "answer_data": [ "Extension object identifier", "Criticality flag as encoded", "Recorded handling outcome reported by the validator" ] } ], "data_elements": [ { "id": "sig-chain-de-initial-policy-set", "name": "Initial policy set", "description": "Set of certificate policy identifiers acceptable to the relying party for this determination.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-046" ] }, { "id": "sig-chain-de-path-control-flags", "name": "Path control flags", "description": "Initial inhibit and require flags supplied for policy processing.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-046" ] }, { "id": "sig-chain-de-name-constraint-outcome", "name": "Name constraint outcome", "description": "Per-name-form result of testing subject and alternative names against permitted and excluded subtrees.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-chain-de-path-len-outcome", "name": "Path length outcome", "description": "Remaining permitted intermediate count recorded at a certificate position in the selected path.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-chain-de-unrecognized-critical-extension", "name": "Unrecognized critical extension", "description": "Object identifier of a critical extension the validator did not recognize, with its recorded handling.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-043" ] } ], "artifacts": [], "inline_only_rationale": "Constraint inputs and outcomes are structured scalar and set-valued fields, not documents. They must be stored inline so that a later replay can re-supply exactly the same inputs to a validator and compare against exactly the same recorded outcomes; encapsulating them in an artifact would obscure field-level comparison. The extension bytes they derive from are already retained inside the certification path certificate set artifact, so no second copy is warranted." }, { "id": "sig-chain-trust-anchor-finding", "name": "Trust anchor identity, anchor-carried controls and trust-store snapshot", "description": "The trust anchor that terminated the selected path, the path controls the anchor itself imposes below it, the trust store or trust list snapshot that made the anchor trusted at the recorded instant, and the service status the governing list reported for it. Operation of the store or list — admission, supervision, status determination — belongs to its scheme operator.", "source_refs": [ "SRC-046", "SRC-013", "SRC-053" ], "questions": [ { "id": "sig-chain-q-anchor-identity", "text": "Which trust anchor terminated the selected path, and by which name and key identifier is it recorded?", "kind": "identity", "answer_data": [ "Trust anchor name", "Public key identifier of the anchor", "Reference to the anchor certificate or trust anchor information object if one exists" ] }, { "id": "sig-chain-q-anchor-controls", "text": "Which path controls does the trust anchor itself impose on certification paths beneath it?", "kind": "constraint", "answer_data": [ "Anchor policy set", "Anchor policy flags for inhibit policy mapping, require explicit policy and inhibit any policy", "Anchor name constraints and path length constraint" ] }, { "id": "sig-chain-q-trust-store-snapshot", "text": "Which trust store or trust list snapshot was in force, and how is that snapshot pinned so it can be reproduced?", "kind": "provenance", "answer_data": [ "Trust store or trust list identifier and location", "Sequence number, version identifier and issue date-time of the snapshot", "Digest over the retrieved snapshot bytes" ] }, { "id": "sig-chain-q-anchor-service-status", "text": "What status did the governing trust list report for the anchor's trust service at the recorded instant?", "kind": "state", "answer_data": [ "Service status identifier as published", "Current status starting date and time", "Service type identifier and scheme territory" ] } ], "data_elements": [ { "id": "sig-chain-de-trust-anchor-name", "name": "Trust anchor name", "description": "Distinguished name or equivalent name of the trust anchor terminating the selected path.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-046" ] }, { "id": "sig-chain-de-trust-anchor-key-id", "name": "Trust anchor key identifier", "description": "Public key identifier of the trust anchor, used to distinguish re-keyed anchors sharing a name.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-046" ] }, { "id": "sig-chain-de-anchor-path-controls", "name": "Anchor path controls", "description": "Policy set, policy flags, name constraints and path length constraint carried by the anchor itself.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-046" ] }, { "id": "sig-chain-de-trust-store-snapshot-ref", "name": "Trust store snapshot reference", "description": "Pinned reference to the trust store or trust list issue in force, by location, sequence number and digest.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-053", "SRC-013" ] }, { "id": "sig-chain-de-trust-service-status", "name": "Observed trust service status", "description": "Status the governing trust list published for the anchor's service, with its status starting date and time.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-053" ] } ], "artifacts": [], "inline_only_rationale": "Trust anchor sets and trust lists are published, sequence-numbered artifacts operated by scheme operators and root programmes that this model explicitly does not own; retaining a local copy as an owned artifact would imply custody of a list whose issuance and status determination happen elsewhere. The defensible contribution is a pin: location, sequence number, issue date-time, digest and the status observed, all of which are reference and scalar values. A consumer that needs the bytes fetches the pinned issue from its operator and verifies the recorded digest." } ] } ] }, { "id": "sig-chain-status-bundle", "name": "Revocation-status evidence and temporal determinacy", "description": "Everything needed to state what the authoritative status source said about the verification method, how trustworthy and fresh that statement is, against which instant the whole record is framed, and whether the evidence is complete enough to be determinate at all.", "rationale": "Status evidence has its own issuance clock, its own signer and its own authorization chain, all independent of the certification path (SRC-044, SRC-048). Correctness at the current instant, at best-signature time and on later historical replay are three different questions over the same evidence (SRC-013), and absent evidence can be normatively correct rather than a gap (SRC-047). Separating this bundle from the path bundle prevents collapsing 'evidence missing' into 'signature invalid'.", "source_refs": [ "SRC-043", "SRC-044", "SRC-047", "SRC-048", "SRC-052", "SRC-013" ], "layers": [ { "id": "sig-chain-status-evidence-layer", "name": "Status mechanism, evidence record and its authorization", "description": "Which status mechanism governs the verification method, what the captured evidence says and about what scope, who was authorized to sign it, and how it was bound to this request and delivered.", "source_refs": [ "SRC-043", "SRC-044", "SRC-047", "SRC-048", "SRC-049", "SRC-052" ], "findings": [ { "id": "sig-chain-status-evidence-finding", "name": "Status mechanism and captured status determination", "description": "The mechanism that governs status for this verification method, the status value reported with its reason and effective date, whether that status is reversible, and the scope the evidence claims to cover. Mechanism-specific vocabularies are kept distinct rather than normalized, because suspension, hold and supersession do not map cleanly across certificate revocation lists, online status responses and credential status lists.", "source_refs": [ "SRC-043", "SRC-044", "SRC-047", "SRC-052" ], "questions": [ { "id": "sig-chain-q-status-mechanism", "text": "Which status mechanism governs this verification method, and what does the certificate or credential itself declare about it?", "kind": "classification", "answer_data": [ "Mechanism code covering certificate revocation list, delta list, online status protocol, credential status list, or declared-unavailable", "Declared distribution point and responder location identifiers", "Presence of a no-revocation-available or responder-no-check declaration" ] }, { "id": "sig-chain-q-status-value", "text": "What status value was reported for the subject, with which reason code and effective date?", "kind": "state", "answer_data": [ "Status value in the mechanism's own vocabulary, including the unknown case", "Reason code as published by the source", "Effective date of the status, distinct from when the evidence was issued" ] }, { "id": "sig-chain-q-status-reversibility", "text": "Is the reported status reversible, and how are suspension and supersession distinguished from permanent revocation?", "kind": "lifecycle", "answer_data": [ "Reversibility indicator and status purpose such as revocation, suspension, message or refresh", "Hold and release-from-hold indications where the mechanism supports them", "Superseded indication with a reference to the successor verification method" ] }, { "id": "sig-chain-q-status-scope", "text": "What scope does this status evidence claim to cover, and does the subject demonstrably fall inside it?", "kind": "composition", "answer_data": [ "Scope descriptor such as issuing distribution point, indirect-issuer indication or delta-list base reference", "Subject match fields such as issuer name hash, issuer key hash and serial number, or status list index and list credential reference", "In-scope determination with its basis" ] } ], "data_elements": [ { "id": "sig-chain-de-status-mechanism", "name": "Status mechanism code", "description": "Which status mechanism produced or is declared to govern this determination.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-043", "SRC-044", "SRC-047", "SRC-052" ] }, { "id": "sig-chain-de-status-value", "name": "Reported status value", "description": "Status value in the reporting mechanism's own vocabulary, retained without cross-mechanism normalization.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-044", "SRC-052" ] }, { "id": "sig-chain-de-status-reason-code", "name": "Status reason code", "description": "Reason published with the status, such as key compromise, superseded, cessation of operation or hold.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-054" ] }, { "id": "sig-chain-de-status-effective-time", "name": "Status effective time", "description": "Time from which the reported status applies, as published by the authoritative source.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-044" ] }, { "id": "sig-chain-de-status-scope-descriptor", "name": "Status evidence scope descriptor", "description": "Fields describing what population the evidence covers and how the subject was matched into it.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043", "SRC-044", "SRC-052" ] } ], "artifacts": [ { "id": "sig-chain-art-status-evidence-object", "name": "Captured revocation status evidence object", "description": "The byte-preserving capture of the signed status statement relied on — a certificate revocation list, a delta list, a signed online status response, or a status list credential — retained so the determination can be re-verified without re-contacting the issuing source.", "media_or_form": [ "DER-encoded certificate list, full or delta", "DER-encoded signed online certificate status response", "Bitstring status list credential document", "Revocation-values container embedded in a signed data object" ], "serial": true, "identity_strategy": "Identified first by the authoritative master-system identifier assigned by the issuing source: certificate revocation list issuer plus certificate revocation list number, or responder key identifier plus the certificate identifier and production time for an online response. Where the mechanism assigns no series number, the governed global identifier is used — the status list credential reference plus index. A Dimension-assigned ULID plus a digest over the exact retrieved bytes is the last resort. Issue dates, this-update and next-update values are never used as identifiers.", "source_refs": [ "SRC-043", "SRC-044", "SRC-052" ] } ], "inline_only_rationale": null }, { "id": "sig-chain-status-authorization-finding", "name": "Status-evidence authorization, replay binding and delivery", "description": "Who signed the captured status evidence, on what basis that signer was authorized to speak for the subject, how the recursion into the signer's own status was stopped, what binds the evidence to this request rather than to a replayed earlier one, and through which channel and cache it arrived. The signer's certificate and the responder service are operated externally; this finding records the authorization basis reported and the binding fields observed.", "source_refs": [ "SRC-044", "SRC-045", "SRC-047", "SRC-048", "SRC-049" ], "questions": [ { "id": "sig-chain-q-status-signer-authorization", "text": "Who signed the captured status evidence, and on what basis was that signer authorized to speak for this subject?", "kind": "authority", "answer_data": [ "Status signer identifier and key identifier", "Delegation basis, such as signing by the same key as the issuing authority, a delegated signing purpose identifier, or a trust list entry", "Reference to the separately built certification path for the status signer" ] }, { "id": "sig-chain-q-status-signer-recursion", "text": "How was the status signer's own revocation position handled without recursing without bound?", "kind": "exception", "answer_data": [ "Presence of a responder-no-check declaration or a no-revocation-available declaration", "Reference to status evidence for the signer, or an explicit recorded omission", "Recursion-stop rule that was applied and who declared it" ] }, { "id": "sig-chain-q-status-replay-binding", "text": "What binds this status evidence to this particular request rather than to an earlier response replayed at us?", "kind": "security", "answer_data": [ "Nonce present, omitted or ignored, with the match result where present", "Production time and any request correlation identifier", "Whether the profile in use permits nonce omission, and which profile version" ] }, { "id": "sig-chain-q-status-delivery", "text": "Through which channel and cache did the evidence arrive: stapled in protocol, fetched directly, embedded in the signed data object, or served from cache?", "kind": "interoperability", "answer_data": [ "Delivery channel code", "Cache origin, cache directives observed and cache age at use", "Request method and endpoint where a fetch occurred" ] } ], "data_elements": [ { "id": "sig-chain-de-status-signer-ref", "name": "Status signer reference", "description": "Reference to the entity whose key signed the captured status evidence.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-044" ] }, { "id": "sig-chain-de-delegation-basis", "name": "Status signer delegation basis", "description": "Recorded basis on which the status signer was accepted as authorized for the subject.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-044", "SRC-045" ] }, { "id": "sig-chain-de-nonce-state", "name": "Nonce binding state", "description": "Whether a nonce was sent, returned, matched, omitted or deliberately ignored under the profile in use.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-044", "SRC-048" ] }, { "id": "sig-chain-de-delivery-channel", "name": "Evidence delivery channel", "description": "How the status evidence reached the relying party, including whether it was stapled or served from cache.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-048", "SRC-049" ] }, { "id": "sig-chain-de-evidence-digest", "name": "Evidence digest", "description": "Digest and digest algorithm over the exact retrieved status evidence bytes.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-044", "SRC-048" ] } ], "artifacts": [], "inline_only_rationale": "The status signer's certificate, its own certification path and the responder service are external records operated by a certification authority or responder operator, and the transport that delivered the evidence is a protocol exchange this model does not own. What remains is a set of scalar and reference fields — signer pointer, delegation basis, nonce state, channel, cache age, digest — which must sit inline next to the evidence object they qualify. The evidence bytes themselves are already held by the captured status evidence object artifact in this same layer, so a second artifact would duplicate custody." } ] }, { "id": "sig-chain-temporal-determinacy-layer", "name": "Validation instants and evidence determinacy", "description": "The instant a trust-chain record is framed against, the proof of existence that supports a past instant, the separation of event time from observation time, and whether the assembled evidence is complete enough to be determinate.", "source_refs": [ "SRC-044", "SRC-047", "SRC-048", "SRC-013" ], "findings": [ { "id": "sig-chain-validation-instant-finding", "name": "Validation instant, proof of existence and observation time", "description": "Which instant this trust-chain record is framed against — the current time, the best-signature time established by a proof of existence, or a replayed historical instant — together with the proof that supports a past instant, the separation of when facts occurred from when they were observed, and the clock-skew tolerance assumed when comparing an instant to an evidence window. A signature made before revocation and proven to predate it is a different case from one made after, and the model must be able to state which case it is describing.", "source_refs": [ "SRC-044", "SRC-048", "SRC-013" ], "questions": [ { "id": "sig-chain-q-instant-kind", "text": "Against which instant is this trust-chain record framed: current time, best-signature time, or a replayed historical instant?", "kind": "temporal", "answer_data": [ "Instant kind code", "Instant value expressed with seconds and an explicit offset", "Reference to the rule or request that selected this instant" ] }, { "id": "sig-chain-q-instant-proof", "text": "What proof of existence establishes that the signature and its supporting evidence existed before the claimed instant?", "kind": "evidence", "answer_data": [ "Reference to the proof of existence, such as a time-stamp token, ledger entry or archival record", "Issuer identifier of the proof", "Description of what the proof demonstrably covers" ] }, { "id": "sig-chain-q-instant-observation", "text": "When was each path and status fact observed or ingested, as distinct from when the underlying event occurred?", "kind": "provenance", "answer_data": [ "Event time as published by the authoritative source", "Observation or ingestion time recorded by this model", "Identifier of the system that performed the observation" ] }, { "id": "sig-chain-q-instant-replay-retention", "text": "What must be retained so this instant can be re-evaluated later without contacting live services?", "kind": "retention", "answer_data": [ "Inventory of evidence required for replay", "Retention horizon reference and any archive-cutoff value reported by the source", "Replay-completeness flag for the declared instant" ] }, { "id": "sig-chain-q-instant-skew", "text": "What clock-skew tolerance and time source were assumed when comparing this instant against evidence validity windows?", "kind": "measurement", "answer_data": [ "Tolerance value and unit", "Time source reference used by the recording system", "Comparison rule applied to the this-update and next-update bounds" ] } ], "data_elements": [ { "id": "sig-chain-de-validation-instant-kind", "name": "Validation instant kind", "description": "Whether the record is framed at current time, at best-signature time, or at a replayed historical instant.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "sig-chain-de-validation-instant-value", "name": "Validation instant value", "description": "The instant itself, recorded with seconds and an explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-044" ] }, { "id": "sig-chain-de-proof-of-existence-ref", "name": "Proof of existence reference", "description": "Reference to the external proof that fixes the signature or evidence before the claimed instant.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-chain-de-observation-time", "name": "Observation time", "description": "Time at which this model captured the fact, held separately from the fact's own event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-044", "SRC-048" ] }, { "id": "sig-chain-de-clock-skew-tolerance", "name": "Clock skew tolerance", "description": "Tolerance applied when comparing an instant against evidence validity bounds.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-048" ] } ], "artifacts": [], "inline_only_rationale": "Instants, tolerances and observation times are scalar values, and the proof of existence they lean on is a token issued and governed by a separate time-stamping or preservation authority that this model references rather than owns. Storing these inline keeps the temporal frame directly comparable with the this-update and next-update bounds recorded on the evidence object, which is exactly the comparison a replay must repeat. The assembled replay container that packages them is declared separately under the determinacy finding." }, { "id": "sig-chain-determinacy-finding", "name": "Evidence completeness and determinacy classification", "description": "Whether the assembled trust-chain and status record is complete enough at the declared instant to be determinate, or whether it is evidence-incomplete — missing, stale, out of scope, or unreachable — as distinct from a cryptographic failure. Also carries, verbatim and attributed, any validation indication issued by an external validator, and the failure-handling stance declared by the consuming environment. The model classifies the completeness of its own record; it does not decide trust and does not enforce an outcome.", "source_refs": [ "SRC-044", "SRC-047", "SRC-048", "SRC-049", "SRC-013", "SRC-054" ], "questions": [ { "id": "sig-chain-q-determinacy-completeness", "text": "Which required trust-chain and status elements are present, stale or missing for the declared instant?", "kind": "quality", "answer_data": [ "Presence flag per required element", "Staleness measured against the evidence next-update bound", "Inventory of missing or unreachable elements with the reason recorded" ] }, { "id": "sig-chain-q-determinacy-class", "text": "Is this record determinate, or is it evidence-incomplete rather than cryptographically failed?", "kind": "validation", "answer_data": [ "Determinacy class covering determinate, evidence-incomplete and not-assessed", "Distinguishing reason, including whether absent status was declared unavailable by the issuer", "Cryptographic verification outcome carried as a separate field, never merged into the determinacy class" ] }, { "id": "sig-chain-q-determinacy-indication", "text": "Which externally issued validation indication and sub-indication are carried with this record, and who issued them?", "kind": "interoperability", "answer_data": [ "Indication value carried verbatim in the issuing vocabulary", "Sub-indication value carried verbatim", "Issuing validator identity, version and the validation policy reference it applied" ] }, { "id": "sig-chain-q-determinacy-stance", "text": "Which failure-handling stance for missing or stale status evidence did the consuming environment declare, and who declared it?", "kind": "decision", "answer_data": [ "Declared stance reference covering hard-fail, soft-fail, treat-as-unknown or skip-when-declared-unavailable", "Identifier of the authority or policy record that declared the stance", "Scope over which the declared stance applies" ] }, { "id": "sig-chain-q-determinacy-privacy", "text": "What does the recorded evidence reveal about the relying party's own query behaviour, and how is that limited?", "kind": "privacy", "answer_data": [ "Whether the status was obtained by direct query, stapling, cached list or embedded material", "Query-linkability indicator for the channel used", "Applied minimization or aggregation measure recorded with the capture" ] } ], "data_elements": [ { "id": "sig-chain-de-determinacy-class", "name": "Determinacy class", "description": "Whether the record is determinate, evidence-incomplete, or not assessed at the declared instant.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-047", "SRC-013" ] }, { "id": "sig-chain-de-missing-element-inventory", "name": "Missing element inventory", "description": "Enumeration of required elements that are absent, unreachable or out of scope, with the reason for each.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-044" ] }, { "id": "sig-chain-de-staleness-measure", "name": "Staleness measure", "description": "Interval by which the evidence exceeds its next-update bound relative to the declared instant.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-044", "SRC-048" ] }, { "id": "sig-chain-de-carried-indication", "name": "Carried validation indication", "description": "Top-level indication issued by an external validator, carried verbatim with its issuing vocabulary.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-chain-de-carried-sub-indication", "name": "Carried validation sub-indication", "description": "Sub-indication issued by an external validator, carried verbatim with its issuing vocabulary.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-chain-de-declared-failure-stance-ref", "name": "Declared failure-handling stance reference", "description": "Reference to the externally declared stance for missing or stale status evidence, with its declaring authority.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-049", "SRC-054" ] } ], "artifacts": [ { "id": "sig-chain-art-replay-package", "name": "Trust-chain evidence replay package", "description": "A self-contained container assembling the selected path, the trust-anchor and trust-store pin, every captured status evidence object, the declared instant and proof-of-existence references, and the determinacy record, so that an external validator can re-evaluate the same determination later without contacting live services.", "media_or_form": [ "Archival container bundling path certificates, status evidence and instant records", "Long-term validation material container embedded in a signed data object", "Detached evidence manifest listing member digests and their pinned references" ], "serial": true, "identity_strategy": "Identified by the authoritative master-system identifier of the signed subject the mixin is attached to, plus the package owner and a monotonic package sequence number assigned by the adopting Dimension. Where no master-system identifier exists for the subject, a governed global identifier for the signature instance is used, and a ULID plus manifest digest is the last resort. The declared validation instant is recorded inside the package but is never used as its identifier.", "source_refs": [ "SRC-044", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-verdict-algorithm-policy", "name": "Algorithm and parameter policy binding", "description": "The context that fixes exactly which cryptographic suite a signature or proof uses, what policy state that suite holds, and how the record behaves under agility, downgrade pressure and post-quantum transition.", "rationale": "Signature semantics are undecidable without a complete, unambiguous suite declaration and the policy under which it was judged. NIST fixes approved algorithms and transition status, IANA registries fix identifier scope and state values, and ETSI fixes the cryptographic-constraint and sunset model, so this concern is separable from the verification episode that consumes it.", "source_refs": [ "SRC-001", "SRC-056", "SRC-059", "SRC-038", "SRC-061", "SRC-063" ], "layers": [ { "id": "sig-verdict-suite-declaration-layer", "name": "Suite declaration and policy state", "description": "Identification of the signature and digest algorithms with their complete parameter sets, and the approval state, security strength and pinned policy under which those parameters were assessed.", "source_refs": [ "SRC-001", "SRC-055", "SRC-059", "SRC-063" ], "findings": [ { "id": "sig-verdict-suite-identification", "name": "Signature and digest suite identification with parameter completeness", "description": "Records the signature and digest algorithm identifiers together with the registry namespace they belong to and the full parameter set needed to reproduce verification: scheme and encoding or padding, curve or group, modulus or key size, digest function and output length, pre-hash mode and any context or domain-separation string. Absent, inherited or ambiguous parameters are recorded as an explicit completeness status rather than silently defaulted.", "source_refs": [ "SRC-001", "SRC-002", "SRC-059", "SRC-038", "SRC-063" ], "questions": [ { "id": "sig-verdict-q-suite-identifier", "text": "Which algorithm identifier, in which registry namespace, denotes the signature suite used, and what is its exact string or numeric value?", "kind": "identity", "answer_data": [ "algorithm identifier value", "registry namespace or OID arc", "identifier encoding form (name string, integer label, OID, IRI)" ] }, { "id": "sig-verdict-q-parameter-set", "text": "Which parameters does the declared suite require in order to be unambiguous, and is each one present on the record?", "kind": "composition", "answer_data": [ "required parameter list for the suite", "per-parameter present or absent flag", "parameter values", "overall completeness status" ] }, { "id": "sig-verdict-q-curve-keysize", "text": "Which curve, group or modulus size and which digest function and output length are bound to this signature?", "kind": "classification", "answer_data": [ "curve or group identifier", "modulus or key size in bits", "digest algorithm identifier", "digest output length in bits" ] }, { "id": "sig-verdict-q-absent-params", "text": "How are absent, inherited or ambiguous algorithm parameters recorded so that they are never silently defaulted?", "kind": "exception", "answer_data": [ "ambiguity reason code", "defaulting rule applied, or none", "resolution source reference" ] }, { "id": "sig-verdict-q-prehash-context", "text": "Is a pre-hash mode or context or domain-separation string in effect, and what is its value?", "kind": "constraint", "answer_data": [ "pre-hash mode flag", "context string value", "domain-separation label", "specification reference" ] } ], "data_elements": [ { "id": "sig-verdict-de-algorithm-id", "name": "Asserted algorithm identifier", "description": "The signature algorithm identifier exactly as carried by the signature container or proof.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-059", "SRC-038" ] }, { "id": "sig-verdict-de-registry-namespace", "name": "Identifier registry namespace", "description": "The registry or namespace that gives the identifier its meaning, so that a bare name such as ES256 is never ambiguous across registries.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-059", "SRC-038" ] }, { "id": "sig-verdict-de-parameter-set", "name": "Suite parameter set", "description": "Structured parameters that complete the suite: scheme variant, padding or encoding, salt length, pre-hash mode and context string.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-063" ] }, { "id": "sig-verdict-de-digest-algorithm", "name": "Digest algorithm and output length", "description": "Registry-scoped digest algorithm identifier with its output length, including any truncation applied.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-057" ] }, { "id": "sig-verdict-de-key-or-group-size", "name": "Key, curve or group size", "description": "Curve or group identifier and modulus or key size in bits for the verification key bound to the signature.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-055" ] }, { "id": "sig-verdict-de-parameter-completeness", "name": "Parameter completeness status", "description": "Coded status stating whether the suite declaration is complete, incomplete, inherited or ambiguous, with the reason code when it is not complete.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-063" ] } ], "artifacts": [], "inline_only_rationale": "Suite identification is a set of registry-governed identifiers and scalar parameters carried inline on the signature record. It has no standalone document form, and materialising it as a local artifact would fork the IANA, NIST and ETSI registry entries that this model only references and never maintains." }, { "id": "sig-verdict-strength-and-status", "name": "Security strength, approval state and pinned algorithm policy", "description": "Records the security strength the declared suite targets and the table that claim is made against, the approval state each governing authority assigns to it (approved, acceptable, deprecated, legacy-use, restricted, disallowed, or registry equivalents such as Recommended, No, Deprecated, Prohibited), any sunset or transition date, the time basis the sunset is evaluated against, and the exact policy snapshot pinned when the assessment was made. Disagreement between authorities is recorded, not resolved.", "source_refs": [ "SRC-055", "SRC-056", "SRC-057", "SRC-058", "SRC-059", "SRC-038", "SRC-061", "SRC-063" ], "questions": [ { "id": "sig-verdict-q-strength-target", "text": "What security strength in bits does the declared suite target, and against which strength table is that claim made?", "kind": "measurement", "answer_data": [ "security strength in bits", "strength table reference and version", "claimed versus independently assessed flag" ] }, { "id": "sig-verdict-q-approval-state", "text": "What approval state does each governing authority assign to this suite, and do those authorities disagree?", "kind": "authority", "answer_data": [ "approval state code per authority", "authority identifier and document version", "disagreement flag with note", "operation scope of the state (signature generation or verification)" ] }, { "id": "sig-verdict-q-sunset-date", "text": "What sunset, deprecation or disallowance date applies, and relative to which time basis is it evaluated?", "kind": "temporal", "answer_data": [ "sunset or deprecation date", "time basis code (validation time or proof-of-existence time)", "policy document version" ] }, { "id": "sig-verdict-q-policy-pin", "text": "Which exact policy snapshot version was pinned when this signature's algorithm state was assessed?", "kind": "provenance", "answer_data": [ "policy snapshot identifier", "policy version", "snapshot digest and digest algorithm", "pin timestamp" ] } ], "data_elements": [ { "id": "sig-verdict-de-security-strength", "name": "Target security strength", "description": "Security strength in bits attributed to the suite, with the reference table that supplies the mapping.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-055", "SRC-057" ] }, { "id": "sig-verdict-de-approval-state", "name": "Approval state per authority", "description": "Coded transition or recommendation state assigned by a named authority, scoped to the operation (generation or verification).", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-056", "SRC-059", "SRC-038" ] }, { "id": "sig-verdict-de-policy-authority", "name": "Policy authority reference", "description": "Reference to the authority and document version that asserts an approval state or sunset date.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-056", "SRC-063" ] }, { "id": "sig-verdict-de-sunset-date", "name": "Algorithm sunset date", "description": "Date after which the suite is deprecated or disallowed under a named policy; a bare date, never used as an identifier.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-verdict-de-policy-pin-ref", "name": "Pinned policy snapshot reference", "description": "Reference to the immutable policy snapshot in force for this assessment, with its version and digest.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-063" ] } ], "artifacts": [ { "id": "sig-verdict-art-policy-snapshot", "name": "Pinned algorithm policy snapshot", "description": "An immutable, versioned capture of the algorithm-state catalogue in force when a signature's suite was assessed: approval states, strength mappings and sunset dates, together with the precedence order among authorities. The catalogue is published and maintained externally; this model records the pinned edition, its version and its digest.", "media_or_form": [ "versioned policy catalogue record", "structured constraint set", "signed or digest-bound snapshot" ], "serial": true, "identity_strategy": "Authoritative policy identifier issued by the publishing authority together with its version; where the publisher assigns none, a governed namespace IRI; only otherwise a UUID or ULID minted by the adopting Dimension and recorded with its minting authority. The snapshot digest is stored as integrity metadata and the publication date is descriptive; neither is the identifier.", "source_refs": [ "SRC-056", "SRC-061", "SRC-063" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-verdict-agility-transition-layer", "name": "Agility, downgrade resistance and transition", "description": "The controls and recorded state that keep a signature record meaningful as algorithms are constrained, combined or retired: verifier-side accepted-algorithm sets, signing randomness profile, and hybrid, composite and post-quantum migration state.", "source_refs": [ "SRC-058", "SRC-027", "SRC-060", "SRC-064" ], "findings": [ { "id": "sig-verdict-downgrade-control", "name": "Accepted-algorithm set and downgrade resistance", "description": "Records the verifier-side accepted-algorithm set that governed a verification episode, where that set came from, whether the algorithm asserted in the signature container fell inside it, and the controls against algorithm confusion, reuse of one key across multiple algorithms, and acceptance of none or other non-signing algorithm values. The accepted set is a policy reference plus per-episode scalars; the deciding engine is external.", "source_refs": [ "SRC-038", "SRC-027", "SRC-061" ], "questions": [ { "id": "sig-verdict-q-accepted-set", "text": "Which accepted-algorithm set applied to this verification, and was it obtained from verifier policy or from the signature container?", "kind": "constraint", "answer_data": [ "accepted algorithm identifiers", "policy source code (verifier policy or container-asserted)", "policy set version and reference" ] }, { "id": "sig-verdict-q-asserted-vs-accepted", "text": "Did the algorithm asserted in the container fall inside the accepted set, and if not, which reason code is recorded?", "kind": "validation", "answer_data": [ "asserted algorithm identifier", "set membership result", "rejection reason code" ] }, { "id": "sig-verdict-q-key-alg-binding", "text": "Is the verification key bound to exactly one algorithm, and was that binding actually checked during the episode?", "kind": "security", "answer_data": [ "key-to-algorithm binding reference", "binding check performed flag", "binding mismatch reason code" ] }, { "id": "sig-verdict-q-none-and-unauth", "text": "How are unauthenticated, none or otherwise non-signing algorithm values handled and recorded?", "kind": "exception", "answer_data": [ "unauthenticated algorithm flag", "handling rule reference", "resulting outcome reason code" ] } ], "data_elements": [ { "id": "sig-verdict-de-accepted-algorithms", "name": "Accepted algorithm set", "description": "The identifiers a verifier was permitted to accept for this episode, recorded as a reference into the pinned policy snapshot plus any episode-local narrowing.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-027" ] }, { "id": "sig-verdict-de-asserted-algorithm", "name": "Container-asserted algorithm", "description": "The algorithm value carried by the signature container, held separately from the accepted set so that the two can be compared.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-038", "SRC-027" ] }, { "id": "sig-verdict-de-downgrade-flag", "name": "Downgrade or confusion indicator", "description": "Coded indicator recording a downgrade attempt, algorithm-confusion condition or unauthenticated algorithm value observed for this signature.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027" ] }, { "id": "sig-verdict-de-key-algorithm-binding", "name": "Key to algorithm binding reference", "description": "Reference to the declaration that binds the verification key to one and only one algorithm, held in the verification-method model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The accepted-algorithm set is recorded as a reference into the externally published policy snapshot plus a small number of per-episode coded values. Creating a separate local artifact would produce a second, competing copy of a policy that the adopting Dimension's configuration store already holds as the record of authority." }, { "id": "sig-verdict-signing-randomness-profile", "name": "Randomized, deterministic and hedged signing profile", "description": "Records whether the signature was produced with a randomized, deterministic or hedged per-message secret process, on what basis that claim rests, and the explicit limitation that deterministic and randomized signatures of the same suite are indistinguishable to a verifier holding only the signature value.", "source_refs": [ "SRC-001", "SRC-002", "SRC-060" ], "questions": [ { "id": "sig-verdict-q-randomness-mode", "text": "Which per-message randomness mode does the signer claim - randomized, deterministic or hedged - and for which suite?", "kind": "classification", "answer_data": [ "randomness mode code", "suite reference", "specification reference for the mode" ] }, { "id": "sig-verdict-q-randomness-evidence", "text": "What evidence supports the randomness-mode claim, given that a verifier cannot infer it from the signature value?", "kind": "evidence", "answer_data": [ "evidence type (device attestation, signer declaration, test vector, none)", "evidence reference", "verifier-observable flag" ] }, { "id": "sig-verdict-q-randomness-risk", "text": "What operational risk is recorded when the randomness mode is unknown or the signer's entropy source is unattested?", "kind": "quality", "answer_data": [ "risk note", "unknown-mode flag", "nonce-reuse concern flag" ] }, { "id": "sig-verdict-q-mode-interop", "text": "Does the recorded mode change the bytes a verifier must process or the identifier it must accept?", "kind": "interoperability", "answer_data": [ "identifier changes flag", "verification procedure changes flag", "profile compatibility note" ] } ], "data_elements": [ { "id": "sig-verdict-de-randomness-mode", "name": "Per-message randomness mode", "description": "Coded claim that signing used a randomized, deterministic or hedged per-message secret process.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-060" ] }, { "id": "sig-verdict-de-randomness-evidence-ref", "name": "Randomness-mode evidence reference", "description": "Reference to any external evidence supporting the mode claim, such as a device attestation or a signer declaration.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-060" ] }, { "id": "sig-verdict-de-mode-observability", "name": "Verifier observability flag", "description": "Boolean stating whether the mode is derivable by the verifier from the signature alone; false for the classical DSA and ECDSA families.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-060" ] } ], "artifacts": [], "inline_only_rationale": "The randomness profile is a small set of coded claims plus references to evidence held elsewhere. Materialising it as an artifact would suggest a verifier-side proof of the signer's nonce derivation that the deterministic-signature specification explicitly states does not exist, since such signatures remain indistinguishable from randomized ones." }, { "id": "sig-verdict-hybrid-composite-transition", "name": "Hybrid, composite and post-quantum transition state", "description": "Records multi-algorithm proofs - composite or parallel hybrid - their ordered component algorithms and parameter sets, the combination rule that governs the overall result, the security property the combination claims relative to its components, and the post-quantum migration state assigned by a named policy and jurisdiction. No universal transition deadline is asserted.", "source_refs": [ "SRC-002", "SRC-058", "SRC-064" ], "questions": [ { "id": "sig-verdict-q-composite-components", "text": "Which component algorithms make up this composite or hybrid proof, and under which composite identifier are they combined?", "kind": "composition", "answer_data": [ "composite algorithm identifier", "ordered component algorithm identifiers", "per-component parameter sets" ] }, { "id": "sig-verdict-q-combination-rule", "text": "What combination rule governs the overall result - must every component verify, or is a subset sufficient?", "kind": "constraint", "answer_data": [ "combination rule code", "specification reference", "per-component result slots" ] }, { "id": "sig-verdict-q-pq-migration-state", "text": "Which post-quantum migration state is recorded for this signature, and which named policy and jurisdiction assign it?", "kind": "state", "answer_data": [ "migration state code", "policy identifier and version", "jurisdiction or authority reference", "effective date under that policy" ] }, { "id": "sig-verdict-q-hybrid-security-claim", "text": "Which security property does the combination claim, and is that property weaker than the property of its strongest component?", "kind": "quality", "answer_data": [ "claimed security property (for example EUF-CMA or SUF-CMA)", "component property comparison note", "source reference for the claim" ] } ], "data_elements": [ { "id": "sig-verdict-de-composite-identifier", "name": "Composite or hybrid identifier", "description": "Registry-scoped identifier for the combined construction, distinct from the identifiers of its components.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-064" ] }, { "id": "sig-verdict-de-component-algorithms", "name": "Component algorithm list", "description": "Ordered list of component suites with their parameter sets and individual result slots.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-064" ] }, { "id": "sig-verdict-de-combination-rule", "name": "Combination rule", "description": "Coded rule stating how component results combine; the default for composite constructions is that every component must verify.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-064" ] }, { "id": "sig-verdict-de-pq-migration-state", "name": "Post-quantum migration state", "description": "Coded migration state relative to a named transition policy, always carried with the policy and jurisdiction reference.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-058" ] } ], "artifacts": [], "inline_only_rationale": "Composite structure, combination rule and migration state are coded values and ordered references over identifiers that other registries own. The component signature values themselves live in the signature container held by the host record, so there is nothing here that has an independent document form." } ] } ] }, { "id": "sig-verdict-verification-verdict", "name": "Verification context, verdicts and evidence", "description": "The context that makes a recorded verification outcome reproducible and honestly bounded: the inputs and time basis it consumed, the verifier and tooling that produced it, the structured outcome vocabulary it uses, and the separation of the distinct validity dimensions it reports.", "rationale": "Recording an outcome without its inputs, time basis, policy pin and producing tool makes the outcome unfalsifiable. ETSI supplies a normative three-valued indication with justifying sub-indications and a report structure, W3C supplies a proof-purpose and verification-result model, and CMS and TSP supply the claimed-time versus proof-of-existence distinction, so this concern is grounded and separable from the algorithm declaration it consumes.", "source_refs": [ "SRC-006", "SRC-009", "SRC-061", "SRC-062", "SRC-004", "SRC-013" ], "layers": [ { "id": "sig-verdict-verification-context-layer", "name": "Verification inputs and reproducibility pins", "description": "What a verification episode consumed and who produced it: covered content and canonicalisation, verification-method reference, validation time and time basis, claimed signing time against proof of existence, and the verifier, tool and evidence bindings that let a verdict be re-derived or challenged.", "source_refs": [ "SRC-006", "SRC-009", "SRC-061", "SRC-062" ], "findings": [ { "id": "sig-verdict-verification-inputs", "name": "Verification input set, validation time and time claims", "description": "Records the complete input set consumed by a verification episode: the covered byte sequence and the ordered canonicalisation or transform chain that produced it, the resolved verification-method reference, the validation time and the basis on which it was chosen, the validation material supplied versus fetched, and the claimed signing time held explicitly as an untrusted claim alongside any proof-of-existence reference that supports it.", "source_refs": [ "SRC-006", "SRC-009", "SRC-061", "SRC-004" ], "questions": [ { "id": "sig-verdict-q-bound-payload", "text": "Exactly which byte sequence was covered by the signature, and through which canonicalisation or transform chain was it derived?", "kind": "composition", "answer_data": [ "covered content reference", "ordered canonicalisation or transform identifiers", "covered-content digest with its digest algorithm" ] }, { "id": "sig-verdict-q-validation-time", "text": "Which validation time was used for this episode, and why was that time chosen rather than another?", "kind": "temporal", "answer_data": [ "validation time as RFC 3339 with offset", "time basis code (current time, claimed signing time, proof-of-existence time)", "selection rationale" ] }, { "id": "sig-verdict-q-claimed-signing-time", "text": "What signing time does the signature claim, and what external evidence, if any, supports that claim?", "kind": "provenance", "answer_data": [ "claimed signing time", "claim trust status code", "proof-of-existence evidence reference", "evidence issuer reference" ] }, { "id": "sig-verdict-q-supplied-material", "text": "Which validation material was supplied to the episode rather than fetched, and is it complete for the chosen validation time?", "kind": "evidence", "answer_data": [ "supplied material references", "acquisition mode per item", "completeness status with reason code" ] }, { "id": "sig-verdict-q-method-reference", "text": "Which verification method or key identifier was resolved for this episode, and in which reference form?", "kind": "identity", "answer_data": [ "verification method reference", "reference form (URI, key identifier, certificate reference)", "resolution status code" ] } ], "data_elements": [ { "id": "sig-verdict-de-covered-content-digest", "name": "Covered content digest", "description": "Digest over the exact byte sequence the signature covers, always stored with the naming of its digest algorithm.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "sig-verdict-de-canonicalisation-chain", "name": "Canonicalisation and transform chain", "description": "Ordered identifiers of the canonicalisation or transform steps applied before signing, preserved verbatim and never re-applied at storage time.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-verdict-de-validation-time", "name": "Validation time and basis", "description": "The time at which validation constraints were evaluated, with the coded basis on which that time was selected.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061" ] }, { "id": "sig-verdict-de-claimed-signing-time", "name": "Claimed signing time", "description": "The time the signer asserts the signature was created; an untrusted claim unless an external proof of existence supports it.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "sig-verdict-de-poe-reference", "name": "Proof-of-existence reference", "description": "Reference to a time-stamp token or equivalent evidence showing the signature existed before a stated time.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-061" ] }, { "id": "sig-verdict-de-verification-method-ref", "name": "Verification method reference", "description": "Reference to the verification method or key used, resolved in the model that owns it.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Every input here is a scalar or a reference into an object that a neighbouring model owns: the covered payload belongs to the host record, the verification method to the key model, and the time-stamp token to the proof-of-existence model. Copying any of them into a local artifact would create a second, drifting record of authority." }, { "id": "sig-verdict-reproducibility-pins", "name": "Verifier, tool and evidence pinning", "description": "Records who or what produced a verdict, with which software identity, version and configuration, at which observation or ingestion time as distinct from the validation time it was computed for, and which externally produced validation report the verdict is bound to and by which digest. It also records what must be held constant to re-derive the verdict and what is known to be non-reproducible.", "source_refs": [ "SRC-061", "SRC-062", "SRC-013" ], "questions": [ { "id": "sig-verdict-q-verifier-identity", "text": "Which verifying party, and which tool, library and version, produced this verdict?", "kind": "provenance", "answer_data": [ "verifying party identifier", "tool or library identifier", "version string", "build or configuration identifier" ] }, { "id": "sig-verdict-q-observation-time", "text": "When was the verdict observed and ingested, as distinct from the validation time it was computed for?", "kind": "temporal", "answer_data": [ "observation or ingestion timestamp", "reference to the validation time", "clock source note" ] }, { "id": "sig-verdict-q-evidence-binding", "text": "Which validation report or evidence object is this verdict bound to, and how is that binding integrity-protected?", "kind": "evidence", "answer_data": [ "evidence artifact reference", "evidence digest with digest algorithm", "binding method", "dereferenceability status" ] }, { "id": "sig-verdict-q-replay-conditions", "text": "What must be held constant to reproduce this verdict, and which factors are known to be non-reproducible?", "kind": "validation", "answer_data": [ "pinned input references", "non-reproducible factor list", "reproducibility status code" ] } ], "data_elements": [ { "id": "sig-verdict-de-verifier-ref", "name": "Verifying party reference", "description": "Reference to the party or service that produced the verdict; anonymous verdicts are not admissible.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-062" ] }, { "id": "sig-verdict-de-tool-version", "name": "Tool and version pin", "description": "Identifier, version and configuration of the software that computed the verdict.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-062", "SRC-013" ] }, { "id": "sig-verdict-de-observation-time", "name": "Observation or ingestion time", "description": "When the verdict was observed and stored by the adopting Dimension, held separately from validation time and claimed signing time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061" ] }, { "id": "sig-verdict-de-evidence-digest", "name": "Evidence digest", "description": "Digest binding the verdict to the referenced validation report or evidence object, stored with its digest algorithm.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-062" ] }, { "id": "sig-verdict-de-reproducibility-status", "name": "Reproducibility status", "description": "Coded statement of whether the verdict can be re-derived from the pinned inputs, and why not where it cannot.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-062" ] } ], "artifacts": [ { "id": "sig-verdict-art-validation-report", "name": "Referenced signature validation report", "description": "A structured report, produced by an external validation application, that enumerates each validation check and constraint, the status it produced, the justification for that status, and the validation objects used such as trust anchors, revocation data and time-stamps. This model records the reference, identity and digest of the report; it neither produces the report nor owns the producing system's audit trail.", "media_or_form": [ "structured validation report", "signed report object", "report reference bound by digest" ], "serial": true, "identity_strategy": "Report identifier assigned by the producing validation application as the authoritative master system; failing that, a governed IRI in the producer's namespace; only otherwise a UUID or ULID minted by the adopting Dimension with its minting authority recorded. The report digest is integrity metadata and the report date is descriptive; neither serves as the identifier.", "source_refs": [ "SRC-061", "SRC-062", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-verdict-verdict-semantics-layer", "name": "Structured verdicts and dimension separation", "description": "What a recorded outcome may say and what it may never imply: a closed outcome vocabulary with mandatory machine-readable reasons, and independent reporting of cryptographic validity, trust path, identity binding, authorization, proof purpose, qualification and legal effect.", "source_refs": [ "SRC-061", "SRC-062", "SRC-004", "SRC-013" ], "findings": [ { "id": "sig-verdict-outcome-taxonomy", "name": "Structured verification outcomes and machine-readable reasons", "description": "Defines the closed outcome vocabulary a recorded verdict may take - valid, invalid, indeterminate, unsupported, malformed, policy-rejected and evidence-incomplete - each carrying at least one machine-readable reason code when it is not valid, together with versioned mappings to external status vocabularies and explicit marking of where those mappings lose information.", "source_refs": [ "SRC-061", "SRC-062", "SRC-004", "SRC-013" ], "questions": [ { "id": "sig-verdict-q-outcome-value", "text": "Which outcome value does this verdict carry, and from which closed vocabulary version is it drawn?", "kind": "classification", "answer_data": [ "outcome code", "vocabulary identifier and version", "closed-vocabulary flag" ] }, { "id": "sig-verdict-q-reason-codes", "text": "Which machine-readable reason codes justify the outcome, and is at least one recorded for every non-valid result?", "kind": "requirement", "answer_data": [ "reason code list", "reason code vocabulary reference", "optional human-readable message" ] }, { "id": "sig-verdict-q-outcome-mapping", "text": "How does each local outcome map onto external status vocabularies, and where is that mapping lossy?", "kind": "interoperability", "answer_data": [ "external vocabulary identifier and version", "mapping target value", "lossiness marker with note" ] }, { "id": "sig-verdict-q-indeterminate-handling", "text": "What distinguishes indeterminate and evidence-incomplete from invalid, and what would resolve them?", "kind": "decision", "answer_data": [ "distinguishing criterion", "missing input or evidence list", "resolution action reference" ] }, { "id": "sig-verdict-q-unsupported-vs-malformed", "text": "How is an unsupported algorithm distinguished from a malformed structure in the recorded outcome?", "kind": "exception", "answer_data": [ "unsupported reason code", "malformed reason code", "parser or profile reference" ] } ], "data_elements": [ { "id": "sig-verdict-de-outcome-code", "name": "Outcome value", "description": "The single coded outcome of the recorded verdict, drawn from the closed vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-verdict-de-reason-codes", "name": "Reason codes", "description": "Machine-readable justifications for the outcome; at least one is required whenever the outcome is anything other than valid.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-062" ] }, { "id": "sig-verdict-de-outcome-message", "name": "Human-readable message", "description": "Optional narrative accompanying the codes; never a substitute for a reason code.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-062" ] }, { "id": "sig-verdict-de-external-mapping", "name": "External vocabulary mapping", "description": "Versioned mapping entries from local outcome and reason codes to external status indications and sub-indications, each marked lossless or lossy.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-004" ] } ], "artifacts": [ { "id": "sig-verdict-art-outcome-vocabulary", "name": "Verdict outcome and reason-code vocabulary", "description": "A governed, versioned code list defining the permitted outcome values, the reason codes available under each, and the versioned mappings from those codes to external status vocabularies with lossiness marked. It is the term set a verdict record cites; it does not decide any verdict.", "media_or_form": [ "controlled vocabulary", "code list with external mappings", "machine-readable term set" ], "serial": false, "identity_strategy": "Identifier issued by the maintaining authority where one exists; where the adopting Dimension maintains the vocabulary, a governed namespace IRI plus a semantic version; a UUID or ULID only as a last resort. Editions are disambiguated by version, never by release date.", "source_refs": [ "SRC-061", "SRC-062", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "sig-verdict-dimension-separation", "name": "Separation of validity dimensions in a verdict", "description": "Requires each verdict to report cryptographic primitive validity, trust-path outcome, identity binding, authorization, proof purpose, qualification and legal effect as independent dimensions, each with its own outcome, reason code and owning authority, and each explicitly marked not-assessed when it was not evaluated. A successful primitive check never sets any other dimension, and any single summary flag must declare the derivation rule and the information it discards.", "source_refs": [ "SRC-061", "SRC-004", "SRC-013" ], "questions": [ { "id": "sig-verdict-q-dimension-set", "text": "Which validity dimensions are reported for this verdict, and which are explicitly marked not assessed?", "kind": "composition", "answer_data": [ "dimension identifier list", "per-dimension outcome code", "not-assessed marker with reason" ] }, { "id": "sig-verdict-q-dimension-owner", "text": "Which model or authority owns the determination of each dimension, and is that determination referenced rather than recomputed here?", "kind": "ownership", "answer_data": [ "owning model or authority reference", "determination reference", "locally computed flag" ] }, { "id": "sig-verdict-q-purpose-match", "text": "For which declared proof purpose was the signature accepted, and does it match the purpose the verification method authorises?", "kind": "relationship", "answer_data": [ "declared proof purpose", "authorised purpose set reference", "purpose match result with reason code" ] }, { "id": "sig-verdict-q-collapse-rule", "text": "Which rule governs deriving a single summary flag, and what information does that derivation discard?", "kind": "constraint", "answer_data": [ "summary derivation rule", "dimensions consumed", "information-loss note" ] }, { "id": "sig-verdict-q-legal-effect-ref", "text": "Where is any qualification or legal-effect determination recorded, and under which jurisdiction and instrument was it made?", "kind": "authority", "answer_data": [ "determination reference", "jurisdiction identifier", "instrument reference", "determination date" ] } ], "data_elements": [ { "id": "sig-verdict-de-dimension-outcomes", "name": "Per-dimension outcomes", "description": "One entry per validity dimension, each carrying its own outcome code, reason codes and not-assessed marker.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-verdict-de-proof-purpose", "name": "Declared proof purpose", "description": "The purpose the proof declares, used to prevent a proof being applied to a purpose it was not created for.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-verdict-de-dimension-authority", "name": "Dimension determination authority", "description": "Reference to the external model, authority or instrument that determined a given non-cryptographic dimension.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-verdict-de-summary-flag", "name": "Derived summary flag", "description": "Optional single boolean derived for constrained consumers; admissible only with its derivation rule and loss note recorded.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Each dimension outcome is a coded reference to a determination that an external model or authority makes. Holding these as local artifacts would create a competing record of determinations this model does not perform, and would blur the boundary it exists to keep sharp." } ] } ] }, { "id": "sig-evid-bundle-trusted-time", "name": "Trusted time as evidence", "description": "Independently issued temporal evidence for a signature or proof: what was submitted for time-stamping, what the returned token asserts, which authority and policy stand behind it, and how the resulting instants may and may not be ordered against signer-claimed time.", "rationale": "A signature alone cannot say when it was made. RFC 5126 and NIST SP 800-102 separate a signer-claimed signing-time from a proof of existence, and eIDAS Article 42 requires binding of date and time to data so that undetectable change is precluded, with an accurate source linked to UTC. Trusted time therefore has to be its own bundle rather than an attribute of the signature.", "source_refs": [ "SRC-009", "SRC-068", "SRC-003", "SRC-070" ], "layers": [ { "id": "sig-evid-layer-timestamp-evidence", "name": "Time-stamp request and token evidence", "description": "The imprint that binds a token to a specific object, and the immutable token that fixes an instant with a serial number, accuracy bounds and a policy claim.", "source_refs": [ "SRC-009", "SRC-065", "SRC-003" ], "findings": [ { "id": "sig-evid-timestamp-imprint-binding", "name": "Time-stamp request and message-imprint binding", "description": "The hash algorithm and imprint value submitted for time-stamping, the requested policy, the nonce and certificate-request flag, and above all an unambiguous statement of which object the imprint covers: the signature value, the signed data, or a prior evidence element. Without this statement a token proves the existence of an unknown digest.", "source_refs": [ "SRC-009", "SRC-065", "SRC-003" ], "questions": [ { "id": "sig-evid-q-imprint-subject", "text": "Which exact byte sequence was hashed to form the message imprint, and is it the signature value, the signed data or a prior evidence element?", "kind": "composition", "answer_data": [ "Imprint subject class (signature-value, signed-data, prior-evidence, evidence-record)", "Stable reference to the covered artefact", "Byte-range or element-extraction rule applied before hashing" ] }, { "id": "sig-evid-q-imprint-algorithm", "text": "Which hash algorithm identifier and digest length formed the imprint, and was that algorithm acceptable under the algorithm policy in force when the request was made?", "kind": "constraint", "answer_data": [ "Hash algorithm object identifier or URI", "Digest length in octets", "Algorithm policy identifier and its status for that algorithm at request time" ] }, { "id": "sig-evid-q-imprint-nonce", "text": "Was a nonce supplied in the request, and does the returned token echo that identical value?", "kind": "security", "answer_data": [ "Nonce value as sent", "Nonce value as returned", "Match result and, where absent, the recorded replay-exposure note" ] }, { "id": "sig-evid-q-imprint-policy-request", "text": "Was a specific authority policy requested, and did the issued token assert that same policy?", "kind": "authority", "answer_data": [ "Requested policy identifier", "Asserted policy identifier in the token", "Divergence flag and handling decision" ] } ], "data_elements": [ { "id": "sig-evid-de-imprint-algorithm", "name": "Imprint hash algorithm", "description": "Identifier of the hash algorithm used to compute the message imprint submitted to the time authority.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-imprint-digest", "name": "Imprint digest value", "description": "The digest octets submitted as the message imprint; its length must match the declared algorithm.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-imprint-subject-ref", "name": "Imprint subject reference", "description": "Stable reference to the object whose digest was submitted, together with the class of that object.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-068" ] }, { "id": "sig-evid-de-request-nonce", "name": "Request nonce", "description": "Large random value supplied to bind request and response and to detect replay.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-requested-policy", "name": "Requested policy identifier", "description": "Policy the requester asked the authority to apply when producing the token.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-cert-req-flag", "name": "Certificate request flag", "description": "Whether the requester asked the authority to include its signing certificate in the response.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-065" ] } ], "artifacts": [ { "id": "sig-evid-art-timestamp-request", "name": "Time-stamp request record", "description": "The request as submitted, or a protocol-neutral descriptor of it, retained so that a later party can confirm what was actually presented for time-stamping and check the nonce echo.", "media_or_form": [ "DER-encoded TimeStampReq", "protocol-neutral request descriptor with algorithm, digest, policy and nonce", "transport log entry carrying the request payload" ], "serial": false, "identity_strategy": "Authoritative master-system identifier assigned by the requesting system where one exists; otherwise a governed IRI in the adopting Dimension namespace; otherwise a ULID recorded together with the imprint digest. The submission instant is never used as an identifier.", "source_refs": [ "SRC-009", "SRC-065" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-timestamp-token-identity", "name": "Time-stamp token identity, generation time and accuracy", "description": "The token exactly as issued: serial number, asserted generation time, accuracy bounds, ordering flag, echoed nonce, authority hint, policy identifier and the certificate identifier binding it to a time-stamping unit key. These bytes are the proof; everything else in the model is commentary on them.", "source_refs": [ "SRC-009", "SRC-065", "SRC-003", "SRC-070" ], "questions": [ { "id": "sig-evid-q-token-serial", "text": "What is the token serial number, and which issuing-authority namespace makes that serial unique?", "kind": "identity", "answer_data": [ "Token serial number as an integer of up to 160 bits", "Issuing authority name or identifier that scopes the serial", "Composite key formed from authority and serial" ] }, { "id": "sig-evid-q-token-gentime", "text": "What generation time does the token assert, and with what stated accuracy bounds?", "kind": "temporal", "answer_data": [ "Generation time normalised to RFC 3339 with seconds and explicit offset", "Original GeneralizedTime value retained verbatim", "Accuracy in seconds, milliseconds and microseconds, defaulting to zero where a component is absent" ] }, { "id": "sig-evid-q-token-ordering", "text": "Is the ordering flag asserted, and may two tokens from this authority be strictly ordered when their accuracy intervals overlap?", "kind": "constraint", "answer_data": [ "Ordering flag value or its absence", "Computed accuracy intervals for the compared tokens", "Orderability verdict: strictly ordered, unordered, or ordered only by authority assertion" ] }, { "id": "sig-evid-q-token-cert-binding", "text": "Which certificate identifier binds the token to the time-stamping unit key, and is it the legacy or the version-2 form?", "kind": "provenance", "answer_data": [ "ESSCertID or ESSCertIDv2 value and its hash algorithm", "Reference to the time-stamping unit certificate", "Note where only a SHA-1 based identifier is available" ] }, { "id": "sig-evid-q-token-status", "text": "Was the response status a granted issuance, and is any failure information recorded?", "kind": "state", "answer_data": [ "Status value (granted, granted with modifications, or a rejection)", "Free-text status string where provided", "Failure information bits where the request was refused" ] } ], "data_elements": [ { "id": "sig-evid-de-token-serial", "name": "Token serial number", "description": "Integer uniquely identifying the token within the issuing authority's namespace.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-token-gentime", "name": "Token generation time", "description": "Instant the authority asserts the token was created, normalised to RFC 3339 with seconds and an explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-070" ] }, { "id": "sig-evid-de-token-accuracy", "name": "Token accuracy bound", "description": "Stated deviation of the generation time from the authority's reference time source.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-token-ordering-flag", "name": "Token ordering flag", "description": "Authority assertion that its tokens are always strictly ordered irrespective of accuracy overlap.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-token-policy", "name": "Asserted policy identifier", "description": "Policy under which the authority states the token was issued.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-token-cert-identifier", "name": "Time-stamping unit certificate identifier", "description": "Certificate identifier attribute binding the token signature to a specific authority key.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-065" ] } ], "artifacts": [ { "id": "sig-evid-art-timestamp-token", "name": "Time-stamp token", "description": "The immutable issued token retained byte-identically, in whatever encoding it arrived, as the primary carrier of trusted time for the bound object.", "media_or_form": [ "DER-encoded RFC 3161 TimeStampToken as CMS SignedData", "XML time-stamp token element", "base64 token embedded in a signature container or document time-stamp revision" ], "serial": true, "identity_strategy": "Authoritative master-system identifier is the issuing authority identifier plus the token serial number. Where the authority cannot be resolved, a governed IRI is used; only if neither exists is a ULID minted by the adopting Dimension, always stored with the token digest. Generation time is never an identifier.", "source_refs": [ "SRC-009", "SRC-065" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-evid-layer-time-assurance", "name": "Time authority reference and temporal ordering", "description": "The authority and policy standing behind trusted time, and the ordering assertions that can defensibly be drawn between claimed, proven and observed instants.", "source_refs": [ "SRC-009", "SRC-068", "SRC-003", "SRC-070" ], "findings": [ { "id": "sig-evid-time-authority-reference", "name": "Time authority reference, policy and time-source assurance", "description": "Which authority issued the trusted time, under which published policy and qualification status, and what assurance of traceability to Coordinated Universal Time that policy claims. Carried strictly as resolvable references plus the subject-specific binding.", "source_refs": [ "SRC-009", "SRC-013", "SRC-003", "SRC-070" ], "questions": [ { "id": "sig-evid-q-authority-identity", "text": "Which authority identifier, certificate and published policy document govern the token relied on here?", "kind": "authority", "answer_data": [ "Authority identifier as asserted in the token and as resolved externally", "Reference to the authority certificate", "Resolvable pointer and version of the published policy or practice statement" ] }, { "id": "sig-evid-q-authority-utc", "text": "What traceability to Coordinated Universal Time does the authority's policy claim for tokens of this class?", "kind": "evidence", "answer_data": [ "Stated time-source traceability claim and its scope", "Reference to the clause of the policy making the claim", "Whether the claim was verified independently or accepted on reference" ] }, { "id": "sig-evid-q-authority-qualification", "text": "Was the authority supervised or qualified under a named trust framework at the moment the token was generated, and according to which list?", "kind": "classification", "answer_data": [ "Qualification or supervision status value", "Identifier and snapshot digest of the list consulted", "Instant at which the status was observed" ] }, { "id": "sig-evid-q-authority-compromise-path", "text": "If the authority is later found compromised or its policy is withdrawn, which recorded reference lets a verifier locate that determination?", "kind": "exception", "answer_data": [ "Reference to the status or incident source for this authority", "Classes of token affected by such a determination", "Pointer to the supersession assertion recorded when the determination arrives" ] } ], "data_elements": [ { "id": "sig-evid-de-authority-identifier", "name": "Time authority identifier", "description": "Identifier of the authority in its own issuing namespace, as asserted and as independently resolved.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-authority-policy-ref", "name": "Authority policy reference", "description": "Resolvable pointer plus version to the policy or practice statement under which the token was issued.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-070" ] }, { "id": "sig-evid-de-authority-qualification", "name": "Authority qualification status", "description": "Supervision or qualification status observed for the authority under a named framework, with the instant of observation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-070" ] }, { "id": "sig-evid-de-authority-utc-claim", "name": "UTC traceability claim", "description": "The authority's stated linkage of its time source to Coordinated Universal Time, recorded as a referenced claim rather than a verified fact.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-070", "SRC-003" ] }, { "id": "sig-evid-de-authority-status-source", "name": "Authority status source reference", "description": "Pointer to the external register or list that owns this authority's status lifecycle.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-070" ] } ], "artifacts": [], "inline_only_rationale": "The authority, its certificate chain, its published policy and its supervision status are issued, versioned and withdrawn by trust-service and supervision registries that this model does not operate. Materialising them as local artefacts would create a second master copy that silently drifts from the register of record and would invite an agent to treat a stale local copy as authoritative. What this finding legitimately holds is purely inline reference data: identifiers, resolvable pointers with versions, the observed status and its observation instant, and the binding of that authority to one specific token." }, { "id": "sig-evid-temporal-ordering", "name": "Ordered relation between claimed, proven and observed instants", "description": "The defensible ordering among signer-claimed signing time, each proof of existence, revocation and compromise instants, and each validation instant, together with the accuracy and clock-uncertainty bounds that make some pairs unorderable.", "source_refs": [ "SRC-009", "SRC-068", "SRC-061", "SRC-003" ], "questions": [ { "id": "sig-evid-q-claimed-versus-proven", "text": "How does the signer-claimed signing time relate to the earliest proof of existence recorded for the same signature?", "kind": "temporal", "answer_data": [ "Claimed signing time as asserted, marked as a claim", "Earliest proof-of-existence instant and the token establishing it", "Signed interval between them and any implausibility flag" ] }, { "id": "sig-evid-q-best-signature-time", "text": "What is the earliest defensible proof-of-existence instant for this signature, and which evidence element establishes it?", "kind": "measurement", "answer_data": [ "Best-signature-time value", "Reference to the establishing token or evidence record", "Whether the value is upper-bounded by accuracy and by how much" ] }, { "id": "sig-evid-q-unorderable-pairs", "text": "Which pairs of recorded instants cannot be strictly ordered because their accuracy or uncertainty intervals overlap?", "kind": "quality", "answer_data": [ "Pairs of instants compared", "Overlapping interval extents", "Resulting orderability verdict per pair" ] }, { "id": "sig-evid-q-poe-mechanism", "text": "Is any proof of existence established by a mechanism other than a time-stamp token, such as a time-mark held by a service provider or an archive time-stamp over an evidence chain?", "kind": "classification", "answer_data": [ "Proof-of-existence mechanism class", "Reference to the record or audit source that carries it", "Assurance note where the mechanism depends on a provider's own records" ] }, { "id": "sig-evid-q-event-versus-observation", "text": "Which recorded instants are event times asserted by an external party and which are observation or ingestion times recorded by this model?", "kind": "provenance", "answer_data": [ "Per-instant classification as event time or observation time", "Recording actor or system for each observation time", "Divergence where an event time was received long after it occurred" ] } ], "data_elements": [ { "id": "sig-evid-de-claimed-signing-time", "name": "Claimed signing time", "description": "Signer-asserted signing instant, retained as an unproven claim and never promoted to a proof of existence.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-068", "SRC-003" ] }, { "id": "sig-evid-de-best-signature-time", "name": "Best signature time", "description": "Earliest instant at which the signature is proven to have existed, derived from the recorded proof set.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-evid-de-poe-entry", "name": "Proof-of-existence entry", "description": "One derived assertion that a named object existed at or before a given instant, with the evidence element that supports it.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-062" ] }, { "id": "sig-evid-de-ordering-assertion", "name": "Ordering assertion", "description": "A pairwise assertion that one recorded instant precedes another, qualified by the bounds that permit or forbid the assertion.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "sig-evid-de-uncertainty-interval", "name": "Clock uncertainty interval", "description": "Bound within which a recorded instant may deviate, from stated accuracy or from a documented clock-quality assumption.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-003" ] }, { "id": "sig-evid-de-observation-time", "name": "Observation time", "description": "Instant at which this model observed or ingested the evidence, always recorded separately from the asserted event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061" ] } ], "artifacts": [], "inline_only_rationale": "These are derived relational assertions computed over proof artefacts that are already declared elsewhere in the model; they carry no bytes of their own. Freezing them into an artefact would fossilise a derivation that legitimately changes whenever a further proof of existence, a revocation record or a compromise determination arrives, and a frozen ordering table would be easy to mistake for independent evidence. Keeping them inline forces every ordering claim to be recomputed from the retained proofs, which is exactly the property an independent replayer needs." } ] } ] }, { "id": "sig-evid-bundle-validation-evidence", "name": "Replayable validation evidence", "description": "Everything a party who was not present at validation needs in order to reach the same conclusion: what the signature covered, which certificates and revocation data were used and how fresh they were, which trust anchors and algorithm constraints applied, which tool produced the verdict, at which instant, and with what indication and reasons.", "rationale": "eIDAS Article 32(2) requires the validating system to give the relying party the correct result and to let it detect security-relevant issues; RFC 5280 makes the validation date/time and trust anchors explicit inputs to path validation; and ETSI EN 319 102-1 with TS 119 102-2 turns the outcome into an indication, a sub-indication and the set of validation objects each conclusion depended on. A verdict without those inputs is not evidence.", "source_refs": [ "SRC-043", "SRC-061", "SRC-062", "SRC-070" ], "layers": [ { "id": "sig-evid-layer-validation-input", "name": "Validation inputs and configuration snapshot", "description": "The reconstructable material of a validation: the signature input digest and its transform chain, the certification path and revocation snapshot with freshness fields, and the trust and algorithm constraints in force.", "source_refs": [ "SRC-044", "SRC-043", "SRC-013", "SRC-016" ], "findings": [ { "id": "sig-evid-signed-input-digest", "name": "Signature input identification and digest", "description": "What the signature actually covers: the digest algorithm and value, the transform or canonicalization chain that produced the hashed octets, whether content is embedded, detached or absent, and the stable reference to the signed object in the system that owns it.", "source_refs": [ "SRC-016", "SRC-068", "SRC-062", "SRC-036" ], "questions": [ { "id": "sig-evid-q-input-digest", "text": "Which digest algorithm and digest value represent the signature input, and over which transformed octet stream were they computed?", "kind": "measurement", "answer_data": [ "Digest algorithm identifier", "Digest value octets", "Description of the octet stream actually hashed, including byte ranges where applicable" ] }, { "id": "sig-evid-q-input-transforms", "text": "Which transforms or canonicalization steps must be replayed in order to regenerate an identical digest input?", "kind": "process", "answer_data": [ "Ordered list of transform and canonicalization algorithm identifiers", "Parameters supplied to each step", "Known implementation divergences recorded for any step" ] }, { "id": "sig-evid-q-input-attachment", "text": "Is the signed content embedded with the signature, detached and referenced, or absent, and what happens to replay when a referenced object cannot be retrieved?", "kind": "exception", "answer_data": [ "Attachment mode value", "Retrieval reference and its resolution status", "Fallback position: digest-only verification retained, with the reduced assurance stated" ] }, { "id": "sig-evid-q-input-object-identity", "text": "Which stable reference identifies the signed data object in the model that owns it, and does that reference pin a specific version?", "kind": "identity", "answer_data": [ "Owning model or system identifier", "Object identifier and version or revision pin", "Digest recorded against that version at signing time" ] } ], "data_elements": [ { "id": "sig-evid-de-input-digest-algorithm", "name": "Signature input digest algorithm", "description": "Algorithm used to digest the signature input.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "sig-evid-de-input-digest-value", "name": "Signature input digest value", "description": "Digest octets over the transformed input, the value a replay must reproduce exactly.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "sig-evid-de-transform-chain", "name": "Transform chain", "description": "Ordered transform and canonicalization identifiers with parameters, required for a reproducible digest input.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-067" ] }, { "id": "sig-evid-de-attachment-mode", "name": "Content attachment mode", "description": "Whether signed content is enveloped, enveloping, detached with a resolvable reference, or absent.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-068" ] }, { "id": "sig-evid-de-signed-object-ref", "name": "Signed data object reference", "description": "Version-pinned reference to the signed object held by the owning content model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-068", "SRC-036" ] } ], "artifacts": [ { "id": "sig-evid-art-signed-input-manifest", "name": "Signed-input digest manifest", "description": "The retained description of every reference, transform and digest that together define the signature input, sufficient to rebuild the hashed octets without access to the original signing application.", "media_or_form": [ "reference, transform and digest manifest in any serialisation", "CMS signed-attribute set carrying content-type and message-digest", "XMLDSIG SignedInfo reference list with transforms", "PDF byte-range descriptor for a document signature" ], "serial": false, "identity_strategy": "Identified by the master-system identifier of the signature record that owns it where the signing or custody system assigns one; otherwise by a governed IRI; otherwise by a ULID stored with the manifest digest and the signature-input digest it describes.", "source_refs": [ "SRC-016", "SRC-068", "SRC-036" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-path-revocation-snapshot", "name": "Certification path and revocation-status snapshot with freshness", "description": "The certificates, certificate revocation lists and status responses actually used for one validation, captured with their own time fields and responder identities so that a later party can reconstruct the status picture that was available, rather than the one available today.", "source_refs": [ "SRC-044", "SRC-043", "SRC-068", "SRC-013" ], "questions": [ { "id": "sig-evid-q-path-composition", "text": "Which certificates form the prospective certification path, and are they retained by value or only by reference with a digest?", "kind": "composition", "answer_data": [ "Ordered certificate list from trust anchor to end entity", "Storage mode per certificate: value or reference plus digest", "Gaps where an intermediate could not be obtained" ] }, { "id": "sig-evid-q-revocation-freshness-fields", "text": "For each revocation source used, what are its production, this-update and next-update instants and its responder or issuer identity?", "kind": "evidence", "answer_data": [ "Revocation source type and identifier", "Production, this-update and next-update instants normalised to RFC 3339", "Responder or issuer identity and the key or name by which it was identified" ] }, { "id": "sig-evid-q-freshness-constraint", "text": "Was each revocation response fresh enough under the freshness constraint applied at the validation instant, and was a nonce or only a cached response available?", "kind": "validation", "answer_data": [ "Freshness constraint expressed as a maximum age or a next-update rule", "Per-source freshness verdict", "Nonce presence and, where absent, the recorded pre-produced-response replay caveat" ] }, { "id": "sig-evid-q-revocation-versus-poe", "text": "If a certificate was revoked, what revocation instant and reason were recorded, and how does that instant compare with the proof of existence for the signature?", "kind": "relationship", "answer_data": [ "Revocation instant and reason code", "Best-signature-time compared against the revocation instant", "Resulting position: proven before revocation, proven after, or indeterminate for want of proof" ] } ], "data_elements": [ { "id": "sig-evid-de-path-certificates", "name": "Certification path certificate set", "description": "The certificates relied on, ordered from trust anchor to end entity, stored by value or by reference with digest.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-043" ] }, { "id": "sig-evid-de-revocation-source", "name": "Revocation source entry", "description": "One retained revocation list or status response with its type, identifier and responder or issuer identity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044", "SRC-043" ] }, { "id": "sig-evid-de-revocation-time-fields", "name": "Revocation source time fields", "description": "Production, this-update and next-update instants of a revocation source, retained verbatim and normalised.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044", "SRC-043" ] }, { "id": "sig-evid-de-certificate-status", "name": "Certificate status value", "description": "Status determined for a certificate from the retained source: good, revoked or unknown.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044" ] }, { "id": "sig-evid-de-revocation-instant", "name": "Revocation instant and reason", "description": "Instant at which a certificate was revoked or suspended, with the recorded reason code.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-044", "SRC-043" ] } ], "artifacts": [ { "id": "sig-evid-art-validation-material-set", "name": "Validation material set", "description": "The retained bytes of certificates, revocation lists and status responses used for one validation, held so that revocation state can be re-derived without depending on responders that may later be unavailable.", "media_or_form": [ "DER certificates, CRLs and status responses", "CAdES certificate-values and revocation-values attributes", "XAdES validation-data properties", "PDF Document Security Store entries", "external validation-material package" ], "serial": false, "identity_strategy": "Each contained element keeps its own master-system identifier (issuer plus certificate serial number; issuer plus this-update for a revocation list; responder plus production instant for a status response). The set as a whole takes a governed IRI or, failing that, a ULID recorded with the set digest.", "source_refs": [ "SRC-044", "SRC-043", "SRC-013", "SRC-036" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-validation-constraints", "name": "Trust configuration and algorithm constraint snapshot", "description": "The trust anchors supplied to path validation, the state of the list or store they came from, the cryptographic suites treated as acceptable with their sunset instants, and the freshness, path and policy constraints applied. Retained so a replay can be run under either the original or a current constraint set and the difference attributed.", "source_refs": [ "SRC-043", "SRC-061", "SRC-013", "SRC-003" ], "questions": [ { "id": "sig-evid-q-trust-anchors", "text": "Which trust anchors were supplied to path validation, and from which list or trust-store state were they taken?", "kind": "provenance", "answer_data": [ "Trust anchor set with identifiers and key digests", "Identifier, version and digest of the list or store snapshot", "Instant at which the snapshot was captured" ] }, { "id": "sig-evid-q-crypto-constraints", "text": "Which cryptographic suites were treated as acceptable, and what sunset instant applied to each at the validation instant?", "kind": "constraint", "answer_data": [ "Suite identifiers with acceptable, deprecated or disallowed status", "Sunset instant per suite", "Minimum key sizes or parameter bounds applied" ] }, { "id": "sig-evid-q-constraint-criticality", "text": "Which freshness, path-length and policy constraints were applied, and which of them were mandatory rather than advisory?", "kind": "requirement", "answer_data": [ "Constraint list with parameters", "Criticality per constraint", "Identifier and version of the governing validation policy" ] }, { "id": "sig-evid-q-constraint-attribution", "text": "Can a replay distinguish a failure under the original constraint set from a failure that appears only under a stricter current constraint set?", "kind": "decision", "answer_data": [ "Verdict under the recorded historical constraint set", "Verdict under the current constraint set", "Attribution statement naming the constraint responsible for any difference" ] } ], "data_elements": [ { "id": "sig-evid-de-trust-anchor-set", "name": "Trust anchor set", "description": "Trust anchors supplied as an input to path validation, with identifiers and public-key digests.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-043" ] }, { "id": "sig-evid-de-trust-store-snapshot", "name": "Trust store snapshot reference", "description": "Version-pinned pointer and digest for the externally owned list or store from which anchors were taken.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-evid-de-crypto-constraint", "name": "Cryptographic suite constraint", "description": "One algorithm or parameter constraint with its status and, where applicable, its sunset instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-003" ] }, { "id": "sig-evid-de-constraint-criticality", "name": "Constraint criticality", "description": "Whether a given constraint failure forces a failed verdict or only a warning.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-evid-de-validation-policy-id", "name": "Validation policy identifier", "description": "Identifier and version of the policy that assembled this constraint set.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-068" ] } ], "artifacts": [ { "id": "sig-evid-art-constraint-snapshot", "name": "Validation constraint snapshot", "description": "The constraint set as it stood for one validation, retained as a versioned document or serialisation, with a pointer and digest for any externally owned list rather than a copy of it.", "media_or_form": [ "validation policy document with version", "serialised constraint set", "trust-store or list state pointer with digest" ], "serial": false, "identity_strategy": "Master-system identifier of the policy in the system that publishes it, where one exists; otherwise a governed IRI for the policy plus version; otherwise a ULID recorded with the digest of the serialised constraint set.", "source_refs": [ "SRC-061", "SRC-013", "SRC-043" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-evid-layer-validation-outcome", "name": "Validation outcome and replay determinism", "description": "The recorded result of a validation performed by an external application, and the contract stating what must be retained together for an independent party to reproduce it.", "source_refs": [ "SRC-061", "SRC-062", "SRC-013", "SRC-070" ], "findings": [ { "id": "sig-evid-validation-verdict", "name": "Validation verdict, sub-indications and dependency references", "description": "The outcome an accepted external validation application returned: main indication, sub-indication, per-constraint results, the validation objects each conclusion depended on, the validation instant, and the report carrying them. The model records this outcome; it does not evaluate, decide or enforce.", "source_refs": [ "SRC-061", "SRC-062", "SRC-013", "SRC-070" ], "questions": [ { "id": "sig-evid-q-verdict-indication", "text": "What main indication and sub-indication did the validating application return for this signature?", "kind": "validation", "answer_data": [ "Main indication value such as passed, failed or indeterminate", "Sub-indication value, preserved verbatim even when unrecognised", "Human-readable reason text as returned" ] }, { "id": "sig-evid-q-verdict-dependencies", "text": "Which specific validation objects did each conclusion depend on, and are all of them retained?", "kind": "relationship", "answer_data": [ "Per-conclusion list of dependent object references", "Retention status of each dependency: retained by value, by reference, or missing", "Replayability flag derived from the missing set" ] }, { "id": "sig-evid-q-verdict-report-format", "text": "Which validation report format and version carry the verdict, and is the report itself signed or sealed?", "kind": "interoperability", "answer_data": [ "Report format identifier and version", "Whether a report signature or seal is present and by whom", "Mapping notes where a proprietary report was normalised into the interchange form" ] }, { "id": "sig-evid-q-verdict-time-basis", "text": "Was the result determined at a validation time other than the moment the report was produced, and which instant governs the conclusion?", "kind": "temporal", "answer_data": [ "Validation instant used as the path-validation reference time", "Report production instant", "Statement of which instant governs and why they differ" ] }, { "id": "sig-evid-q-verdict-relying-party", "text": "What must be shown to a relying party for this result to be actionable, including signatory identification and any pseudonym or qualification flag?", "kind": "requirement", "answer_data": [ "Signatory identifying data as presented", "Pseudonym indicator where the certificate uses one", "Qualification or assurance flags and any security-relevant issues surfaced" ] } ], "data_elements": [ { "id": "sig-evid-de-main-indication", "name": "Main indication", "description": "Top-level outcome of the validation as returned by the validating application.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-evid-de-sub-indication", "name": "Sub-indication", "description": "Refining outcome code explaining why the main indication was reached; unknown values are preserved verbatim.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-evid-de-validation-instant", "name": "Validation instant", "description": "Reference instant used as the current date and time input to path validation for this outcome.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-043", "SRC-061" ] }, { "id": "sig-evid-de-report-production-time", "name": "Report production time", "description": "Instant at which the validating application produced the report, recorded separately from the validation instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-062" ] }, { "id": "sig-evid-de-constraint-result", "name": "Constraint evaluation result", "description": "Outcome of one evaluated constraint, with its identifier and the objects it consumed.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-062" ] }, { "id": "sig-evid-de-dependent-object-ref", "name": "Dependent validation object reference", "description": "Reference from a conclusion to a validation object it relied on, with the digest of that object.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-062" ] } ], "artifacts": [ { "id": "sig-evid-art-validation-report", "name": "Signature validation report", "description": "The retained report or verdict record as produced, carrying indications, reasons, validation objects and proof-of-existence entries, kept immutable so that a later contradictory result becomes a new record rather than an edit.", "media_or_form": [ "interchange validation report in the ETSI TS 119 102-2 structure", "implementation-specific simple or detailed report", "format-neutral verdict record with indication, reasons and dependency references" ], "serial": true, "identity_strategy": "Master-system identifier assigned by the validating application where one exists; otherwise a governed IRI in the adopting Dimension namespace; otherwise a ULID. Reports for one signature form an ordered series keyed by validation instant plus verifier identity, but the instant alone is never the identifier.", "source_refs": [ "SRC-062", "SRC-061", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-verifier-replay-determinism", "name": "Verifier identification and replay determinism", "description": "Which product, version, build and named configuration produced a recorded verdict, which inputs must be replayed unchanged, which parts of a replay still depend on network retrieval, and how a divergent replay result is recorded without touching the earlier record.", "source_refs": [ "SRC-061", "SRC-062", "SRC-013", "SRC-016" ], "questions": [ { "id": "sig-evid-q-verifier-identity", "text": "Which validating product, version and build produced this outcome, and under which named configuration was it run?", "kind": "identity", "answer_data": [ "Product identifier, version string and build fingerprint", "Configuration or profile name with its version", "Reference to the accepted-validator registry entry authorising its use" ] }, { "id": "sig-evid-q-replay-invariants", "text": "Which inputs must be replayed unchanged for the verdict to be reproducible, and which may legitimately vary?", "kind": "process", "answer_data": [ "Invariant input list: proof bytes, input digest manifest, validation material, constraint snapshot, validation instant", "Permitted-variation list such as verifier build or transport", "Named replay contract identifier and version" ] }, { "id": "sig-evid-q-replay-network-dependency", "text": "Which parts of a replay depend on live network retrieval rather than on retained evidence?", "kind": "quality", "answer_data": [ "Per-input source classification: retained locally or fetched at replay", "Consequence if each remote source becomes unavailable", "Remediation action such as capturing the missing element before it disappears" ] }, { "id": "sig-evid-q-replay-divergence", "text": "When a replay reaches a different verdict from the recorded one, how is the divergence captured without altering the earlier record?", "kind": "exception", "answer_data": [ "New verdict record with its own validation instant and constraint snapshot", "Divergence note naming the differing input or constraint", "Reference to any supersession assertion raised as a result" ] } ], "data_elements": [ { "id": "sig-evid-de-verifier-product", "name": "Verifier product identifier", "description": "Identifier of the validating application that produced a recorded outcome.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-062" ] }, { "id": "sig-evid-de-verifier-version", "name": "Verifier version and build", "description": "Version string and build fingerprint of the validating application at the time of the outcome.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-062", "SRC-013" ] }, { "id": "sig-evid-de-verifier-configuration-ref", "name": "Verifier configuration reference", "description": "Pointer to the named, versioned configuration under which the application was run.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-evid-de-replay-contract", "name": "Replay contract identifier", "description": "Identifier and version of the declared set of inputs that must be retained together for reproducibility.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-062" ] }, { "id": "sig-evid-de-network-dependency-flag", "name": "Network dependency flag", "description": "Whether a given replay input must be fetched remotely rather than read from retained evidence.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044", "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Verifier identity, version and configuration are descriptive parameters of a verdict that is already declared as an immutable artefact in the sibling finding, and the replay contract is a statement about which of the model's existing artefacts must be retained together. Minting a further artefact here would duplicate the validation report's payload and create two descriptions of a single immutable event that could drift apart. Keeping this finding inline makes the replay contract a property of the evidence set rather than another object competing to be the record of truth." } ] } ] }, { "id": "sig-evid-bundle-durability", "name": "Evidence durability, corroboration and degradation", "description": "How proof survives the weakening of the cryptography that protects it, how optional external corroboration is recorded without overclaiming, and how anomalies and reinterpretations are captured as new assertions rather than as edits.", "rationale": "RFC 4998 and RFC 6283 define renewal by new time-stamps or by hash-tree rebuild precisely because algorithms and keys expire; eIDAS Article 34 requires preservation that extends trustworthiness beyond the technological validity period; and RFC 9162 makes clear that a transparency log detects misissuance but does not establish legitimacy. Durability, corroboration and degradation therefore need explicit structure and explicit limits.", "source_refs": [ "SRC-066", "SRC-067", "SRC-069", "SRC-070" ], "layers": [ { "id": "sig-evid-layer-preservation", "name": "Evidence packaging and renewal", "description": "Where durable evidence lives relative to the signature container, and how its chain is kept unbroken across algorithm and key expiry.", "source_refs": [ "SRC-066", "SRC-067", "SRC-068", "SRC-036" ], "findings": [ { "id": "sig-evid-evidence-packaging", "name": "Evidence embedding versus external evidence package", "description": "Whether durable evidence is carried inside the signature container, held beside it as a detached evidence record, or both, and what binds an external package to the exact signature and input it covers when the subject is re-containerised.", "source_refs": [ "SRC-066", "SRC-067", "SRC-068", "SRC-013", "SRC-036" ], "questions": [ { "id": "sig-evid-q-packaging-mode", "text": "Is durable evidence embedded in the signature container, held as a detached evidence record, or maintained in both places at once?", "kind": "classification", "answer_data": [ "Packaging mode value", "Locations holding evidence for this subject", "Reconciliation rule where embedded and external evidence disagree" ] }, { "id": "sig-evid-q-claimed-level-substantiation", "text": "Which container profile and level does the embedded evidence claim, and is that claim substantiated by the elements actually present?", "kind": "validation", "answer_data": [ "Claimed profile and level identifier", "Inventory of elements present against those the level requires", "Substantiated, over-claimed or under-claimed verdict" ] }, { "id": "sig-evid-q-package-binding", "text": "If evidence is external, what binding ties the package to the exact signature and signed input it covers?", "kind": "relationship", "answer_data": [ "Digest of the covered signature and of the signature input", "Covered-object reference list with version pins", "Statement of what breaks the binding, such as re-encoding the container" ] }, { "id": "sig-evid-q-packaging-portability", "text": "How is the same evidence expressed when the subject moves between container formats or into a database projection?", "kind": "interoperability", "answer_data": [ "Per-format expression of each evidence element", "Elements with no equivalent in the target format and their fallback", "Invariants that must survive the move, principally digests and proof bytes" ] } ], "data_elements": [ { "id": "sig-evid-de-packaging-mode", "name": "Evidence packaging mode", "description": "Whether evidence is embedded, external, or duplicated in both locations.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-036" ] }, { "id": "sig-evid-de-container-profile", "name": "Container profile and level", "description": "Profile and long-term level claimed by the signature container carrying the evidence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-068", "SRC-013", "SRC-036" ] }, { "id": "sig-evid-de-package-binding-digest", "name": "Package binding digest", "description": "Digest that ties an external evidence package to the exact signature and input it covers.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-evid-de-covered-object-ref", "name": "Covered object reference", "description": "Version-pinned reference to each object the evidence package covers.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-066", "SRC-067" ] } ], "artifacts": [ { "id": "sig-evid-art-evidence-package", "name": "Durable evidence package", "description": "The retained long-term evidence for a subject, in whichever carrier it exists, held so that no single container format is required for the evidence to remain meaningful.", "media_or_form": [ "ASN.1 evidence record per RFC 4998", "XML evidence record per RFC 6283", "CAdES or XAdES long-term and archive properties", "PDF Document Security Store with document time-stamp revisions", "format-neutral evidence package index with digests and pointers" ], "serial": false, "identity_strategy": "Master-system identifier assigned by the preservation system of record where one exists; otherwise a governed IRI for the package; otherwise a ULID stored with the package digest and the digests of every covered object.", "source_refs": [ "SRC-066", "SRC-067", "SRC-036" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-renewal-continuity", "name": "Evidence renewal and chain continuity", "description": "How evidence is kept effective as algorithms and keys weaken: renewal by a new time-stamp over prior evidence when only the authority key is at issue, or hash-tree renewal over the full sequence when the digest algorithm itself is at issue, together with the continuity of the chain and the detection of gaps.", "source_refs": [ "SRC-066", "SRC-067", "SRC-068", "SRC-070" ], "questions": [ { "id": "sig-evid-q-renewal-kind", "text": "Was the most recent renewal a time-stamp renewal over prior evidence or a hash-tree renewal under a new digest algorithm?", "kind": "event", "answer_data": [ "Renewal kind value", "Trigger recorded for it, such as key compromise or algorithm weakening", "New digest algorithm where the tree was rebuilt" ] }, { "id": "sig-evid-q-renewal-deadline", "text": "By which instant is the next renewal due, and which algorithm or key expiry drives that deadline?", "kind": "lifecycle", "answer_data": [ "Next renewal due instant", "Driving expiry: authority certificate, signature algorithm or digest algorithm", "Reference to the algorithm policy entry setting the sunset" ] }, { "id": "sig-evid-q-chain-continuity", "text": "Is the chain from the first proof of existence to the most recent renewal unbroken, and where exactly does any gap fall?", "kind": "validation", "answer_data": [ "Ordered chain of archive time-stamps or renewal records", "Continuity verdict", "Location and duration of any gap and the evidence affected" ] }, { "id": "sig-evid-q-redundant-chains", "text": "Which redundant evidence chains exist under different digest algorithms or different authorities for this subject?", "kind": "composition", "answer_data": [ "List of independent chains with their algorithms and authorities", "Degree of independence, including shared authority or shared algorithm", "Note where only one chain exists and the resulting single point of failure" ] }, { "id": "sig-evid-q-missed-renewal", "text": "If a renewal is missed until after the protecting algorithm has already weakened, what is recorded and what assurance remains?", "kind": "exception", "answer_data": [ "Missed-deadline record with the affected interval", "Residual assurance statement naming what is still provable", "Compensating action such as adding a redundant chain or capturing external corroboration" ] } ], "data_elements": [ { "id": "sig-evid-de-renewal-kind", "name": "Renewal kind", "description": "Whether a renewal re-time-stamped prior evidence or rebuilt the hash tree under a new digest algorithm.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-evid-de-renewal-instant", "name": "Renewal instant", "description": "Instant at which a renewal was effected, taken from the renewing time-stamp rather than from local clock.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-066" ] }, { "id": "sig-evid-de-next-renewal-due", "name": "Next renewal due instant", "description": "Deadline by which the evidence must be renewed to stay continuous, derived from algorithm and key expiry.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-066", "SRC-070" ] }, { "id": "sig-evid-de-chain-continuity-status", "name": "Chain continuity status", "description": "Whether the evidence chain is unbroken from the first proof of existence to the latest renewal.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-evid-de-redundant-chain-ref", "name": "Redundant chain reference", "description": "Reference to an independent evidence chain using a different algorithm or authority.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-066" ] } ], "artifacts": [ { "id": "sig-evid-art-renewal-record", "name": "Evidence renewal record", "description": "The retained record of one renewal: the new archive time-stamp or document time-stamp, the reduced hash tree or equivalent linkage, and the identification of everything the renewal covers.", "media_or_form": [ "archive time-stamp entry within a chain or sequence", "document time-stamp revision appended to a container", "renewal event record with covered-object digests and linkage data" ], "serial": true, "identity_strategy": "Master-system identifier is the renewing authority identifier plus the renewing token serial number. Renewal records form an ordered series within a chain; the chain position is recorded and gaps are represented explicitly rather than closed by renumbering.", "source_refs": [ "SRC-066", "SRC-067", "SRC-036" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-evid-layer-corroboration-anomaly", "name": "External corroboration and evidence degradation", "description": "Optional publication corroboration recorded with explicit limits, and the anomalies, compromises and reinterpretations that change what retained evidence means.", "source_refs": [ "SRC-044", "SRC-069", "SRC-061", "SRC-003" ], "findings": [ { "id": "sig-evid-transparency-corroboration", "name": "Transparency-log corroboration references", "description": "Inclusion and consistency proof references, log identity, entry locator and signed checkpoints, recorded as optional corroboration that something was published at a point in a verifiable append-only structure — and explicitly not as proof of signer identity, authorisation or the truth of the signed content.", "source_refs": [ "SRC-069", "SRC-043", "SRC-061" ], "questions": [ { "id": "sig-evid-q-log-entry-locator", "text": "Which log identity, entry index and tree size does the recorded inclusion proof refer to?", "kind": "provenance", "answer_data": [ "Log identifier in its governed namespace", "Entry index and tree size at which the proof was taken", "Leaf input digest that the proof reconstructs to the root" ] }, { "id": "sig-evid-q-log-checkpoint", "text": "Which signed checkpoint or signed tree head was current when the proof was captured, and which key signed it?", "kind": "evidence", "answer_data": [ "Checkpoint or tree head value with its timestamp and tree size", "Signing key identifier and verification result", "Consistency proof linking it to any previously recorded checkpoint" ] }, { "id": "sig-evid-q-corroboration-limits", "text": "What does this corroboration deliberately not establish about the signer or the signed content?", "kind": "definition", "answer_data": [ "Explicit negative scope statement retained with the record", "Claims that remain dependent on certification path and revocation evidence", "Warning text surfaced to any agent reading the corroboration alone" ] }, { "id": "sig-evid-q-log-failure", "text": "If the log is later shown to be inconsistent, is decommissioned, or its key is withdrawn, what remains provable from the retained evidence?", "kind": "exception", "answer_data": [ "Residual proof set independent of the log", "Recorded status of the log and pointer to the determination", "Supersession assertion downgrading the corroboration" ] } ], "data_elements": [ { "id": "sig-evid-de-log-identifier", "name": "Log identifier", "description": "Governed identifier of the append-only log the corroboration refers to.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-069" ] }, { "id": "sig-evid-de-inclusion-proof-ref", "name": "Inclusion proof reference", "description": "Reference to a proof that a specific leaf is present in a specific tree state.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-069" ] }, { "id": "sig-evid-de-consistency-proof-ref", "name": "Consistency proof reference", "description": "Reference to a proof that a later tree state extends an earlier one without modification.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-069" ] }, { "id": "sig-evid-de-checkpoint-ref", "name": "Signed checkpoint reference", "description": "Signed tree head or checkpoint against which the proofs were verified, with its tree size and timestamp.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-069" ] }, { "id": "sig-evid-de-corroboration-scope", "name": "Corroboration scope statement", "description": "Mandatory statement of what the corroboration does and does not establish, stored with the reference itself.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-069" ] } ], "artifacts": [ { "id": "sig-evid-art-corroboration-reference", "name": "Transparency corroboration reference set", "description": "The retained proof references and checkpoint copies that corroborate publication, kept small and pointer-based so that the log itself remains the system of record for entries and tree state.", "media_or_form": [ "inclusion and consistency proof reference record", "copy of a signed tree head or checkpoint", "log entry locator with leaf digest" ], "serial": false, "identity_strategy": "Master-system identifier is the log identifier plus entry index where the log assigns one; otherwise a governed IRI for the proof reference set; otherwise a ULID stored with the leaf digest and checkpoint digest.", "source_refs": [ "SRC-069" ] } ], "inline_only_rationale": null }, { "id": "sig-evid-anomaly-supersession", "name": "Evidence anomalies, degradation and supersession assertions", "description": "Conditions that damage or change the meaning of retained evidence — unavailable or retracted status responders, expired certificates, keys revoked or compromised after signing, a compromised time authority, digest-algorithm collision migration, orphaned signed content and clock uncertainty — recorded as new append-only assertions that supersede an earlier interpretation while leaving every earlier record byte-identical.", "source_refs": [ "SRC-066", "SRC-044", "SRC-043", "SRC-068", "SRC-061", "SRC-003" ], "questions": [ { "id": "sig-evid-q-anomaly-class", "text": "Which anomaly class applies here, and which prior evidence records does it affect?", "kind": "classification", "answer_data": [ "Anomaly class such as responder unavailable, status retracted, certificate expired, key revoked after proof, authority compromised, digest algorithm broken, content orphaned, clock unreliable", "References to every affected evidence record", "Scope: one signature, one authority's tokens, or a whole algorithm class" ] }, { "id": "sig-evid-q-supersession-integrity", "text": "Which superseding assertion replaces the interpretation of an earlier record, and does that earlier record remain byte-identical?", "kind": "state", "answer_data": [ "Superseding assertion identifier and its content", "Digest of the affected record before and after, demonstrating identity", "Chain of superseding assertions where more than one applies" ] }, { "id": "sig-evid-q-revoked-after-proof", "text": "Was a key revoked or found compromised after the proof of existence, and does the retained evidence still support validity at that earlier instant?", "kind": "temporal", "answer_data": [ "Revocation or compromise instant and its source", "Best-signature-time compared against that instant", "Resulting position, including the case where the compromise is stated to predate the proof" ] }, { "id": "sig-evid-q-collision-migration", "text": "If a digest algorithm protecting this evidence becomes collision-prone, what migration was performed and what residual risk remains?", "kind": "security", "answer_data": [ "Migration action and the instant it completed", "Digests recorded under the new algorithm alongside the historical ones", "Residual risk statement covering the interval before migration" ] }, { "id": "sig-evid-q-anomaly-retention", "text": "How long must the affected proof bytes and prior validation records be retained after a supersession assertion, and who decides that?", "kind": "retention", "answer_data": [ "Retention floor derived from the replay contract and the last renewal deadline", "Any active hold and its reference", "Named external retention or legal-hold model that owns the decision and its execution" ] } ], "data_elements": [ { "id": "sig-evid-de-anomaly-class", "name": "Anomaly class", "description": "Classification of the condition affecting retained evidence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044", "SRC-061" ] }, { "id": "sig-evid-de-affected-record-ref", "name": "Affected record reference", "description": "Reference plus digest for every evidence record whose interpretation the anomaly changes.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-066", "SRC-061" ] }, { "id": "sig-evid-de-supersession-assertion", "name": "Supersession assertion", "description": "Append-only statement that a later interpretation replaces an earlier one, naming the affected records and the reason.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-066" ] }, { "id": "sig-evid-de-assertion-observation-time", "name": "Assertion observation time", "description": "Instant at which the anomaly was observed and the assertion recorded, distinct from the instant the underlying event occurred.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-044" ] }, { "id": "sig-evid-de-residual-assurance", "name": "Residual assurance statement", "description": "What remains provable after the anomaly, stated explicitly rather than left to inference.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-068", "SRC-003" ] }, { "id": "sig-evid-de-external-determination-ref", "name": "External determination reference", "description": "Pointer to the external authority determination that establishes a compromise, retraction or withdrawal.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-043" ] } ], "artifacts": [ { "id": "sig-evid-art-supersession-assertion", "name": "Supersession or invalidation assertion", "description": "An append-only record asserting that the interpretation of named evidence has changed, carrying the affected record digests, the reason, the observation instant and any external determination reference. It never modifies the records it names.", "media_or_form": [ "append-only assertion record in any serialisation", "signed statement over the affected record identifiers and digests", "chained assertion entry referencing a prior assertion" ], "serial": true, "identity_strategy": "Master-system identifier assigned by the asserting system where one exists; otherwise a governed IRI; otherwise a ULID. Assertions over one subject form an ordered series keyed by the assertion sequence, never by observation date, and each entry carries the digest of the assertion it follows.", "source_refs": [ "SRC-066", "SRC-061" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-gov-proof-change-control", "name": "Proof Lifecycle, Controlled Change and Compromise Response", "description": "How a governed proof record comes into being, how it may only be corrected forward by supersession, how changes to algorithm, key reference, trust anchor and pinned policy are recorded, and how emergency compromise is captured, bounded by exceptions with mandatory expiry and defined rollback.", "rationale": "Every cited normative source separates the immutable cryptographic fact from the mutable governance judgement about it. Data Integrity expresses correction by appended proof chains, C2PA by update manifests, and X.509 by a superseded revocation reason - none by in-place edit. Algorithm transition and compromise are the two forces that invalidate previously acceptable proofs, and both originate outside this model, so they must be recorded as referenced events with scope and reported outcome rather than executed here.", "source_refs": [ "SRC-061", "SRC-004", "SRC-073", "SRC-043", "SRC-055", "SRC-057", "SRC-013" ], "layers": [ { "id": "sig-gov-lifecycle-supersession", "name": "Governance State and Immutable Correction", "description": "The state a proof record holds in the governance plane, distinct from the cryptographic outcome reported by an external validator, and the append-only supersession mechanism that is the only route to substantive correction.", "source_refs": [ "SRC-061", "SRC-004", "SRC-073", "SRC-043", "SRC-013" ], "findings": [ { "id": "sig-gov-proof-state-register", "name": "Governance state and its separation from reported validation outcome", "description": "A proof record carries a governance state set by an accountable role - for example declared, in force, superseded, expired by policy, invalidated by compromise, or withdrawn. This is categorically not the cryptographic validation outcome. Validation indications such as TOTAL-PASSED, TOTAL-FAILED or INDETERMINATE with sub-indications, C2PA error, warning and informational status codes, or a Data Integrity verification result, are recorded as attributed observations from an external validator at a stated time, never recomputed or overridden here. A record may simultaneously hold an in-force governance state and an INDETERMINATE reported outcome; the model must be able to express that without collapsing the two.", "source_refs": [ "SRC-061", "SRC-004", "SRC-073", "SRC-013" ], "questions": [ { "id": "sig-gov-q-state-vocabulary", "text": "Which governance states may a proof record occupy, and which state transitions are permitted?", "kind": "state", "answer_data": [ "Enumerated governance state codes with the pinned vocabulary version", "Permitted from-state to to-state transition pairs", "Trigger reference required for each permitted transition", "States that are terminal and admit no further transition" ] }, { "id": "sig-gov-q-state-vs-outcome", "text": "How is the governance state kept distinct from the externally reported cryptographic validation outcome?", "kind": "validation", "answer_data": [ "Reported indication and sub-indication code with its source vocabulary", "Reporting validator reference and validation report reference", "Time the outcome was reported and the time it was ingested", "Written separation rule stating that an outcome never sets a state automatically" ] }, { "id": "sig-gov-q-state-effective-time", "text": "At what event time did the current governance state take effect, and when was that state observed or ingested?", "kind": "temporal", "answer_data": [ "State effective timestamp in RFC 3339 with seconds and explicit offset or Z", "Observation or ingestion timestamp recorded separately", "Time source reference, including any trusted time-stamp token relied upon" ] }, { "id": "sig-gov-q-state-authority", "text": "Which role holds the authority to set or change the governance state of a proof record?", "kind": "authority", "answer_data": [ "Authoritative role code for each transition", "Delegation reference where authority is delegated", "Reference to the decision record that justified the transition" ] } ], "data_elements": [ { "id": "sig-gov-de-proof-record-id", "name": "Proof record identifier", "description": "Identifier of the governed proof record, assigned by the stated identity priority.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-043" ] }, { "id": "sig-gov-de-governance-state", "name": "Governance state code", "description": "Current state of the proof record in the governance plane, from the pinned state vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-073", "SRC-013" ] }, { "id": "sig-gov-de-state-effective-at", "name": "State effective time", "description": "Event time at which the current governance state took effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-gov-de-state-observed-at", "name": "State observation time", "description": "Time at which this model observed or ingested the state, recorded separately from event time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061" ] }, { "id": "sig-gov-de-reported-validation-indication", "name": "Reported validation indication", "description": "Validation indication and sub-indication as reported by an external validator, with its source vocabulary.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-073", "SRC-013" ] }, { "id": "sig-gov-de-validation-report-ref", "name": "Validation report reference", "description": "Reference to the externally produced validation report supporting a reported indication.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "The governance state and the reported validation indication are field-level values carried on the mixin itself and on referenced external reports. No separate document is produced: the state vocabulary belongs to the owner package, and the validation report is authored and stored by the external validator, so materialising a local artifact here would duplicate a target-owned record and invite it being treated as evidence this model did not create." }, { "id": "sig-gov-supersession-chain", "name": "Immutable correction by supersession", "description": "A proof record is never edited in place for substantive content. A correction is expressed by issuing a successor record that references the record it replaces and by moving the prior record to a superseded state while keeping it resolvable. This mirrors ordered proof chains linked by previousProof, C2PA update manifests that document modifications while preserving prior provenance, and the X.509 superseded revocation reason. The superseded record retains its original pins, its original reported outcomes and its own supersession links, so an evidentiary chain can be reconstructed at any past point.", "source_refs": [ "SRC-004", "SRC-073", "SRC-043", "SRC-075" ], "questions": [ { "id": "sig-gov-q-supersession-trigger", "text": "What conditions require a proof record to be superseded rather than corrected in place?", "kind": "constraint", "answer_data": [ "Enumerated substantive fields whose change forces supersession", "Enumerated non-substantive fields that may be updated in place", "Reference to the owner package rule that fixes the two lists" ] }, { "id": "sig-gov-q-supersession-link", "text": "How is the ordered link between a superseding record and the record it replaces expressed and resolved?", "kind": "relationship", "answer_data": [ "Forward reference from successor to superseded record", "Back reference from superseded record to its successor", "Chain position or ordinal within the supersession chain", "Rule for detecting and rejecting forks in the chain" ] }, { "id": "sig-gov-q-supersession-reason", "text": "Which reason code and supporting evidence justify each supersession?", "kind": "evidence", "answer_data": [ "Supersession reason code from the pinned vocabulary", "Reference to the review or decision record that authorised it", "Acting role reference and recorded-at timestamp" ] }, { "id": "sig-gov-q-superseded-retention", "text": "For how long must a superseded proof record remain resolvable after it has been replaced?", "kind": "retention", "answer_data": [ "Retention schedule reference governing superseded records", "Any legal hold reference that extends resolvability", "Minimum resolvability guarantee expressed as a policy reference, not a local deletion right" ] } ], "data_elements": [ { "id": "sig-gov-de-supersedes-ref", "name": "Supersedes reference", "description": "Reference from a successor proof record to the record it replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-gov-de-superseded-by-ref", "name": "Superseded-by reference", "description": "Back reference from a superseded proof record to its successor.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-073" ] }, { "id": "sig-gov-de-supersession-reason-code", "name": "Supersession reason code", "description": "Coded justification for the supersession, from the pinned vocabulary.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-gov-de-supersession-recorded-at", "name": "Supersession recorded time", "description": "Time at which the supersession was recorded in this model.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-gov-de-chain-position", "name": "Supersession chain position", "description": "Monotonic ordinal of the record within its supersession chain.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-073" ] } ], "artifacts": [ { "id": "sig-gov-art-supersession-record", "name": "Proof supersession record", "description": "An append-only entry recording that one proof record supersedes another, with reason code, acting role reference, recorded-at time and chain position. It does not restate the superseded record's content and never authorises its deletion.", "media_or_form": [ "structured record entry", "append-only linked entry in a chain", "human-readable governance statement" ], "serial": true, "identity_strategy": "Named by the superseded proof record identifier plus the artifact kind plus a monotonic sequence, never by date; the sequence is unique per proof record and never reused.", "source_refs": [ "SRC-004", "SRC-073", "SRC-043" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-gov-change-control", "name": "Controlled Change to Method, Keys, Trust Anchors and Policy", "description": "Governed change records for the signing method and key reference used for future proofs, and for the pinned signature policy, validation policy, trust-anchor set and jurisdictional regime that govern existing proofs.", "source_refs": [ "SRC-071", "SRC-004", "SRC-043", "SRC-055", "SRC-057", "SRC-076", "SRC-013" ], "findings": [ { "id": "sig-gov-method-change-record", "name": "Controlled change of signing method and key reference", "description": "Records a governed change to the algorithm or cryptosuite identifier, hash, format profile, or the key or signing-service reference used for proofs created after the change. Each method identifier carries a transition status drawn from the cryptographic transition regime - broadly acceptable, deprecated, restricted to verification of previously generated signatures, or disallowed - together with the effective interval of that status. A transition imposes remediation obligations on already recorded proofs: re-sign under a current method, augment with long-term validation material and archive time-stamps, or accept as legacy verification-only. Key generation, custody and rotation execution belong to the cryptographic key model; only the reference and the change record are held here.", "source_refs": [ "SRC-004", "SRC-055", "SRC-001", "SRC-057", "SRC-013" ], "questions": [ { "id": "sig-gov-q-method-status", "text": "Which signing method identifier and version are in force, and which transition status applies to it?", "kind": "classification", "answer_data": [ "Method or cryptosuite identifier with its version, including any date-based suite version", "Hash and format profile identifiers", "Transition status code and the source regime that assigned it", "Effective interval over which that status holds" ] }, { "id": "sig-gov-q-method-change-obligation", "text": "What remediation obligation does a method transition impose on proofs that were already recorded?", "kind": "requirement", "answer_data": [ "Obligation code such as re-sign, augment, preserve or accept as legacy", "Target augmentation level or preservation profile reference", "Deadline expressed as an effective interval, not a bare date identifier", "Set of affected proof record references" ] }, { "id": "sig-gov-q-method-change-decision", "text": "Who decided the method change, and on what documented basis was it decided?", "kind": "decision", "answer_data": [ "Deciding role reference and its authority basis", "Reference to the transition source or advisory relied upon", "Reference to the review and approval record", "Recorded dissent or conditions attached to the decision" ] }, { "id": "sig-gov-q-method-legacy-window", "text": "Over what interval does a superseded method remain acceptable for verification of existing proofs only?", "kind": "temporal", "answer_data": [ "Start and end of the verification-only interval in RFC 3339 with explicit offset", "Generation-disallowed effective time", "Reference to the authority that set the interval" ] } ], "data_elements": [ { "id": "sig-gov-de-method-identifier", "name": "Signing method identifier", "description": "Algorithm, cryptosuite or format profile identifier pinned to the proof record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "sig-gov-de-method-suite-version", "name": "Method suite version", "description": "Version of the cryptosuite or format profile, including date-based suite versions used for agility.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "sig-gov-de-transition-status", "name": "Method transition status", "description": "Status assigned to the method by the applicable transition regime, with its source.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-057" ] }, { "id": "sig-gov-de-signing-key-ref", "name": "Signing key or credential reference", "description": "Reference to the key or credential in the external key model; no key material is held here.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-055", "SRC-077" ] }, { "id": "sig-gov-de-remediation-obligation-code", "name": "Remediation obligation code", "description": "Obligation imposed on existing proofs by a method transition.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-057", "SRC-013" ] } ], "artifacts": [ { "id": "sig-gov-art-method-change-record", "name": "Signing method change record", "description": "A dated-by-content but sequence-named entry capturing a change of method, key reference or transition status, the affected scope, the remediation obligations and the deciding role. It reports a change decided elsewhere; it does not perform key rotation or re-signing.", "media_or_form": [ "structured change record", "governance change note", "tabular obligation schedule" ], "serial": true, "identity_strategy": "Named by the owning scope identifier plus the artifact kind plus a monotonic sequence; no date component is used in the name.", "source_refs": [ "SRC-057", "SRC-055", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "sig-gov-anchor-policy-pinning", "name": "Trust-anchor set, signature policy and jurisdictional regime pinning", "description": "Pins, by reference and version, the signature policy and validation policy that govern a proof, the trust-anchor or trusted-list set applicable at event time including the list's published version and status history, and any jurisdictional trust-service regime asserted to apply, with a jurisdiction code and an effective interval. Signature policies are authored and signed by a signature policy issuer and may contain applicability rules about business or legal fitness that go beyond technical validation constraints; this model pins them and never authors them. A pinned regime reference records that a regime was asserted, not that a legal conclusion holds.", "source_refs": [ "SRC-061", "SRC-071", "SRC-073", "SRC-043", "SRC-076", "SRC-013" ], "questions": [ { "id": "sig-gov-q-policy-pin-identity", "text": "Which signature policy and validation policy versions are pinned to this proof record?", "kind": "identity", "answer_data": [ "Signature policy reference with issuer and version", "Validation policy or constraint set reference with version", "Identifier of the applicability rules relied upon", "Digest of the pinned policy document where available" ] }, { "id": "sig-gov-q-anchor-set-pin", "text": "Which trust-anchor or trusted-list set, at which published version, was applicable when the proof was created?", "kind": "provenance", "answer_data": [ "Trust-anchor set or trusted-list reference with published version", "Relevant service status history entry reference", "Revocation freshness constraint that was in force", "Whether the anchor set was validator-configured or a default list" ] }, { "id": "sig-gov-q-jurisdiction-regime", "text": "Which jurisdictional trust-service regime is asserted to apply, and over what effective interval?", "kind": "spatial", "answer_data": [ "Jurisdiction code and the naming authority for that code", "Regime or instrument reference with the article or clause relied upon", "Effective interval start and end in RFC 3339 with explicit offset", "Note of any known divergence between jurisdictional texts of the same instrument" ] }, { "id": "sig-gov-q-policy-change-effect", "text": "How does a change to the pinned policy or anchor set affect proofs that were already recorded?", "kind": "lifecycle", "answer_data": [ "Rule stating that existing records keep their original pins", "New pin record reference applying to subsequent proofs", "Re-evaluation obligation and its target scope", "Governance state consequence, if any, for existing records" ] }, { "id": "sig-gov-q-regime-claim-limit", "text": "What prevents a pinned regional regime reference from being read as a universal legal conclusion?", "kind": "constraint", "answer_data": [ "Explicit statement that the reference is an assertion of applicability only", "Named external party responsible for legal-effect assessment", "Prohibition on deriving a local legal-validity flag from the pin" ] } ], "data_elements": [ { "id": "sig-gov-de-signature-policy-ref", "name": "Signature policy reference", "description": "Reference to the externally issued signature policy governing the proof.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-071" ] }, { "id": "sig-gov-de-policy-version", "name": "Pinned policy version", "description": "Version identifier of the pinned signature or validation policy.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-gov-de-trust-anchor-set-ref", "name": "Trust-anchor set reference", "description": "Reference to the trust-anchor or trusted-list set with its published version.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-043", "SRC-013", "SRC-073" ] }, { "id": "sig-gov-de-jurisdiction-code", "name": "Jurisdiction code", "description": "Coded jurisdiction under which a trust-service regime is asserted to apply.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-076" ] }, { "id": "sig-gov-de-regime-effective-interval", "name": "Regime effective interval", "description": "Start and end of the interval over which the pinned jurisdictional regime is asserted to apply.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-076" ] } ], "artifacts": [ { "id": "sig-gov-art-policy-anchor-pin-record", "name": "Signature policy and trust-anchor pin record", "description": "A versioned binding entry that fixes which policy version, trust-anchor set version and jurisdictional regime applied to a defined scope over a defined interval. It carries references and versions only, never a copy of the external policy or list.", "media_or_form": [ "structured pin record", "versioned binding table", "human-readable policy binding statement" ], "serial": true, "identity_strategy": "Named by the governed scope identifier plus the artifact kind plus a monotonic pin sequence; the pinned policy's own identifier and version are carried as fields, not as the artifact name.", "source_refs": [ "SRC-071", "SRC-013", "SRC-076" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-gov-compromise-exception", "name": "Compromise Response and Bounded Exceptions", "description": "Emergency response to an externally declared compromise affecting proofs, and the time-boxed exceptions under which a proof that does not satisfy its pinned policy may still be accepted for a stated purpose.", "source_refs": [ "SRC-061", "SRC-073", "SRC-043", "SRC-055", "SRC-077", "SRC-013" ], "findings": [ { "id": "sig-gov-compromise-response-record", "name": "Emergency compromise response record", "description": "Captures the reference to an externally declared compromise of a key, credential, algorithm or trust anchor, the reason code, the asserted invalidity time from which affected proofs are treated as suspect, the frozen set of proof records within the blast radius, the required response actions and the outcome reported by the executing party. Trusted time-stamps or a preserved long-term validation evidence set may mitigate the compromise for proofs demonstrably created before the invalidity time, so mitigation evidence is recorded alongside the scope. Revocation, key destruction, certificate reissuance and incident handling are executed by the key and PKI models under their own timelines; this model records the reference, the scope and the reported outcome.", "source_refs": [ "SRC-073", "SRC-043", "SRC-055", "SRC-077", "SRC-013" ], "questions": [ { "id": "sig-gov-q-compromise-notification", "text": "Which external compromise declaration or problem report triggered the response, and who issued it?", "kind": "event", "answer_data": [ "Reference to the external declaration, problem report or incident record", "Issuing party reference and its role code", "Time the declaration was issued and the time it was received here", "Reason code such as key compromise or authority compromise" ] }, { "id": "sig-gov-q-invalidity-time", "text": "From which asserted invalidity time are affected proofs to be treated as suspect?", "kind": "temporal", "answer_data": [ "Asserted invalidity time in RFC 3339 with seconds and explicit offset", "Source of the assertion and its confidence qualifier", "Distinction between asserted invalidity time and the time revocation was published" ] }, { "id": "sig-gov-q-affected-scope", "text": "Which proof records fall within the compromise blast radius, and how is that set computed and frozen?", "kind": "composition", "answer_data": [ "Scope selection criteria such as key reference, method identifier or anchor set", "Frozen list of affected proof record references with the freeze time", "Records excluded from scope and the stated ground for exclusion" ] }, { "id": "sig-gov-q-response-outcome", "text": "Which response actions were required, and what outcome did the executing party report?", "kind": "process", "answer_data": [ "Required action list with the owning external model for each", "Reported outcome code and completion time per action", "Reference to the evidence supplied by the executing party", "Residual risk statement where an action could not be completed" ] }, { "id": "sig-gov-q-timestamp-mitigation", "text": "Does a trusted time-stamp or preserved evidence set mitigate the compromise for proofs created before the invalidity time?", "kind": "evidence", "answer_data": [ "Time-stamp token reference and issuing authority reference", "Preserved validation evidence set reference and its profile", "Mitigation determination code and the role that recorded it" ] } ], "data_elements": [ { "id": "sig-gov-de-compromise-event-ref", "name": "Compromise declaration reference", "description": "Reference to the externally issued compromise declaration or problem report.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-077", "SRC-055" ] }, { "id": "sig-gov-de-compromise-reason-code", "name": "Compromise reason code", "description": "Coded compromise reason, aligned to the external revocation reason vocabulary where applicable.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-gov-de-asserted-invalidity-at", "name": "Asserted invalidity time", "description": "Time from which the compromised key or credential is asserted to have been untrustworthy.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-043" ] }, { "id": "sig-gov-de-affected-proof-refs", "name": "Affected proof record set", "description": "Frozen collection of proof record references within the compromise scope.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-073" ] }, { "id": "sig-gov-de-response-outcome-code", "name": "Reported response outcome", "description": "Outcome reported by the party that executed a required response action.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-077" ] } ], "artifacts": [ { "id": "sig-gov-art-compromise-response-record", "name": "Proof compromise response record", "description": "An entry recording the referenced compromise declaration, the asserted invalidity time, the frozen affected scope, the required actions with their owning external models, the reported outcomes and any mitigation evidence. It contains no key material and asserts no revocation of its own.", "media_or_form": [ "structured incident-linked record", "frozen scope list", "human-readable response summary" ], "serial": true, "identity_strategy": "Named by the referenced compromise declaration identifier plus the artifact kind plus a monotonic sequence; the external declaration identifier is carried verbatim as a field.", "source_refs": [ "SRC-043", "SRC-055", "SRC-077" ] } ], "inline_only_rationale": null }, { "id": "sig-gov-exception-expiry-rollback", "name": "Bounded acceptance exceptions, expiry and rollback", "description": "Records a time-boxed exception under which a proof that does not satisfy its pinned policy is nonetheless accepted for a stated and limited purpose - for example an INDETERMINATE outcome caused by unavailable revocation data, a stale revocation freshness constraint, or a method whose transition status has become verification-only. Every exception carries a mandatory expiry, a purpose limitation, a compensating condition, the approving authority and a defined rollback that restores the pre-exception governance state. An exception never alters the reported cryptographic outcome and never edits a pinned policy; it records a bounded governance tolerance of a known deficiency.", "source_refs": [ "SRC-061", "SRC-071", "SRC-076", "SRC-013" ], "questions": [ { "id": "sig-gov-q-exception-grounds", "text": "On what stated grounds may a proof failing its pinned policy be accepted, and for which purpose only?", "kind": "exception", "answer_data": [ "Exception ground code such as unavailable revocation data or deprecated method", "Purpose limitation naming the permitted use and excluded uses", "Reference to the reported outcome the exception tolerates", "Compensating condition required for the exception to stand" ] }, { "id": "sig-gov-q-exception-expiry", "text": "What mandatory expiry and re-evaluation point bound the exception?", "kind": "temporal", "answer_data": [ "Expiry timestamp in RFC 3339 with seconds and explicit offset", "Re-evaluation point or review cadence reference", "Behaviour on expiry when no re-evaluation has occurred" ] }, { "id": "sig-gov-q-exception-approver", "text": "Which authority approved the exception, and which roles were barred from approving it?", "kind": "authority", "answer_data": [ "Approving role reference and the basis of its authority", "Roles explicitly excluded from approving, including the requesting role", "Reference to the separation rule applied" ] }, { "id": "sig-gov-q-exception-rollback", "text": "What rollback restores the pre-exception governance state, and what evidence proves it happened?", "kind": "lifecycle", "answer_data": [ "Rollback condition and the resulting target state", "Rollback record reference with acting role and recorded-at time", "Statement that the reported cryptographic outcome is unchanged by rollback" ] } ], "data_elements": [ { "id": "sig-gov-de-exception-id", "name": "Exception identifier", "description": "Identifier of the bounded acceptance exception.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-071" ] }, { "id": "sig-gov-de-exception-ground-code", "name": "Exception ground code", "description": "Coded ground on which the exception was granted.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-gov-de-exception-expires-at", "name": "Exception expiry time", "description": "Mandatory expiry after which the exception no longer applies.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "sig-gov-de-exception-approver-ref", "name": "Exception approver reference", "description": "Reference to the role or party that approved the exception.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-071", "SRC-077" ] }, { "id": "sig-gov-de-rollback-condition", "name": "Rollback condition", "description": "Condition whose occurrence restores the pre-exception governance state.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "sig-gov-art-exception-record", "name": "Bounded acceptance exception record", "description": "An entry recording a time-boxed acceptance of a proof that does not satisfy its pinned policy, with ground, purpose limitation, compensating condition, approver, mandatory expiry and rollback condition. It never restates or amends the pinned policy.", "media_or_form": [ "structured exception entry", "expiring governance waiver note" ], "serial": true, "identity_strategy": "Named by the governed scope identifier plus the artifact kind plus a monotonic sequence; expiry is a field, never part of the name.", "source_refs": [ "SRC-061", "SRC-071", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-gov-accountability-controls", "name": "Accountability, Access Segregation and Evidentiary Retention", "description": "Who is accountable for what around a proof record, what evidences that governance decisions were reviewed, how the separable components of proof information are classified for disclosure, and how retention, legal hold, evidence preservation and tombstone references are bound to externally owned obligations.", "rationale": "Signature governance fails in two characteristic ways: one party silently accumulates signing authorization, key custody, verification-policy authority and legal-effect assessment; or public verifiability of a proof is taken to license access to the signed payload and the signer's identity attributes. Both failures are addressed by explicit role separation and independently classified disclosure. Retention is the third failure mode - a proof outlives the system that made it, so the evidence needed to revalidate it must be preserved by reference while disposition stays with the records authority.", "source_refs": [ "SRC-071", "SRC-004", "SRC-074", "SRC-075", "SRC-076", "SRC-077", "SRC-078", "SRC-072" ], "layers": [ { "id": "sig-gov-role-review", "name": "Role Separation and Review Evidence", "description": "The distinct accountable roles over a proof record, the combinations that must not be held by one party, and the documented review and approval that must precede a governance decision taking effect.", "source_refs": [ "SRC-061", "SRC-071", "SRC-055", "SRC-074", "SRC-077", "SRC-078" ], "findings": [ { "id": "sig-gov-role-separation-matrix", "name": "Governance role separation and prohibited combinations", "description": "Names the distinct accountable roles over a proof record and binds each to a party reference: responsible owner, signature-policy authority, signer or signing operator, verifier, trust administrator, cryptographic custodian, reviewer or auditor, records authority, and the external legal-effect assessor. The core prohibition is that no single party may simultaneously hold signing authorization, cryptographic key custody, verification-policy authority and legal-effect assessment for the same proof record. Where an adopting Dimension is too small to separate them, the conflict must be recorded explicitly with a compensating control rather than silently collapsed. Party identity attributes, credentials and authorization enforcement remain in the identity and access models.", "source_refs": [ "SRC-061", "SRC-071", "SRC-055", "SRC-074", "SRC-076", "SRC-077" ], "questions": [ { "id": "sig-gov-q-role-inventory", "text": "Which governance roles must be assigned for a proof record, and which are optional?", "kind": "ownership", "answer_data": [ "Role code list with mandatory or optional flag per role", "Scope of each role - per proof record, per policy scope or per Dimension", "Named external model that owns each role's operational duties" ] }, { "id": "sig-gov-q-role-holder-binding", "text": "How is each role bound to an accountable party without copying identity attributes into this model?", "kind": "identity", "answer_data": [ "Party reference resolvable in the external identity model", "Role code and binding effective interval", "Rule prohibiting local storage of identity attributes beyond the reference" ] }, { "id": "sig-gov-q-role-conflicts", "text": "Which role combinations are prohibited, and what compensating control applies when separation is not achievable?", "kind": "security", "answer_data": [ "Prohibited role-pair and role-set list", "Recorded conflict declaration when a prohibited combination exists", "Compensating control description and its approving role", "Re-evaluation point for the accepted conflict" ] }, { "id": "sig-gov-q-role-handover", "text": "Over what period did each role assignment hold, and what evidences a handover between holders?", "kind": "provenance", "answer_data": [ "Assignment start and end times in RFC 3339 with explicit offset", "Predecessor and successor party references", "Reference to the handover decision or approval record" ] } ], "data_elements": [ { "id": "sig-gov-de-role-code", "name": "Governance role code", "description": "Coded governance role over the proof record.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-061", "SRC-071" ] }, { "id": "sig-gov-de-role-holder-ref", "name": "Role holder reference", "description": "Reference to the party holding a role, resolved in the external identity model.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-074" ] }, { "id": "sig-gov-de-role-interval", "name": "Role assignment interval", "description": "Interval over which a role assignment held.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-074" ] }, { "id": "sig-gov-de-separation-rule-ref", "name": "Separation rule reference", "description": "Reference to the separation-of-duty rule applied to a role set.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-077", "SRC-055" ] }, { "id": "sig-gov-de-compensating-control", "name": "Compensating control statement", "description": "Control recorded when a prohibited role combination cannot be avoided.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-077" ] } ], "artifacts": [ { "id": "sig-gov-art-role-assignment-register", "name": "Signature governance role assignment register", "description": "A versioned register of role codes, party references, assignment intervals, declared conflicts and compensating controls for a governed scope. It holds references and intervals only; it is not an access-control policy and grants nothing.", "media_or_form": [ "structured register", "tabular assignment matrix", "human-readable accountability statement" ], "serial": false, "identity_strategy": "One current register per governed scope, identified by the scope identifier plus the artifact kind, with a monotonic version counter; superseded versions remain resolvable.", "source_refs": [ "SRC-071", "SRC-074", "SRC-077" ] } ], "inline_only_rationale": null }, { "id": "sig-gov-review-approval-evidence", "name": "Review and approval evidence for governance decisions", "description": "Evidence that a governance decision - a method change, a policy or anchor pin, a supersession, an exception grant, or the closure of a compromise response - was reviewed and approved by a competent and independent role before taking effect. Records the inputs that were before the reviewer at decision time, the decision code, any dissent or conditions, the recorded-at time and a reference to the corresponding entry in the externally owned audit trail. This is decision evidence held on the record plane; it is not the audit trail, which is captured, stored, queried and retained by the audit model.", "source_refs": [ "SRC-071", "SRC-074", "SRC-077", "SRC-078" ], "questions": [ { "id": "sig-gov-q-review-scope", "text": "Which governance decisions require documented review before they take effect?", "kind": "requirement", "answer_data": [ "Decision-type list with review-required flag", "Minimum reviewer role per decision type", "Effect of a missing review on the decision's effective status" ] }, { "id": "sig-gov-q-review-inputs", "text": "Which inputs and reports were before the reviewer at the moment of decision?", "kind": "evidence", "answer_data": [ "References to validation reports, scope lists and change records reviewed", "Version or digest of each input as it stood at decision time", "Statement of any input that was unavailable and why" ] }, { "id": "sig-gov-q-review-independence", "text": "What competence and independence criteria must the reviewer satisfy?", "kind": "quality", "answer_data": [ "Competence criteria reference and how it was evidenced", "Independence rule excluding the decision-maker from reviewing", "Recorded exception where independence could not be achieved" ] }, { "id": "sig-gov-q-review-audit-link", "text": "How is a review record linked to externally held audit entries without reproducing them?", "kind": "relationship", "answer_data": [ "Audit entry reference and the audit model that owns it", "Rule stating audit content and audit retention are not held here", "Reconciliation key allowing an auditor to match record and audit entry" ] } ], "data_elements": [ { "id": "sig-gov-de-review-decision-code", "name": "Review decision code", "description": "Coded outcome of the review, such as approved, approved with conditions, or rejected.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-074" ] }, { "id": "sig-gov-de-reviewer-role-ref", "name": "Reviewer role reference", "description": "Reference to the reviewing role and the party holding it.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-071", "SRC-077" ] }, { "id": "sig-gov-de-reviewed-input-refs", "name": "Reviewed input references", "description": "Collection of references, with versions or digests, to the inputs before the reviewer.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-075", "SRC-013" ] }, { "id": "sig-gov-de-decision-recorded-at", "name": "Decision recorded time", "description": "Time at which the decision was recorded, distinct from the time it takes effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-074" ] }, { "id": "sig-gov-de-audit-entry-ref", "name": "Audit entry reference", "description": "Reference to the corresponding entry in the externally owned audit model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-078" ] } ], "artifacts": [ { "id": "sig-gov-art-review-approval-record", "name": "Governance review and approval record", "description": "An entry evidencing that a named governance decision was reviewed by a competent, independent role, listing the reviewed inputs with versions, the decision code, conditions or dissent, and the audit entry reference. It duplicates no audit content.", "media_or_form": [ "structured review entry", "approval minute or note", "conditions and dissent annex" ], "serial": true, "identity_strategy": "Named by the decision subject identifier plus the artifact kind plus a monotonic sequence; the decision time is a field and never part of the name.", "source_refs": [ "SRC-074", "SRC-077", "SRC-078" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-gov-access-retention", "name": "Disclosure Segregation and Evidentiary Retention", "description": "Independent disclosure classes over the components of proof information, and the binding of a proof record to externally owned retention, legal hold, preservation and disposition obligations, ending in a tombstone reference.", "source_refs": [ "SRC-072", "SRC-004", "SRC-073", "SRC-074", "SRC-075", "SRC-076", "SRC-078" ], "findings": [ { "id": "sig-gov-disclosure-classes", "name": "Separable disclosure classes for proof information", "description": "Classifies the components of a proof record into independently governed disclosure classes: host content, signature or proof bytes, certificates and public keys, signer identity attributes, revocation and status evidence, and sensitive validation diagnostics. Public verifiability of a proof does not imply public access to the signed payload, and never implies access to signer identity attributes. Proof timing values and status endpoints can themselves leak information about a controller, so expiry and status references are classified in their own right. Diagnostics that reveal internal trust configuration, failure detail or scope lists are treated as sensitive by default. Each class is bound to an externally authored access policy; evaluation and enforcement occur in the access model.", "source_refs": [ "SRC-004", "SRC-073", "SRC-043", "SRC-074", "SRC-076", "SRC-013" ], "questions": [ { "id": "sig-gov-q-disclosure-inventory", "text": "Which components of a proof record are separately classifiable for disclosure?", "kind": "access", "answer_data": [ "Component inventory covering payload, proof bytes, certificates, signer attributes, revocation evidence and diagnostics", "Disclosure class code assigned to each component", "Default class applied to a component with no explicit assignment" ] }, { "id": "sig-gov-q-verifiability-vs-payload", "text": "What rule prevents public verifiability of a proof from implying access to the signed payload?", "kind": "privacy", "answer_data": [ "Explicit non-implication rule between proof-bytes access and host-content access", "Handling for detached versus embedded proofs", "Treatment of digests and canonical projections that could reveal payload content" ] }, { "id": "sig-gov-q-diagnostic-sensitivity", "text": "Which validation diagnostics are treated as sensitive, and on what stated ground?", "kind": "security", "answer_data": [ "Diagnostic categories marked sensitive with the ground for each", "Redaction or summarisation rule for released diagnostics", "Roles permitted to receive full diagnostics" ] }, { "id": "sig-gov-q-class-binding", "text": "How is a disclosure class bound to an externally enforced access policy without embedding that policy here?", "kind": "interoperability", "answer_data": [ "Access policy reference with its version and owning model", "Mapping from disclosure class code to policy scope", "Statement that evaluation and enforcement occur outside this model" ] } ], "data_elements": [ { "id": "sig-gov-de-disclosure-class-code", "name": "Disclosure class code", "description": "Coded disclosure class assigned to a component of the proof record.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-074" ] }, { "id": "sig-gov-de-classified-component-ref", "name": "Classified component reference", "description": "Reference to the proof-record component carrying a disclosure class.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-073" ] }, { "id": "sig-gov-de-access-policy-ref", "name": "Access policy reference", "description": "Reference to the externally authored access policy bound to a disclosure class.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "sig-gov-de-redaction-applied", "name": "Redaction applied flag", "description": "Indicates that a released component was redacted or summarised under its class rule.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-074" ] } ], "artifacts": [ { "id": "sig-gov-art-disclosure-classification-schedule", "name": "Signature disclosure classification schedule", "description": "A versioned schedule mapping each proof-record component to a disclosure class, the ground for that class and the external access policy reference bound to it. It states classification only and confers no grant.", "media_or_form": [ "structured classification schedule", "tabular component-to-class mapping", "human-readable disclosure statement" ], "serial": false, "identity_strategy": "One current schedule per governed scope, identified by the scope identifier plus the artifact kind, with a monotonic version counter; superseded versions remain resolvable for past releases.", "source_refs": [ "SRC-004", "SRC-074", "SRC-076" ] } ], "inline_only_rationale": null }, { "id": "sig-gov-retention-hold-tombstone", "name": "Retention, legal hold, evidence preservation and tombstone referencing", "description": "Binds a proof record to an externally owned retention schedule and to any legal hold or evidence-preservation order, states the obligation to preserve the evidence set needed to revalidate the proof after credential expiry - certificates, the revocation data current at signing, the trust path, trust verification records, policies and algorithm details, together with long-term validation material and archive time-stamps where an augmentation or preservation profile applies - and records a tombstone once disposition has been executed elsewhere. A proof record commonly outlives the system that produced it, so the preservation obligation is stated by reference to a preservation profile rather than by local copying. Physical erasure, backup expiry, audit-record retention and host-record deletion are executed and evidenced by the records, storage and audit models.", "source_refs": [ "SRC-072", "SRC-074", "SRC-075", "SRC-076", "SRC-013", "SRC-078" ], "questions": [ { "id": "sig-gov-q-retention-binding", "text": "Which retention schedule governs this proof record, and which authority issued that schedule?", "kind": "retention", "answer_data": [ "Retention schedule reference with version and issuing authority", "Retention trigger event and the computed disposition point", "Behaviour when no schedule resolves - retain and flag" ] }, { "id": "sig-gov-q-legal-hold", "text": "How is a legal hold or evidence-preservation order recorded, and what exactly does it suspend?", "kind": "constraint", "answer_data": [ "Hold reference, issuing authority and scope of records covered", "Hold start time and release condition or release time", "Explicit list of actions suspended, and the model that enforces the suspension" ] }, { "id": "sig-gov-q-evidence-set", "text": "Which validation evidence must be preserved so the proof remains verifiable after credential expiry?", "kind": "evidence", "answer_data": [ "Certificate chain, trust path and trust verification record references", "Revocation or status data current at signing, with its freshness at that time", "Time-stamp token and archive time-stamp references", "Preservation or augmentation profile reference defining the required set" ] }, { "id": "sig-gov-q-tombstone-content", "text": "What minimum information survives in a tombstone after the referenced record has been disposed of elsewhere?", "kind": "lifecycle", "answer_data": [ "Retained identifier and supersession links", "Disposition reason code and reported disposition time", "Authority reference that ordered and executed disposition", "Explicit exclusion of payload, proof bytes and signer identity attributes" ] }, { "id": "sig-gov-q-disposition-owner", "text": "Which model or party executes disposition, and what does this model record about that execution?", "kind": "ownership", "answer_data": [ "Owning records or storage model reference", "Executing party reference and its role code", "Reported disposition evidence reference", "Statement that this model performs no deletion itself" ] } ], "data_elements": [ { "id": "sig-gov-de-retention-schedule-ref", "name": "Retention schedule reference", "description": "Reference to the externally owned retention schedule governing the proof record.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-074", "SRC-078" ] }, { "id": "sig-gov-de-legal-hold-ref", "name": "Legal hold reference", "description": "Reference to a legal hold or evidence-preservation order covering the record.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-078" ] }, { "id": "sig-gov-de-preserved-evidence-ref", "name": "Preserved evidence set reference", "description": "Collection of references to the preserved validation evidence needed for later revalidation.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-075", "SRC-072", "SRC-013" ] }, { "id": "sig-gov-de-tombstone-id", "name": "Tombstone identifier", "description": "Identifier retained after the referenced record has been disposed of by the owning model.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-074" ] }, { "id": "sig-gov-de-disposition-reported-at", "name": "Disposition reported time", "description": "Time at which the executing model reported that disposition had occurred.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-078" ] } ], "artifacts": [ { "id": "sig-gov-art-retention-hold-register", "name": "Retention, hold and preservation binding register", "description": "A versioned register binding proof records to retention schedule references, legal hold references, preservation profile references and the preserved evidence set. It records obligations by reference and executes none of them.", "media_or_form": [ "structured binding register", "tabular hold and schedule listing", "preservation obligation statement" ], "serial": false, "identity_strategy": "One current register per governed scope, identified by the scope identifier plus the artifact kind, with a monotonic version counter.", "source_refs": [ "SRC-072", "SRC-074", "SRC-078" ] }, { "id": "sig-gov-art-proof-tombstone-entry", "name": "Proof tombstone entry", "description": "A minimal residual entry created after an external model reports disposition, retaining only the identifier, supersession links, disposition reason code, reported disposition time and authority reference. It carries no payload, no proof bytes and no signer identity attributes.", "media_or_form": [ "structured tombstone entry", "minimal residual reference record" ], "serial": true, "identity_strategy": "Named by the disposed proof record identifier plus the artifact kind plus a monotonic sequence; the identifier is retained verbatim so prior references continue to resolve.", "source_refs": [ "SRC-074", "SRC-078", "SRC-076" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-slayer-governance-bundle", "name": "Signature and Proof Service-Layer Governance", "description": "The governing operating contract for WM-XCT-034 records: who in the adopting Dimension owns the mixin, how the context record is namespaced and registered, what its canonical form and change semantics are, how artifacts obtain identity, time and integrity, how the record is projected across containers and interfaces without any projection becoming canonical, how access is scoped and exceptions bounded, and how an agent bootstraps into the model and fails closed when a reference will not resolve.", "rationale": "Signature and proof context is only useful if two independent parties reach the same bytes, the same identity and the same evidence pointers. The underlying standards make this unavoidable: canonical form is a prerequisite for any hash or signature and is itself an attack surface, envelope bytes must reach the consumer unaltered, key identifiers are hints rather than identities, and acceptance of an otherwise valid signature remains an application decision. A service-layer bundle is therefore load-bearing rather than administrative, and it must be written so that it governs description and hand-off only, never key custody, cryptographic execution, authority operation, enforcement or audit storage.", "source_refs": [ "SRC-004", "SRC-007", "SRC-008", "SRC-019", "SRC-021", "SRC-082" ], "layers": [ { "id": "sig-slayer-dimension-layer", "name": "Dimension Ownership, Namespace and Registry Binding", "description": "Establishes which adopting-Dimension owner package stewards WM-XCT-034 instances, which namespaces and registries the model's identifiers and vocabulary terms resolve into, and which external authorities are named as owners of everything this mixin deliberately does not execute.", "source_refs": [ "SRC-004", "SRC-055", "SRC-080", "SRC-050" ], "findings": [ { "id": "sig-slayer-owner-package-finding", "name": "Owner package, delegated authority and namespace binding", "description": "A WM-XCT-034 deployment is only governable when a single named owner package in the adopting Dimension is accountable for the mixin's configuration, and when every capability the mixin does not perform is bound by name and resolvable reference to the external system that does perform it. The specifications this model aligns with consistently push key management, trust establishment and acceptance policy outside their own boundary, so the owner package's principal duty is to declare those delegations rather than to reimplement them. The same package fixes the namespace under which local terms, vocabulary extensions and minted identifiers resolve, so that a term coined by one Dimension cannot silently collide with a governed IRI.", "source_refs": [ "SRC-004", "SRC-007", "SRC-008", "SRC-055", "SRC-050" ], "questions": [ { "id": "sig-slayer-q-owner-accountable", "text": "Which named owner package and steward role in the adopting Dimension is accountable for this WM-XCT-034 configuration, and how is that accountability reachable?", "kind": "ownership", "answer_data": [ "Owner package identifier and its authoritative master-system reference", "Steward role name and contactable channel, excluding personal contact details from open scopes", "Effective-from timestamp of the current ownership assignment", "Succession or escalation path when the steward is unavailable" ] }, { "id": "sig-slayer-q-delegated-authorities", "text": "Which external authorities are declared as owning key custody, signing authorization, cryptographic execution, certificate and trust-list operation, trusted time, audit storage, legal effect and retention enforcement?", "kind": "authority", "answer_data": [ "Delegation table mapping each excluded capability to a named external system", "Resolvable reference or endpoint identifier for each named system", "Assertion that this model holds no execution rights over the delegated capability", "Review interval and last-reviewed timestamp for the delegation table" ] }, { "id": "sig-slayer-q-namespace-required", "text": "What namespace and registry bindings must be declared before any local term, proof-purpose value or minted identifier is written into a record?", "kind": "requirement", "answer_data": [ "Base namespace IRI reserved for Dimension-local extension terms", "Registry entry identifier and record-plane binding for the model", "List of governed external vocabularies whose terms must be used unchanged rather than re-coined", "Collision-avoidance rule when a local term later gains a governed IRI" ] }, { "id": "sig-slayer-q-owner-change-decision", "text": "Who decides that an owner-package, namespace or delegation change has occurred, and what is recorded at the moment of that decision?", "kind": "decision", "answer_data": [ "Decision authority and approving role", "Prior and new owner-package or namespace values", "Decision timestamp and the observation timestamp at which dependent records were re-checked", "Impact statement listing records whose delegation references changed" ] } ], "data_elements": [ { "id": "sig-slayer-de-owner-package-ref", "name": "Owner package reference", "description": "Reference to the accountable owner package in the adopting Dimension, expressed as a master-system identifier or governed IRI.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-055" ] }, { "id": "sig-slayer-de-delegation-entry", "name": "Delegated authority entry", "description": "One entry naming an excluded capability, the external system that owns it, and the resolvable reference by which that system is reached.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-055" ] }, { "id": "sig-slayer-de-namespace-base", "name": "Local namespace base IRI", "description": "Base IRI under which Dimension-local extension terms and minted identifiers resolve.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-050" ] }, { "id": "sig-slayer-de-registry-binding", "name": "Registry binding", "description": "Registry identifier and record-plane binding that place this model instance in the adopting Dimension's catalogue.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "sig-slayer-af-owner-package-descriptor", "name": "Owner package descriptor", "description": "A declarative descriptor naming the accountable owner package and steward role, the local namespace base, the registry binding, and the full delegation table of capabilities this model does not execute together with the external systems that do.", "media_or_form": [ "structured record in any serialization", "human-readable governance document", "registry catalogue entry" ], "serial": false, "identity_strategy": "Identified by the owner package's authoritative master-system identifier where one exists; otherwise by a governed IRI under the declared local namespace base; a Dimension-minted ULID is used only when neither exists and is marked Dimension-local.", "source_refs": [ "SRC-055", "SRC-050", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-slayer-canon-layer", "name": "Canonical Form, Change Control and Compatibility", "description": "Defines the canonical byte form of a WM-XCT-034 context record independent of container, the atomic change semantics that may be applied to it, and the compatibility classes that distinguish a safe additive change from a breaking one.", "source_refs": [ "SRC-019", "SRC-021", "SRC-079", "SRC-008", "SRC-082" ], "findings": [ { "id": "sig-slayer-canonical-form-finding", "name": "Canonical form of the context record, distinct from cryptosuite canonicalization", "description": "Two canonicalizations exist and confusing them is the most common failure mode in this domain. The first is whatever transformation a cryptosuite or envelope applies to produce the bytes actually signed — a Sig_structure, a pre-authentication encoding, a JCS or RDFC-1.0 output — which is owned entirely by the referenced signature mechanism. The second is the canonical form of this model's own context record, needed so that digests, comparisons and hand-offs are reproducible. This finding fixes the second and forbids the model from asserting or recomputing the first. Both canonical forms must fail closed on inputs they cannot represent, and both must be bounded against adversarial inputs designed to make canonicalization expensive.", "source_refs": [ "SRC-019", "SRC-021", "SRC-008", "SRC-082", "SRC-004" ], "questions": [ { "id": "sig-slayer-q-canonical-definition", "text": "What exactly constitutes the canonical byte form of a WM-XCT-034 context record, and which algorithm identifier and version produced it?", "kind": "definition", "answer_data": [ "Canonicalization algorithm identifier and version, recorded as a governed IRI or registered name", "Input subset restrictions applied before canonicalization", "Resulting canonical octet sequence and its declared character encoding", "Digest algorithm identifier and digest value over the canonical octets" ] }, { "id": "sig-slayer-q-canonical-constraint", "text": "Which inputs must cause canonicalization to terminate with an error rather than to produce a repaired or approximated output?", "kind": "constraint", "answer_data": [ "Rejected constructs such as duplicate member names, non-representable numeric precision and invalid Unicode sequences", "Non-finite numeric values that must abort processing", "Complexity or work bound beyond which processing aborts as a suspected denial-of-service input", "Error identifier and the fail-closed disposition applied to the record" ] }, { "id": "sig-slayer-q-canonical-separation", "text": "How is the record's own canonical form kept separate from the canonicalization owned by the referenced cryptosuite or envelope?", "kind": "composition", "answer_data": [ "Reference to the cryptosuite or envelope canonicalization profile as an opaque declared value", "Assertion that the model neither recomputes nor substitutes the signed-bytes transformation", "Field-level marking of which stored octets are model-canonical and which are externally produced", "Failure behaviour when the two profiles are conflated in an incoming record" ] }, { "id": "sig-slayer-q-canonical-quality", "text": "What evidence shows that two independent implementations reach byte-identical canonical output for the same record?", "kind": "quality", "answer_data": [ "Reproducibility test-vector set and its version", "Digest agreement result across implementations with observation timestamp", "Known divergence cases and their disposition", "Implementation and library version identifiers used in the comparison" ] } ], "data_elements": [ { "id": "sig-slayer-de-canon-profile-id", "name": "Canonicalization profile identifier", "description": "Governed identifier and version of the algorithm used to produce the record's canonical byte form.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-021" ] }, { "id": "sig-slayer-de-canon-digest", "name": "Canonical digest", "description": "Digest algorithm identifier and digest value computed over the record's canonical octet sequence.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-081", "SRC-082" ] }, { "id": "sig-slayer-de-external-canon-ref", "name": "External signing canonicalization reference", "description": "Opaque reference to the canonicalization or pre-authentication encoding owned by the referenced cryptosuite or envelope, carried without recomputation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-082", "SRC-004" ] }, { "id": "sig-slayer-de-canon-abort-code", "name": "Canonicalization abort code", "description": "Identifier of the condition that caused canonicalization to terminate, recorded instead of a repaired output.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-021" ] } ], "artifacts": [ { "id": "sig-slayer-af-canonical-form-profile", "name": "Canonical form profile", "description": "A declaration binding this deployment to one canonicalization algorithm and version for the model's own records, listing rejected input constructs, the complexity bound at which processing aborts, the digest algorithm applied to the canonical octets, and an explicit statement that cryptosuite and envelope canonicalization remain externally owned.", "media_or_form": [ "profile declaration in any serialization", "specification section", "test-vector companion set" ], "serial": false, "identity_strategy": "Identified by the governed IRI or registered name of the canonicalization algorithm plus this deployment's profile version; never identified by publication date.", "source_refs": [ "SRC-019", "SRC-021", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "sig-slayer-change-control-finding", "name": "Change sets, preconditions and compatibility classes", "description": "A signature context record changes for reasons that are not edits to signed material: evidence is captured later, a status reference is re-checked, an augmentation level rises, a delegation target moves. Change control must therefore permit the record to evolve while guaranteeing that nothing purporting to be signed bytes is ever mutated in place. Changes are expressed as atomic operation sequences with explicit preconditions so that concurrent stewards cannot silently overwrite each other, and each change is classified against a compatibility ladder that treats a canonicalization-profile change, an identity-priority change or a binding change as breaking rather than routine.", "source_refs": [ "SRC-079", "SRC-082", "SRC-081", "SRC-004", "SRC-001" ], "questions": [ { "id": "sig-slayer-q-change-lifecycle", "text": "What are the permitted states of a WM-XCT-034 context record between initial capture and supersession, and which transitions require a recorded change set?", "kind": "lifecycle", "answer_data": [ "Enumerated record states such as draft, published, evidence-augmented, superseded and withdrawn", "Allowed transitions and the role authorized to request each", "Change-set reference attached to every non-trivial transition", "Supersession pointer to the replacing record identity" ] }, { "id": "sig-slayer-q-change-process", "text": "How is a change set expressed, precondition-checked and applied so that partial application cannot occur?", "kind": "process", "answer_data": [ "Ordered operation list using add, remove, replace, move, copy and test semantics", "Precondition test operations asserting the expected prior values", "All-or-nothing application outcome with rollback on any failed operation", "Prior and resulting canonical digests of the record" ] }, { "id": "sig-slayer-q-change-validation", "text": "Which changes are prohibited outright because they would alter material that is bound by an existing proof?", "kind": "validation", "answer_data": [ "Prohibited targets: stored proof octets, subject digests, protected parameters and pre-authentication inputs", "Required alternative of creating a new subject descriptor or a new attached proof rather than editing in place", "Detection rule comparing subject digests before and after a proposed change", "Rejection code and disposition for a prohibited change attempt" ] }, { "id": "sig-slayer-q-change-compatibility", "text": "How is a proposed change classified as additive, deprecating or breaking, and what must consumers be told in each case?", "kind": "classification", "answer_data": [ "Compatibility class assigned to the change", "Rule set mapping change kinds to classes, including canonicalization profile, identity priority and binding style as breaking", "Deprecation marker and superseding term for retired algorithm or vocabulary identifiers", "Consumer notification obligation and effective-from timestamp" ] } ], "data_elements": [ { "id": "sig-slayer-de-change-set-ops", "name": "Change set operation list", "description": "Ordered, atomically applied operation sequence describing a change to the context record, including precondition tests.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-079" ] }, { "id": "sig-slayer-de-change-prior-digest", "name": "Prior canonical digest", "description": "Canonical digest of the record immediately before the change set was applied, used as the concurrency precondition.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-079", "SRC-082" ] }, { "id": "sig-slayer-de-compat-class", "name": "Compatibility class", "description": "Classification of the change as additive, deprecating or breaking under the declared compatibility rules.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "sig-slayer-de-supersedes-ref", "name": "Supersession reference", "description": "Identity of the record or proof-context version superseded by the current one, where supersession rather than mutation was required.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-081", "SRC-004" ] } ], "artifacts": [ { "id": "sig-slayer-af-change-set-record", "name": "Change set record", "description": "A serially numbered record of one atomic change to a WM-XCT-034 context record, carrying the precondition tests, the ordered operations, the prior and resulting canonical digests, the assigned compatibility class, the requesting role and the RFC 3339 application time.", "media_or_form": [ "atomic operation document in any serialization", "version-control commit payload", "change ledger entry" ], "serial": true, "identity_strategy": "Identified by the parent record identity plus a monotonic per-record sequence number; the application timestamp is a field, never part of the identifier.", "source_refs": [ "SRC-079", "SRC-082" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-slayer-artifact-layer", "name": "Artifact Identity, Integrity and Time Discipline", "description": "Fixes how signature, proof and evidence artifacts obtain identity under a strict priority ladder, how their byte integrity is preserved end to end, and how the several distinct kinds of time attached to a proof are kept separate rather than collapsed into one field.", "source_refs": [ "SRC-007", "SRC-009", "SRC-081", "SRC-082", "SRC-083", "SRC-050" ], "findings": [ { "id": "sig-slayer-artifact-identity-finding", "name": "Identity priority and byte-fidelity integrity for proof and evidence artifacts", "description": "Signature domains offer many identifier-shaped values that are not identifiers: a key identifier is explicitly a hint for key selection, a digest is a content address that binds an attestation to an immutable subject, a serial number is unique only within its issuing authority, and a file name is a projection detail. Identity must therefore follow a strict ladder from authoritative master-system identifier through governed IRI to a Dimension-minted opaque identifier, with the minted case flagged as local. Integrity is equally strict: the octets handed to a consumer must be the octets whose digest was recorded, because re-parsing or re-serializing after verification is a known vulnerability class.", "source_refs": [ "SRC-007", "SRC-081", "SRC-082", "SRC-009", "SRC-050" ], "questions": [ { "id": "sig-slayer-q-identity-priority", "text": "Which identifier does a given signature, proof or evidence artifact carry, and at which rung of the identity priority ladder was it obtained?", "kind": "identity", "answer_data": [ "Authoritative master-system identifier and the naming system of record that issued it", "Governed global identifier or IRI where no master-system identifier exists", "Dimension-minted ULID or UUID with an explicit local-only marker", "Rung indicator recording which of the three applied and why the higher rungs were unavailable" ] }, { "id": "sig-slayer-q-identity-non-identifiers", "text": "Which accompanying values are recorded as hints or content addresses and must never be promoted to identity?", "kind": "classification", "answer_data": [ "Key identifier hints carried for key selection only", "Digest algorithm and value recorded as a content address and subject binding", "Authority-scoped serial numbers qualified by their issuing authority", "Container file names, paths and version labels marked as projection detail" ] }, { "id": "sig-slayer-q-integrity-evidence", "text": "What evidence demonstrates that stored proof octets and referenced evidence octets were not altered between capture and delivery?", "kind": "evidence", "answer_data": [ "Digest algorithm identifier and digest value over the exact stored octets", "Canonicalization profile or explicit opaque-octet marking for each stored value", "Comparison outcome at read time with observation timestamp", "Fail-closed disposition applied on digest mismatch" ] }, { "id": "sig-slayer-q-identity-provenance", "text": "Where did each artifact and its identifier come from, and which system remains its system of record?", "kind": "provenance", "answer_data": [ "Producing or issuing system reference", "Capture method such as direct receipt, mirrored copy or transcribed reference", "System of record retained for the artifact after capture", "Ingestion timestamp distinct from any time asserted inside the artifact" ] } ], "data_elements": [ { "id": "sig-slayer-de-artifact-identity", "name": "Artifact identity", "description": "The identifier assigned to a signature, proof or evidence artifact together with the priority rung at which it was obtained.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-081", "SRC-050" ] }, { "id": "sig-slayer-de-artifact-digest", "name": "Artifact digest binding", "description": "Digest algorithm identifier and value over the exact stored octets, used as content address and integrity check rather than identity.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-081", "SRC-082" ] }, { "id": "sig-slayer-de-key-hint", "name": "Key selection hint", "description": "Key identifier or thumbprint carried to assist key selection, explicitly marked as a hint and not as signer identity.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-slayer-de-system-of-record", "name": "System of record reference", "description": "Reference to the system that issued or retains authority over the artifact after capture.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-080" ] } ], "artifacts": [ { "id": "sig-slayer-af-artifact-descriptor", "name": "Signature and evidence artifact descriptor", "description": "A resource descriptor for one stored or referenced artifact — proof octets, time-stamp token, status response, inclusion proof or credential chain — carrying its identity, priority rung, digest binding, media form, opaque-octet marking, producing system and ingestion time, without reproducing the artifact's own issuing semantics.", "media_or_form": [ "resource descriptor record in any serialization", "attachment manifest entry", "catalogue row referencing external storage" ], "serial": false, "identity_strategy": "Master-system identifier from the issuing system first; otherwise a governed IRI; otherwise a Dimension-minted ULID marked local. Digests bind content but never serve as identity, and no date component appears in the identifier.", "source_refs": [ "SRC-081", "SRC-082", "SRC-009", "SRC-069" ] } ], "inline_only_rationale": null }, { "id": "sig-slayer-time-discipline-finding", "name": "Separation of signer-claimed time, trusted evidence time and observation time", "description": "A proof carries at least three unrelated kinds of time and merging them destroys the evidentiary value of all three. Signer-claimed time is an assertion inside the signed material and provides no assurance on its own unless its accuracy can independently be trusted; trusted evidence time is asserted by an external authority that attests only that a datum existed at a point in time, with its own policy, granularity and accuracy claim; observation or ingestion time is the adopting Dimension's own record of when it captured or last re-checked the material. This model records all three distinctly, preserves each authority's accuracy claim rather than rounding it away, and never computes a derived best time on its own authority.", "source_refs": [ "SRC-009", "SRC-083", "SRC-004", "SRC-080", "SRC-073" ], "questions": [ { "id": "sig-slayer-q-time-kinds", "text": "Which distinct time values are attached to this proof context, and which party asserted each one?", "kind": "temporal", "answer_data": [ "Signer-claimed signing time and any proof creation or expiry value as asserted", "Trusted evidence time from an external time-stamp token with its issuing authority and policy reference", "Dimension observation or ingestion time and last re-check time", "Assertion of which party is the source of each value" ] }, { "id": "sig-slayer-q-time-format-state", "text": "In what form is each recorded time stored so that offset, precision and accuracy are not lost?", "kind": "state", "answer_data": [ "RFC 3339 date-time with explicit seconds and explicit numeric offset or Z", "Rejection state for date-only, local-time-only or implied-zone values", "Accuracy or granularity claim preserved alongside the value rather than folded into it", "Ordering flag indicating whether values from one authority may be ordered by time alone" ] }, { "id": "sig-slayer-q-time-event-capture", "text": "Which events cause a new time value to be recorded rather than an existing one to be updated?", "kind": "event", "answer_data": [ "Evidence capture event and its ingestion time", "Status re-check event and its observation time", "Augmentation event that adds later evidence to an existing proof", "Rule forbidding in-place overwrite of a previously recorded time" ] }, { "id": "sig-slayer-q-time-measurement-limits", "text": "What are the declared limits on the precision and comparability of the recorded times, and who owns any authoritative time determination?", "kind": "measurement", "answer_data": [ "Declared precision of each time source", "Stated non-comparability between claimed time and authority-asserted time", "External system named as owner of any authoritative time determination", "Explicit statement that this model derives no authoritative time of its own" ] } ], "data_elements": [ { "id": "sig-slayer-de-claimed-time", "name": "Signer-claimed time", "description": "Time asserted by or on behalf of the signer, including proof creation and expiry values, recorded as a claim without assurance.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-083" ] }, { "id": "sig-slayer-de-evidence-time", "name": "Trusted evidence time reference", "description": "Reference to an externally asserted time value with its issuing authority, policy identifier, granularity and accuracy claim, carried without recomputation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-073" ] }, { "id": "sig-slayer-de-observation-time", "name": "Observation or ingestion time", "description": "Time at which the adopting Dimension captured, or last re-checked, the proof context or its evidence.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-080", "SRC-009" ] }, { "id": "sig-slayer-de-time-accuracy", "name": "Time accuracy claim", "description": "Accuracy or deviation claim published with an authority-asserted time, preserved alongside the value.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Time discipline is carried entirely as inline field-level values and constraints on the context record, plus references to time evidence that other systems own. The artifacts that could carry authoritative time — time-stamp tokens, signed tree heads, status responses — are produced, signed and retained by external authorities under their own policies, and this model must reference them rather than mint, wrap or reissue them. Declaring a local time artifact here would create a second, unsigned copy of an authority's assertion and would implicitly claim time-determination semantics that the boundary explicitly assigns elsewhere." } ] }, { "id": "sig-slayer-operations-layer", "name": "Scoped Access, Roles and Agent Bootstrap", "description": "Governs who may read or propose changes to which scope of a WM-XCT-034 record, how narrowly bounded exceptions are shaped, and how an agent enters the model through a mandatory AGENTS.md contract that fails closed and reports projection losses across every container and interface.", "source_refs": [ "SRC-007", "SRC-008", "SRC-073", "SRC-080", "SRC-082" ], "findings": [ { "id": "sig-slayer-access-scope-finding", "name": "Scope-differentiated access and bounded exceptions", "description": "A signature context record is not uniformly sensitive. Public credential material and algorithm identifiers are often intended to be widely readable; the secured payload may be confidential; identity attributes about a claimed signer are personal data; status and diagnostic material can leak organizational structure and verification behaviour; and unprotected header parameters are attacker-influenceable and must never be treated as authoritative merely because they arrived with a valid record. Access is therefore declared per scope — bundle, layer, finding and artifact — with distinct treatment for payload, proof octets, public credential material, identity attributes, status evidence and diagnostics. Exceptions exist but must be explicit, time-boxed and reviewable; issuing, enforcing and recording their use is the adopting Dimension's job, not this model's.", "source_refs": [ "SRC-007", "SRC-008", "SRC-073", "SRC-004", "SRC-080" ], "questions": [ { "id": "sig-slayer-q-access-scope", "text": "Which access class applies to each scope and material category within a WM-XCT-034 record?", "kind": "access", "answer_data": [ "Scope indicator of bundle, layer, finding or artifact", "Material category such as payload, proof octets, public credential material, identity attributes, status evidence or diagnostics", "Access class assigned to each scope and category pair", "Roles permitted to read and roles permitted to propose change for that pair" ] }, { "id": "sig-slayer-q-access-exception", "text": "On what terms may an exception widen access beyond the default, and how does it end?", "kind": "exception", "answer_data": [ "Exception identifier, requesting role and stated purpose", "Exact scopes and material categories widened", "Expiry timestamp with explicit offset and a maximum permitted duration", "Reference to the external system that issues, enforces and records use of the exception" ] }, { "id": "sig-slayer-q-access-privacy", "text": "Which elements of a proof context are treated as personal or linkable data requiring minimization before disclosure?", "kind": "privacy", "answer_data": [ "Identity attributes about a claimed signer, including names, roles and contact values", "Correlatable values such as stable key identifiers, serial numbers and unblinded nonces", "Minimization or redaction rule applied per disclosure scope", "Statement of which linkability risks remain after minimization" ] }, { "id": "sig-slayer-q-access-security-trust", "text": "Which parameters must never be trusted for an access or acceptance decision merely because they accompany the record?", "kind": "security", "answer_data": [ "Unprotected header parameters marked as non-integrity-protected", "Algorithm identifiers requiring separate policy acceptance even when the signature verifies", "Unrecognized critical parameters that must cause fail-closed rejection", "External reference targets requiring integrity-protected retrieval before use" ] } ], "data_elements": [ { "id": "sig-slayer-de-scope-class", "name": "Scope access classification", "description": "Assignment of an access class to a scope and material-category pair within the record.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-073", "SRC-080" ] }, { "id": "sig-slayer-de-exception-grant-ref", "name": "Exception reference", "description": "Reference to an externally issued, time-boxed exception widening access, with its expiry and issuing system.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-080" ] }, { "id": "sig-slayer-de-protection-marking", "name": "Parameter protection marking", "description": "Marking of each carried parameter as integrity-protected or unprotected, so that unprotected values are never relied upon.", "value_kind": "boolean", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-slayer-de-minimization-rule", "name": "Minimization rule reference", "description": "Reference to the redaction or minimization rule applied to identity attributes and correlatable values before disclosure at a given scope.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Access here is declarative context: a scope-to-class mapping, protection markings on carried parameters and pointers to exceptions that some other system issued. Producing a local grant, decision or usage artifact would mean minting an access-control record and, with it, evaluation, enforcement and audit-trail semantics that the boundary assigns to the adopting Dimension's access and audit systems. The correct representation is therefore inline classification plus outbound references, so that the authoritative grant and its usage trail remain single-sourced in the system that can actually enforce them." }, { "id": "sig-slayer-bootstrap-projection-finding", "name": "AGENTS.md bootstrap contract and format-neutral projection binding", "description": "An agent must be able to enter a WM-XCT-034 deployment without prior knowledge of its container. A single mandatory AGENTS.md bootstrap record names the model, its kind, and the resolvable specification, storage-type, interface and process references, together with the registry identifier and the accountable owner. Because the same semantics may be projected into Git trees, plain files, an MCP interface, a document database or an embedded signature binding, and because each of those loses something — key ordering, byte fidelity, numeric precision, attachment linkage, opaque-octet handling — no projection is canonical and every projection must publish what it lost. Resolution is strictly ordered and fails closed: if a declared reference cannot be resolved or its integrity cannot be established, the agent stops rather than proceeding on partial context.", "source_refs": [ "SRC-082", "SRC-019", "SRC-007", "SRC-073", "SRC-008", "SRC-080" ], "questions": [ { "id": "sig-slayer-q-bootstrap-fields", "text": "Which fields must the AGENTS.md bootstrap record carry before an agent may act on a WM-XCT-034 deployment?", "kind": "requirement", "answer_data": [ "Name and Type of the model as deployed", "Specification URL, Storage type URL, Interface URL and Processes URL as resolvable references", "Registry ID binding the deployment to its catalogue entry", "Owner naming the accountable owner package or steward role" ] }, { "id": "sig-slayer-q-bootstrap-process", "text": "In what order are bootstrap references resolved, and what happens when one of them cannot be resolved or verified?", "kind": "process", "answer_data": [ "Ordered resolution sequence across the declared references", "Integrity condition required before a resolved reference is used", "Fail-closed halt with an unresolved-reference code and the scope withheld", "Prohibition on substituting cached, inferred or default values for an unresolved reference" ] }, { "id": "sig-slayer-q-projection-losses", "text": "Which fidelity losses does each supported projection introduce, and how are they reported to a consumer?", "kind": "interoperability", "answer_data": [ "Projection target such as version-controlled files, plain files, document database, tool interface or embedded signature binding", "Enumerated losses including member ordering, byte fidelity, numeric precision, attachment linkage and opaque-octet handling", "Loss report reference attached to the projected output", "Round-trip digest comparison result against the canonical form" ] }, { "id": "sig-slayer-q-projection-relationship", "text": "What is the relationship between a projection, the canonical record and the host record that the mixin is attached to?", "kind": "relationship", "answer_data": [ "Assertion that no container, database or interface is canonical", "Pointer from each projection to the canonical form and its digest", "Attachment relationship to the host record and the subject descriptors that bind them", "Handling rule for embedded versus detached carriage of the same proof context" ] }, { "id": "sig-slayer-q-bootstrap-retention", "text": "How long is a bootstrap record and its projection loss report kept, and which policy governs their disposition?", "kind": "retention", "answer_data": [ "Retention class assigned to bootstrap and loss-report material", "Named external retention policy that governs disposition", "Tombstone content retained after disposition, limited to identity and disposition reference", "External system responsible for executing physical deletion" ] } ], "data_elements": [ { "id": "sig-slayer-de-bootstrap-field", "name": "Bootstrap field entry", "description": "One required AGENTS.md field with its literal name and its resolvable value.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-080", "SRC-007" ] }, { "id": "sig-slayer-de-resolution-order", "name": "Resolution order position", "description": "Ordinal position of a reference in the mandatory bootstrap resolution sequence.", "value_kind": "number", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "sig-slayer-de-projection-target", "name": "Projection target", "description": "Identifier of the container, database, interface or signature binding into which the record is projected.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-073", "SRC-082" ] }, { "id": "sig-slayer-de-projection-loss", "name": "Projection loss entry", "description": "One declared fidelity loss introduced by a projection, with the affected element class and its consequence for reproducibility.", "value_kind": "object", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-019", "SRC-082" ] }, { "id": "sig-slayer-de-unresolved-code", "name": "Unresolved reference code", "description": "Code recorded when a bootstrap reference cannot be resolved or its integrity cannot be established, triggering a fail-closed halt.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-080" ] } ], "artifacts": [ { "id": "sig-slayer-af-agents-bootstrap-descriptor", "name": "AGENTS.md bootstrap descriptor", "description": "The mandatory entry-point record carrying Name, Type, Specification URL, Storage type URL, Interface URL, Processes URL, Registry ID and Owner, together with the ordered resolution sequence and the fail-closed rule that halts an agent when any declared reference cannot be resolved or integrity-checked.", "media_or_form": [ "AGENTS.md document", "equivalent bootstrap record exposed through a database collection or tool interface" ], "serial": false, "identity_strategy": "Identified by the deployment's registry identifier as recorded in the Registry ID field, qualified by the owner package reference; the file name AGENTS.md is a projection convention and is not the identifier.", "source_refs": [ "SRC-080", "SRC-007", "SRC-073" ] }, { "id": "sig-slayer-af-projection-loss-report", "name": "Projection loss report", "description": "A serially numbered report accompanying one projection of a WM-XCT-034 record into a specific container or interface, enumerating fidelity losses, the round-trip digest comparison against the canonical form, and the elements that must be re-read from the canonical source rather than from the projection.", "media_or_form": [ "report record in any serialization", "build or export log entry", "interface response envelope field" ], "serial": true, "identity_strategy": "Identified by the projected record identity plus the projection target identifier plus a monotonic per-target sequence number; no date component appears in the identifier.", "source_refs": [ "SRC-019", "SRC-082", "SRC-021" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-prep-request-construction", "name": "Proof Request Construction and Executor Handoff", "description": "Everything needed to read the current or historical proof state of a host record, build an exact and immutable protected signing input, pin the proof configuration and context, and hand a correlated, expiring request to an external signing or proving executor without exposing anything mutable or secret.", "rationale": "Signature and proof specifications converge on one requirement: signer and verifier must independently arrive at byte-identical protected input, and that input must fix the algorithm, the key reference and the context before any private key is touched. RFC 7515 fixes the JWS Signing Input, RFC 9052 fixes the Sig_structure, RFC 9421 fixes the signature base, and W3C Data Integrity fixes the proof configuration before proof serialization. Remote-signing and time-stamping protocols show the correct handoff shape: pin a digest, correlate the request, bound its validity, and let the key stay where it is.", "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-008", "SRC-019", "SRC-009", "SRC-087" ], "layers": [ { "id": "sig-prep-read-surface", "name": "Proof State Read and As-Of Projection", "description": "How callers observe which proofs are attached to a host record, how an explicit historical projection differs from the current one, and the rule that neither proof presence nor a stored verification observation is a statement of current validity.", "source_refs": [ "SRC-084", "SRC-005", "SRC-088" ], "findings": [ { "id": "sig-prep-state-projection", "name": "Current and as-of projections of attached proof state", "description": "A read returns the proof descriptors attached to a host record, either as at the read instant or as at an explicitly supplied historical point. The projection states which host version each proof commits to, whether the set is complete or access-filtered, and — for chains — the asserted order. The as-of basis (event time or observation time) is supplied by the caller and never inferred, because a proof's asserted creation instant and the instant the system observed it can differ.", "source_refs": [ "SRC-084", "SRC-085", "SRC-005", "SRC-088" ], "questions": [ { "id": "sig-prep-q-current-set", "text": "Which proofs are attached to the host record version that is current at read time, and which host version does each proof commit to?", "kind": "state", "answer_data": [ "current host version identifier", "ordered list of attached proof descriptor identifiers", "per-proof pinned payload digest and digest algorithm", "per-proof securing mechanism code" ] }, { "id": "sig-prep-q-asof-basis", "text": "What as-of instant does a historical projection use, and is it evaluated against event time or against observation time?", "kind": "temporal", "answer_data": [ "as-of instant as RFC 3339 with seconds and explicit offset", "as-of basis code (event time or observation time)", "resolved host version identifier at that point", "clock source reference and permitted skew" ] }, { "id": "sig-prep-q-projection-completeness", "text": "Does the returned projection represent the complete proof set or an access-filtered subset?", "kind": "access", "answer_data": [ "completeness flag", "applied scope or filter identifier", "count of withheld proof descriptors", "withholding reason code" ] }, { "id": "sig-prep-q-chain-order", "text": "For a proof chain, what ordering does the projection assert and which proof does each entry name as its predecessor?", "kind": "composition", "answer_data": [ "previous-proof reference per entry", "chain position ordinal", "set-or-chain code", "chain continuity flag" ] }, { "id": "sig-prep-q-read-determinism", "text": "Is the projection reproducible for the same as-of input, and what marker makes it reproducible?", "kind": "quality", "answer_data": [ "read consistency token or entity-tag", "projection snapshot identifier", "reproducibility flag" ] } ], "data_elements": [ { "id": "sig-prep-de-host-version-ref", "name": "Host version reference", "description": "Immutable, digest-addressable reference to the exact host record version the projection resolved to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-084" ] }, { "id": "sig-prep-de-asof-instant", "name": "As-of instant", "description": "Caller-supplied historical point for the projection, expressed as an RFC 3339 date-time with seconds and an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-088" ] }, { "id": "sig-prep-de-asof-basis", "name": "As-of basis code", "description": "Explicit statement of whether the as-of instant is evaluated against asserted event time or against system observation time. Never defaulted silently.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-088", "SRC-022" ] }, { "id": "sig-prep-de-read-consistency-token", "name": "Read consistency token", "description": "Opaque validator identifying the exact represented state, usable as the expected-version precondition on a subsequent mutation.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-085" ] }, { "id": "sig-prep-de-projection-completeness", "name": "Projection completeness flag", "description": "Indicates whether the returned proof set is complete or was reduced by the caller's access scope, with a count of withheld entries.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "A projection is a derived read view computed over host versions and already-stored proof descriptors. It holds no octets of its own and is never persisted as a signed or addressable object, so materialising it as an artifact would create a second, drift-prone copy of state whose authority is unclear. It is therefore expressed purely as inline reference data: host version reference, as-of instant and basis, consistency token and completeness flags." }, { "id": "sig-prep-non-inference", "name": "Proof presence and prior verification are not current validity", "description": "The rule set preventing the most common misuse of this mixin. An attached proof asserts only that some party produced a proof over a specific protected input using a specific method; it asserts nothing about the truth of the host content, the current standing of the signer, or the acceptability of the record to any relying party. A stored verification result is an observation bound to the instant and inputs at which it was taken, and is invalidated for reuse when any pinned input changes.", "source_refs": [ "SRC-084", "SRC-022", "SRC-005" ], "questions": [ { "id": "sig-prep-q-presence-meaning", "text": "What exactly does the presence of an attached proof assert, and what does it deliberately not assert?", "kind": "definition", "answer_data": [ "assertion scope statement", "explicit list of excluded assertions", "securing mechanism reference", "proof purpose value" ] }, { "id": "sig-prep-q-prior-result-status", "text": "Is a stored verification result an assertion about the present or an observation bound to the instant and inputs at which it was made?", "kind": "evidence", "answer_data": [ "observation instant as RFC 3339 with offset", "inputs pinned at observation", "observing party reference", "explicit not-current marker" ] }, { "id": "sig-prep-q-revalidation-trigger", "text": "Which changes to pinned inputs invalidate reuse of a prior verification observation?", "kind": "constraint", "answer_data": [ "list of pins whose change forces revalidation", "changed pin identifiers", "revalidation-required flag" ] }, { "id": "sig-prep-q-consumer-obligation", "text": "What must a consumer independently evaluate before relying on a proof-bearing record?", "kind": "decision", "answer_data": [ "relying-party policy reference", "required independent check list", "reliance decision owner reference" ] } ], "data_elements": [ { "id": "sig-prep-de-assertion-scope", "name": "Proof assertion scope statement", "description": "Machine-readable statement of what the attached proof covers and what it explicitly does not cover, carried alongside the descriptor.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "sig-prep-de-observation-instant", "name": "Verification observation instant", "description": "The instant at which a verification result was observed and recorded, distinct from the proof's asserted creation instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-088", "SRC-084" ] }, { "id": "sig-prep-de-not-current-marker", "name": "Non-current evidence marker", "description": "Flag forcing consumers to treat a stored verification result as historical evidence rather than as present-tense validity.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "sig-prep-de-revalidation-trigger-set", "name": "Revalidation trigger set", "description": "Enumerated pins (payload version, algorithm, verification method, context bindings, expiry) whose change makes a prior observation unusable.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "This finding is a normative interpretation rule attached to every read and to every stored verification observation. It produces no object of its own: it constrains how existing descriptors and observations are labelled and consumed. Expressing it as inline flags and scope statements keeps the rule inseparable from the data it governs, whereas a separate artifact could be fetched, cached or ignored independently of the proof it qualifies." } ] }, { "id": "sig-prep-protected-input", "name": "Protected Signing Input and Pinned Proof Configuration", "description": "Construction of the exact octets or digest the executor will operate on, and the pinned configuration — algorithm, parameters, verification method, purpose, context and policy — that the protected input must itself cover.", "source_refs": [ "SRC-084", "SRC-007", "SRC-008", "SRC-019", "SRC-089" ], "findings": [ { "id": "sig-prep-payload-pin", "name": "Exact payload version pin and protected input construction", "description": "Preparation resolves the host payload to one immutable, content-addressed version, applies a named and versioned deterministic transformation, and records the resulting protected input octets or their digest with the digest algorithm and length. The recorded value is the sole thing the executor may operate on. At attachment the protected input is recomputed from the same pinned version and must be byte-identical, which is what detects time-of-check-to-time-of-use drift.", "source_refs": [ "SRC-084", "SRC-007", "SRC-008", "SRC-019", "SRC-009" ], "questions": [ { "id": "sig-prep-q-input-bytes", "text": "What exact octet sequence or digest constitutes the protected signing input handed to the executor?", "kind": "measurement", "answer_data": [ "protected input octets or digest value", "digest algorithm identifier or OID", "digest length in octets", "encoding of the transmitted value" ] }, { "id": "sig-prep-q-transform", "text": "Which canonicalization or transformation profile produced the protected input, and can an independent verifier reproduce it?", "kind": "interoperability", "answer_data": [ "transformation profile identifier", "profile version", "determinism assertion", "reproduction procedure reference" ] }, { "id": "sig-prep-q-payload-version", "text": "Which immutable host payload version does the protected input pin, and how is that version identified?", "kind": "identity", "answer_data": [ "payload version identifier", "content digest of that version", "immutability assertion", "master system of record reference" ] }, { "id": "sig-prep-q-detached-scope", "text": "Is the payload detached, enveloped or embedded, and what externally supplied context is folded into the protected input?", "kind": "classification", "answer_data": [ "payload attachment mode code", "external additional authenticated data value", "covered component list", "digest-only disclosure flag" ] }, { "id": "sig-prep-q-input-drift", "text": "How is drift between the prepared protected input and the host record at attachment time detected and handled?", "kind": "validation", "answer_data": [ "recomputed protected input digest at attachment", "byte-identity comparison outcome", "drift refusal reason code" ] } ], "data_elements": [ { "id": "sig-prep-de-protected-input", "name": "Protected signing input", "description": "The exact octet sequence the proof commits to, constructed once at preparation and never regenerated by a different path.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008", "SRC-022" ] }, { "id": "sig-prep-de-input-digest", "name": "Protected input digest", "description": "Digest of the protected signing input, used as the value transmitted when only a digest is disclosed and as the comparison value at attachment.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-087" ] }, { "id": "sig-prep-de-digest-algorithm", "name": "Digest algorithm identifier", "description": "Identifier or OID of the hash function producing the protected input digest, pinned so the executor cannot substitute another.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-087", "SRC-009" ] }, { "id": "sig-prep-de-transform-profile", "name": "Transformation profile identifier and version", "description": "Named, versioned canonicalization or signature-base construction profile; unnamed or unversioned profiles are refused at preparation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-022", "SRC-084" ] }, { "id": "sig-prep-de-covered-components", "name": "Covered component list", "description": "Ordered enumeration of the components or pointers included in the protected input, including any externally supplied context.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-022", "SRC-008", "SRC-089" ] } ], "artifacts": [ { "id": "sig-prep-signing-input-manifest", "name": "Protected Signing Input Manifest", "description": "Immutable record produced by preparation holding the protected input or its digest, the digest algorithm and length, the transformation profile and version, the pinned host payload version, the covered component list and any external additional authenticated data. It is re-read and recomputed against at attachment; never edited after creation, only superseded.", "media_or_form": [ "structured record", "octet string or digest value", "ordered covered-component list" ], "serial": true, "identity_strategy": "Primary identifier is the authoritative master-system identifier assigned by the adopting Dimension's proof-request store; where that store is not the master, the executor's own request identifier is used. Failing both, a UUID or ULID is minted at preparation. The protected input digest is recorded as an integrity check value and correlation aid and is never the primary identifier; no instant or version label is used as an identifier.", "source_refs": [ "SRC-084", "SRC-007", "SRC-008", "SRC-019", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "sig-prep-proof-options", "name": "Pinned proof configuration: algorithm, method, purpose, context and policy", "description": "The configuration the request fixes before any key is touched: the algorithm or cryptosuite and its parameters, the verification-method or credential reference that will validate the result, the proof purpose and the verification relationship it must match, the context bindings scoping the proof to one audience and occasion, and the policy and profile versions in force. Wherever the securing mechanism allows, this configuration is itself covered by the protected input, so a returned proof cannot silently claim a different algorithm or key.", "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-008", "SRC-087", "SRC-089" ], "questions": [ { "id": "sig-prep-q-algorithm-pin", "text": "Which algorithm or cryptosuite and which parameter set are pinned, and are they covered by the protected input?", "kind": "requirement", "answer_data": [ "algorithm or cryptosuite identifier", "algorithm parameter set", "protected-coverage flag", "allow-list entry reference" ] }, { "id": "sig-prep-q-verification-method", "text": "Which verification-method, key identifier or credential identifier is pinned, and does it resolve to exactly one key?", "kind": "relationship", "answer_data": [ "verification method URL or opaque key identifier", "credential identifier", "identifier scheme reference", "unique-resolution flag" ] }, { "id": "sig-prep-q-proof-purpose", "text": "What proof purpose is asserted, and does it match the verification relationship the pinned method is authorised for?", "kind": "authority", "answer_data": [ "proof purpose value", "expected verification relationship", "match assertion", "controller reference" ] }, { "id": "sig-prep-q-context-audience", "text": "Which security domain, audience, challenge or presentation header binds this proof to its intended context and occasion?", "kind": "security", "answer_data": [ "domain or audience value", "challenge or nonce value", "presentation header octets", "context binding coverage flag" ] }, { "id": "sig-prep-q-policy-pins", "text": "Which policy and profile versions are pinned so that executor and verifier evaluate the same rules?", "kind": "provenance", "answer_data": [ "policy identifier and version", "signature profile or level identifier", "allow-list snapshot reference", "pin capture instant" ] } ], "data_elements": [ { "id": "sig-prep-de-algorithm-id", "name": "Algorithm or cryptosuite identifier", "description": "Governed identifier of the signature or proof suite to be used, drawn unchanged from the registry that governs it.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-084", "SRC-007", "SRC-008", "SRC-001" ] }, { "id": "sig-prep-de-algorithm-params", "name": "Algorithm parameter set", "description": "Parameters accompanying the algorithm (curve, padding scheme, hash pairing, feature option), fixed at preparation and immutable thereafter.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-087", "SRC-089" ] }, { "id": "sig-prep-de-verification-method-ref", "name": "Verification method reference", "description": "Pinned reference to the verification method, key identifier or credential identifier a verifier will use, carrying the scheme that governs it. Never accompanied by key material.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-087" ] }, { "id": "sig-prep-de-proof-purpose", "name": "Proof purpose", "description": "The declared purpose of the proof, which must match the verification relationship the pinned method is authorised for.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-084" ] }, { "id": "sig-prep-de-context-binding", "name": "Context binding set", "description": "Domain or audience, challenge or nonce, tag and presentation header values that scope the proof to one context and occasion.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-084", "SRC-022", "SRC-008", "SRC-089" ] }, { "id": "sig-prep-de-policy-pin", "name": "Policy and profile pin", "description": "Identifier and version of the signature policy, profile or level in force at preparation, captured so later evaluation uses the same rules.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-087", "SRC-084" ] } ], "artifacts": [ { "id": "sig-prep-proof-configuration", "name": "Pinned Proof Configuration", "description": "The canonical, immutable set of proof options — algorithm and parameters, verification-method reference, proof purpose, context bindings and policy pins — assembled at preparation and, where the securing mechanism supports it, itself covered by the protected input. Compared field-by-field against the returned proof's declared values at admission.", "media_or_form": [ "structured record", "canonical serialised option set" ], "serial": false, "identity_strategy": "Primary identifier is the authoritative master-system identifier assigned by the proof-request store that owns it; the governed external identifiers it contains (verification-method URL, cryptosuite identifier, proof purpose) are carried unchanged and never re-minted. Where no master-system identifier exists, a UUID or ULID is minted; the configuration digest is an integrity check value, not an identifier.", "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-008", "SRC-089" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-prep-executor-handoff", "name": "Correlated Request and Executor Boundary", "description": "The request record correlating one preparation to exactly one executor response within a bounded validity window, and the refusal constraints keeping secrets, mutable references and authorization decisions on the far side of the boundary.", "source_refs": [ "SRC-085", "SRC-009", "SRC-086", "SRC-087" ], "findings": [ { "id": "sig-prep-request-record", "name": "Correlated, expiring request to an external signing or proving executor", "description": "A request record binds one signing input manifest and one pinned proof configuration to one correlation identifier, one creation instant and one expiry instant. Dispatch is guarded by an expected-revision precondition and an idempotency key so retries after a network failure cannot produce a second signing operation or extend the validity window. Asynchronous operation requires an explicit response delivery reference and the same correlation identifier echoed back.", "source_refs": [ "SRC-085", "SRC-009", "SRC-087", "SRC-088" ], "questions": [ { "id": "sig-prep-q-correlation-id", "text": "What request correlation identifier is issued, and how does the executor echo it so a response matches exactly one request?", "kind": "identity", "answer_data": [ "request correlation identifier", "echo or response identifier", "one-to-one binding assertion", "echo verification outcome" ] }, { "id": "sig-prep-q-request-expiry", "text": "When was the request created and when does it expire, and what clock and skew govern those instants?", "kind": "temporal", "answer_data": [ "creation instant as RFC 3339 with seconds and offset", "expiry instant as RFC 3339 with seconds and offset", "clock source reference", "maximum permitted skew" ] }, { "id": "sig-prep-q-idempotency", "text": "Which idempotency key makes a retried dispatch safe, and what is the defined result of replaying that key?", "kind": "process", "answer_data": [ "idempotency key", "replay outcome code", "retry window", "existing request reference returned on replay" ] }, { "id": "sig-prep-q-concurrency", "text": "Which request lifecycle states permit dispatch, and which expected-version preconditions must hold for the transition to be accepted?", "kind": "lifecycle", "answer_data": [ "current request state", "permitted transition set", "expected host version or entity-tag", "expected request revision", "precondition failure code" ] }, { "id": "sig-prep-q-request-mode", "text": "Is the operation synchronous or asynchronous, and where and over which authenticated channel is the response delivered?", "kind": "interoperability", "answer_data": [ "operation mode code", "response delivery endpoint reference", "channel authentication method reference", "expected response media form" ] } ], "data_elements": [ { "id": "sig-prep-de-correlation-id", "name": "Request correlation identifier", "description": "Identifier minted at preparation and required to be echoed by the executor; a response whose correlation identifier matches no open request is refused.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-087" ] }, { "id": "sig-prep-de-request-created", "name": "Request creation instant", "description": "Instant the request record was created, as RFC 3339 with seconds and an explicit offset or Z. Distinct from the proof's asserted creation instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-088", "SRC-022" ] }, { "id": "sig-prep-de-request-expiry", "name": "Request expiry instant", "description": "Instant after which a returned proof is refused regardless of its cryptographic correctness. Never extended by a retry.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-022", "SRC-087", "SRC-088" ] }, { "id": "sig-prep-de-idempotency-key", "name": "Idempotency key", "description": "Caller-supplied key making preparation, dispatch and attachment safely retryable; replay returns the existing outcome rather than creating a new one.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-085" ] }, { "id": "sig-prep-de-expected-revision", "name": "Expected revision precondition", "description": "Entity-tag or revision value the caller believes current; a mismatch fails the mutation with a precondition failure rather than merging concurrent writes.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-085" ] }, { "id": "sig-prep-de-operation-mode", "name": "Operation mode code", "description": "Synchronous or asynchronous execution mode, with the response delivery reference required when asynchronous.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-087" ] } ], "artifacts": [ { "id": "sig-prep-proof-request-record", "name": "Proof Request Record", "description": "The correlated, state-bearing record for one signing or proving request: references to the signing input manifest and pinned proof configuration, correlation identifier, idempotency key, creation and expiry instants, operation mode, response delivery reference, executor reference, current lifecycle state and revision. Transitions forward only and is closed by admission, refusal or expiry.", "media_or_form": [ "structured record", "state-machine instance" ], "serial": true, "identity_strategy": "Primary identifier is the authoritative master-system identifier assigned by the adopting Dimension's proof-request store; where the executor is the system of record for the operation, its request identifier is carried as an additional governed reference. A UUID or ULID is minted only when neither exists. The correlation identifier is a matching value, never the record's primary identifier.", "source_refs": [ "SRC-085", "SRC-009", "SRC-087", "SRC-088" ] } ], "inline_only_rationale": null }, { "id": "sig-prep-executor-limits", "name": "Executor boundary constraints and minimum disclosure", "description": "The refusal rules applied at dispatch. Private key access, signer or prover authorization and cryptographic primitive execution stay wholly with the executor, whose module keeps keys non-extractable and may require authentication before each key use. Every reference in the outgoing payload must resolve to immutable, digest-pinned content: a mutable reference lets content change between the executor's fetch and the model's own pin, which is precisely the substitution the protected input exists to prevent. Disclosure is minimised to the digest wherever a digest suffices.", "source_refs": [ "SRC-001", "SRC-009", "SRC-086", "SRC-087" ], "questions": [ { "id": "sig-prep-q-no-key-access", "text": "Which operations are asserted to remain wholly inside the executor's cryptographic module, and what records that assertion?", "kind": "ownership", "answer_data": [ "externalised operation list", "module or token reference", "non-extractability assertion reference", "attestation reference held externally" ] }, { "id": "sig-prep-q-no-mutable-refs", "text": "Does every reference sent to the executor resolve to immutable content, and how is that immutability demonstrated?", "kind": "security", "answer_data": [ "per-reference immutability flag", "per-reference content digest", "list of references refused as mutable", "dispatch refusal reason code" ] }, { "id": "sig-prep-q-authorization-owner", "text": "Who authorises the signer or prover to use the pinned key, and which system holds that decision?", "kind": "authority", "answer_data": [ "authorisation decision owner reference", "activation data reference held externally", "authorisation outcome reference", "sole-control assertion reference" ] }, { "id": "sig-prep-q-minimum-disclosure", "text": "What is the minimum data set the executor requires, and which host content is deliberately withheld?", "kind": "privacy", "answer_data": [ "disclosed field list", "withheld field list", "digest-only flag", "disclosure justification reference" ] } ], "data_elements": [ { "id": "sig-prep-de-externalised-operations", "name": "Externalised operation list", "description": "Enumeration of operations this model never performs locally: key access, activation, signing, proving, derivation and verification computation.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-086", "SRC-087", "SRC-001" ] }, { "id": "sig-prep-de-reference-pin", "name": "Outgoing reference pin", "description": "For each reference in the outgoing payload, the resolved content digest and an immutability flag; an unpinned reference fails dispatch.", "value_kind": "object", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-009", "SRC-007" ] }, { "id": "sig-prep-de-digest-only-flag", "name": "Digest-only disclosure flag", "description": "Records that only a digest, never host content, crossed the boundary — mirroring a time-stamping authority that never examines the imprinted data.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-087" ] }, { "id": "sig-prep-de-authorization-decision-ref", "name": "Authorisation decision reference", "description": "Reference to the external decision authorising key use. A reference only: activation data values are never stored or relayed by this model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-086", "SRC-087" ] } ], "artifacts": [], "inline_only_rationale": "These are refusal and minimisation constraints evaluated at dispatch time, not a stored object. They are carried as inline flags and references on the request record owned by an adjacent finding, and every assertion they point at — module attestations, non-extractability guarantees, signer authorisation outcomes — is held and evidenced by external models. Creating a local artifact here would imply this model holds custody evidence it must never hold." } ] } ] }, { "id": "sig-prep-proof-admission", "name": "Returned Proof Admission and Host-Bound Attachment", "description": "The gate every returned proof passes before it may touch a host record, and the append-only attachment binding admitted proof octets to a new host version without altering payload, identity, approval state or trust standing.", "rationale": "Every specification consulted makes admission a comparison against something fixed earlier: the time-stamp response imprint must equal the request imprint or be rejected, the echoed nonce must match, a conforming Data Integrity processor must produce an error on a non-conforming document, and JCS requires any verification failure to abort the operation. Attachment then follows the secured-document model in which a proof is added to an unsecured input document, with proof sets unordered and proof chains ordered by an explicit previous-proof reference.", "source_refs": [ "SRC-084", "SRC-022", "SRC-019", "SRC-085", "SRC-009", "SRC-005" ], "layers": [ { "id": "sig-prep-admission-control", "name": "Admission Checks and Append-Only Attachment", "description": "The complete check set applied to a returned proof, the disposition of refused material, and the semantics of appending an admitted proof as an immutable, host-bound version.", "source_refs": [ "SRC-084", "SRC-022", "SRC-085", "SRC-009", "SRC-005" ], "findings": [ { "id": "sig-prep-admission-gate", "name": "Admission checks on a returned proof", "description": "Before a returned proof may be attached, all of the following must hold: a dispatched, unexpired request record exists for the claimed correlation identifier; the recomputed protected input or digest equals the manifest value byte-for-byte; the declared algorithm, parameters and verification-method reference equal the pinned configuration; the context bindings equal the pinned values; the response arrived inside the validity window; and the nonce or challenge has not been seen before for this host and purpose. Any single failure refuses the whole proof. These are structural comparisons against recorded pins — cryptographic verification itself is executed elsewhere, and a passing admission is not a verification result.", "source_refs": [ "SRC-084", "SRC-022", "SRC-019", "SRC-009", "SRC-087" ], "questions": [ { "id": "sig-prep-q-check-set", "text": "Which checks must all pass before a returned proof is admitted, and what happens if any single check fails?", "kind": "validation", "answer_data": [ "ordered check identifier list", "per-check outcome", "aggregate admission decision", "abort-on-first-failure flag" ] }, { "id": "sig-prep-q-unsolicited", "text": "How is an unsolicited or duplicate proof detected and refused?", "kind": "exception", "answer_data": [ "matching request record reference or explicit null", "duplicate detection key", "refusal reason code", "quarantine reference" ] }, { "id": "sig-prep-q-parameter-match", "text": "Do the algorithm, parameters and verification-method reference in the returned proof match exactly what was pinned?", "kind": "evidence", "answer_data": [ "pinned versus returned algorithm comparison", "pinned versus returned parameter comparison", "pinned versus returned verification method comparison", "mismatched field list" ] }, { "id": "sig-prep-q-expiry-replay", "text": "Did the response arrive inside the validity window, and does the nonce or challenge prevent replay onto another host version?", "kind": "temporal", "answer_data": [ "response receipt instant as RFC 3339 with offset", "request expiry instant", "nonce or challenge reuse check outcome", "replay scope key" ] }, { "id": "sig-prep-q-refusal-record", "text": "What is recorded when a proof is refused, and where does the refused material go?", "kind": "retention", "answer_data": [ "refusal reason code set", "quarantine location reference", "disposition rule reference", "refused-material retention period" ] } ], "data_elements": [ { "id": "sig-prep-de-admission-decision", "name": "Admission decision", "description": "Accepted or refused, with the ordered per-check outcomes producing it. A refusal is terminal for that response.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-084", "SRC-019" ] }, { "id": "sig-prep-de-refusal-reason", "name": "Refusal reason code set", "description": "Enumerated causes: no matching request, correlation mismatch, digest mismatch, algorithm mismatch, method mismatch, context mismatch, expired, replayed, duplicate.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-022", "SRC-084" ] }, { "id": "sig-prep-de-response-receipt-instant", "name": "Response receipt instant", "description": "Observation instant at which the response was received, recorded separately from the proof's asserted creation instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-088", "SRC-022" ] }, { "id": "sig-prep-de-replay-scope-key", "name": "Replay scope key", "description": "Composite of nonce or challenge, host record, proof purpose and audience, checked for prior use to block cross-context replay.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-022", "SRC-084", "SRC-009" ] }, { "id": "sig-prep-de-quarantine-ref", "name": "Quarantine reference", "description": "Location of refused proof material, held separately from attachments under its own shorter disposition rule and never promoted.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [ { "id": "sig-prep-admission-outcome-record", "name": "Admission Outcome Record", "description": "The outcome of running the admission check set against one returned proof: ordered per-check results, aggregate decision, any refusal reason codes, the response receipt instant and the replay scope key. It closes the request record it belongs to. It is operational state of this model's own request, not an audit-trail entry: it is not the audit model's record format, is not sealed or retained by this model, and is not a verification result.", "media_or_form": [ "structured record", "ordered check-result list" ], "serial": true, "identity_strategy": "Primary identifier is the authoritative master-system identifier assigned by the adopting Dimension's proof-request store, scoped to the request record it closes; failing that, a UUID or ULID minted at admission. The correlation identifier and the response digest are matching and integrity values, never the primary identifier.", "source_refs": [ "SRC-084", "SRC-022", "SRC-019", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "sig-prep-attachment-append", "name": "Append-only, host-bound attachment of an admitted proof", "description": "Attachment copies the pinned host payload version, adds the admitted proof to it and yields a new host-bound version; the payload itself is unchanged and no previously attached proof is altered. Proof octets are stored byte-exact and never re-encoded, re-indented or normalised in storage. The new proof joins either an unordered proof set or an ordered proof chain, where chain position is asserted by an explicit previous-proof reference rather than by storage order. Attaching the same admitted proof twice under the same idempotency key yields no second version.", "source_refs": [ "SRC-084", "SRC-085", "SRC-005", "SRC-089" ], "questions": [ { "id": "sig-prep-q-append-semantics", "text": "How does attachment append a new host-bound version without mutating the host payload or any previously attached proof?", "kind": "process", "answer_data": [ "new host version identifier", "predecessor host version identifier", "payload-unchanged assertion", "prior-proof-unaltered assertion" ] }, { "id": "sig-prep-q-proof-immutability", "text": "Are the proof octets stored byte-exact and immutable after attachment, and what detects later alteration?", "kind": "quality", "answer_data": [ "proof value encoding", "stored octet digest and algorithm", "re-encoding prohibition flag", "alteration detection procedure reference" ] }, { "id": "sig-prep-q-attach-idempotency", "text": "If the same admitted proof is attached twice, how many host versions result?", "kind": "state", "answer_data": [ "idempotency key", "existing attachment reference", "no-op outcome flag", "resulting version count" ] }, { "id": "sig-prep-q-set-or-chain", "text": "Is the new proof joining an unordered proof set or an ordered proof chain, and which existing proof does it follow?", "kind": "composition", "answer_data": [ "set-or-chain code", "previous proof reference", "resulting chain position ordinal", "serial ordinal recorded separately" ] }, { "id": "sig-prep-q-attach-nonclaims", "text": "What does attachment explicitly not do to the host record's identity, approval state or trust standing?", "kind": "decision", "answer_data": [ "excluded effect list", "owning model reference for approval workflow", "owning model reference for host identity", "reliance decision owner reference" ] } ], "data_elements": [ { "id": "sig-prep-de-attached-version-id", "name": "Attached host version identifier", "description": "Identifier of the new host-bound version produced by attachment, naming its predecessor.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-084", "SRC-005" ] }, { "id": "sig-prep-de-proof-value", "name": "Proof value octets", "description": "The returned proof bytes stored exactly as received, with their declared encoding recorded; never re-encoded by storage or transport layers.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-084", "SRC-089" ] }, { "id": "sig-prep-de-set-or-chain", "name": "Set or chain membership code", "description": "Whether the proof belongs to an unordered proof set or an ordered proof chain.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-084" ] }, { "id": "sig-prep-de-previous-proof-ref", "name": "Previous proof reference", "description": "For chain membership, the proof that must be verified before this one; absent for set membership.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-084" ] }, { "id": "sig-prep-de-attachment-instant", "name": "Attachment instant", "description": "Observation instant at which the proof was appended, recorded separately from the proof's asserted creation instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-088", "SRC-084" ] }, { "id": "sig-prep-de-excluded-effects", "name": "Excluded effect list", "description": "Explicit enumeration of what attachment does not do: mint host identity, grant approval, assert trust standing or write an audit trail.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "sig-prep-attached-proof-version", "name": "Attached Proof Version", "description": "The immutable host-bound record produced by a successful attachment: proof descriptor, byte-exact proof octets and their encoding, references to the signing input manifest and pinned proof configuration, set-or-chain membership with any previous-proof reference, the new and predecessor host version identifiers, and the attachment instant. Superseded only by appending a further version, never by editing.", "media_or_form": [ "structured record", "byte-exact proof octet string", "host version link" ], "serial": true, "identity_strategy": "Primary identifier is the authoritative master-system identifier assigned by the attachment store that owns host versions; where the host record's own master system assigns version identifiers, that identifier governs. A UUID or ULID is minted only where neither exists. The proof-value digest and the serial ordinal are integrity and ordering values, not identifiers, and no instant is used as an identifier.", "source_refs": [ "SRC-084", "SRC-085", "SRC-005", "SRC-089" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-life-multiparty-composition", "name": "Multi-Party Proof Composition", "description": "How several proofs over one subject relate to each other: independent co-signature sets that bind separately to the same pinned payload version, dependency-ordered countersignature chains that bind to the exact bytes of a prior signature, the declaration of who must participate and for what purpose, and the reporting of partial completion per member and per dependency.", "rationale": "Authoritative securing mechanisms explicitly separate unordered sets from ordered chains, and separate binding-to-payload from binding-to-prior-signature. Conflating these produces false conclusions about order, dependency and who attested to what, so the topology must be recorded rather than inferred from the presence of several proofs.", "source_refs": [ "SRC-004", "SRC-015", "SRC-006", "SRC-061", "SRC-093" ], "layers": [ { "id": "sig-life-binding-topology", "name": "Binding Topology and Dependency Order", "description": "The two distinct ways an additional proof may be attached to a subject that already carries a proof: independent co-signature over the same pinned payload, and countersignature over a named prior signature. Each has a different binding target, a different failure propagation rule and a different ordering guarantee.", "source_refs": [ "SRC-004", "SRC-015", "SRC-006", "SRC-091" ], "findings": [ { "id": "sig-life-cosign-independent-binding", "name": "Independent co-signature binding to a pinned payload version", "description": "An independent co-signature is a proof appended by an additional party that binds to the same pinned payload version and canonical byte form as its siblings, and to nothing else. Its validity is computed without reference to any sibling proof, membership in the set is unordered, and the failure of one member does not by itself invalidate another. The set is a recorded fact about topology, not a derived count.", "source_refs": [ "SRC-004", "SRC-006", "SRC-019", "SRC-093" ], "questions": [ { "id": "sig-life-cosign-payload-binding", "text": "Which pinned payload version, canonicalization method and digest does this co-signature bind to, and how is that binding recorded at signing time?", "kind": "identity", "answer_data": [ "Pinned payload version identifier issued by the host record model", "Canonicalization method identifier, for example a named JSON or deterministic CBOR scheme", "Digest algorithm identifier and digest value over the canonical bytes", "Instant at which the binding was fixed, as an RFC 3339 value with offset" ] }, { "id": "sig-life-cosign-set-membership", "text": "Is this proof a member of an unordered co-signature set rather than a position in a dependency-ordered chain, and what recorded evidence establishes that distinction?", "kind": "composition", "answer_data": [ "Topology marker with values independent-set or dependency-chain", "Absence of any covered prior-signature digest or prior-proof pointer", "Set identifier shared by all members bound to the same pinned payload version", "Reference to the securing mechanism construct used, such as an unordered proof set or parallel signer entries" ] }, { "id": "sig-life-cosign-failure-isolation", "text": "Does verification of this co-signature depend on any sibling proof, and what does the set report when one member fails or is indeterminate?", "kind": "relationship", "answer_data": [ "Declared independence flag with the rule that a member outcome is scoped to that member", "Per-member outcome list rather than a single aggregate verdict", "Explicit statement that a failed member is reported as failed without changing sibling outcomes", "Reference to the application rule in force where a stricter all-must-pass convention has been adopted" ] }, { "id": "sig-life-cosign-purpose-and-method", "text": "Under which declared proof purpose and verification-method or key reference did this participant sign, and where is that reference resolved?", "kind": "authority", "answer_data": [ "Declared proof purpose code, such as assertion, authentication or attestation of an existing record", "Verification-method or key reference as an identifier resolvable in the key and certificate model", "Signer or attesting party reference", "Named signature suite or algorithm identifier as declared, not as computed" ] }, { "id": "sig-life-cosign-projection", "text": "How is the independence of this co-signature preserved when the set is projected into a different securing mechanism or serialization?", "kind": "interoperability", "answer_data": [ "Mapping table from the model's topology marker to the target construct, such as proof set, parallel signer entries or multiple signature entries", "Statement of which target constructs cannot express independence and must therefore be rejected or annotated", "Round-trip rule requiring the original proof bytes to survive the projection unchanged", "Record of any information loss detected during projection" ] } ], "data_elements": [ { "id": "sig-life-de-pinned-payload-version", "name": "Pinned payload version reference", "description": "Identifier of the exact host payload version whose canonical bytes this proof covers. Assigned by the host record model and never re-pointed after the proof is created.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-005" ] }, { "id": "sig-life-de-canonicalization-method", "name": "Canonicalization method identifier", "description": "Named scheme used to derive the invariant byte sequence that was signed, recorded because re-serialization with a different procedure produces different bytes.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-015" ] }, { "id": "sig-life-de-payload-digest", "name": "Payload digest value and algorithm", "description": "Digest algorithm identifier and digest value computed over the canonical payload bytes, used to detect divergence between the stored payload and the bytes that were signed.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-009" ] }, { "id": "sig-life-de-topology-marker", "name": "Composition topology marker", "description": "Explicit indication of whether the proof is an independent set member or a dependency-chain position. Never inferred from the number of proofs present.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "sig-life-de-proof-purpose", "name": "Declared proof purpose", "description": "The intent declared by the creator of the proof so that the proof cannot be reused for an unintended purpose.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "sig-life-art-cosignature-record", "name": "Independent co-signature proof record", "description": "The retained record of one independently bound co-signature: original proof bytes, pinned payload version reference, canonicalization and digest parameters, signer and verification-method references, declared purpose, topology marker and set identifier.", "media_or_form": [ "Embedded proof object carried inside the host record", "Detached proof document referencing the host payload version", "Signature entry within a multi-signature envelope structure", "Signer information entry within a parallel-signature container", "Row or document in an adopting-Dimension store, holding the original bytes verbatim" ], "serial": false, "identity_strategy": "Use the authoritative master-system proof identifier issued by the system of record that produced or registered the proof, recorded with its issuing naming system. Where none exists, use a governed global identifier or IRI from a namespace the adopting Dimension controls or recognises. Where neither exists, assign a UUID or ULID and mark it as locally assigned. The payload or proof digest is an integrity check and a secondary locator, never a primary identifier, and no date may be used as an identifier.", "source_refs": [ "SRC-004", "SRC-006", "SRC-092" ] } ], "inline_only_rationale": null }, { "id": "sig-life-countersign-dependency-binding", "name": "Dependency-aware countersignature binding to prior signature bytes", "description": "A countersignature binds to the exact byte sequence or digest of one named prior signature rather than to the payload alone, creating an explicit ordered dependency. The covered signature is unchanged by the act. A countersignature may itself be countersigned, so positions form an ordered chain in which an indeterminate or failed earlier position propagates to every later position.", "source_refs": [ "SRC-015", "SRC-006", "SRC-004", "SRC-091", "SRC-061" ], "questions": [ { "id": "sig-life-countersign-covered-bytes", "text": "Which exact prior signature bytes or digest does this countersignature cover, and is the covered object a signature value or the payload itself?", "kind": "composition", "answer_data": [ "Reference to the covered prior proof record", "Digest algorithm and digest value over the covered signature bytes", "Covered-object kind with values signature-value or payload", "Context label recorded from the securing mechanism, distinguishing countersignature over a signature from a signature over content" ] }, { "id": "sig-life-countersign-order-immutability", "text": "What ordinal position does this countersignature occupy in its chain, and by what rule is that order prevented from changing afterwards?", "kind": "constraint", "answer_data": [ "Chain root reference identifying the first signature in the dependency order", "Monotonic ordinal assigned by the system of record, starting at one within the chain", "Rule that ordinals are never reused, renumbered or reordered once assigned", "Statement that correcting an order requires a new superseding chain, not an edit" ] }, { "id": "sig-life-countersign-status-propagation", "text": "If the covered prior signature is reported failed or indeterminate, what status must this position and every later position report?", "kind": "validation", "answer_data": [ "Propagation rule stating that a later position cannot report a stronger status than the position it covers", "Recorded status indication and sub-indication for each position as returned by the external validator", "Explicit indeterminate marker where the covered position has no recorded outcome", "Reference to the validation policy under which the indications were produced" ] }, { "id": "sig-life-countersign-binding-strength", "text": "Is the dependency expressed by covering the prior signature bytes or only by pointing at a prior proof identifier, and how is the difference in binding strength recorded?", "kind": "interoperability", "answer_data": [ "Dependency binding kind with values covered-bytes or prior-proof-identifier", "Note that an identifier-only pointer is not cryptographically bound to the prior bytes and depends on the resolver's integrity", "Digest of the covered bytes where available", "Named securing mechanism construct used to express the dependency" ] }, { "id": "sig-life-countersign-attestation-scope", "text": "What exactly does the countersigning party attest to: the existence of the prior signature, or the meaning of the underlying payload?", "kind": "definition", "answer_data": [ "Declared attestation scope with values existence-of-prior-signature or endorsement-of-payload", "Declared purpose for this chain position", "Note that countersigning an opaque or protected body attests only to the existence of that body", "Party reference and the role in which the party countersigned, such as witness or notarial role" ] } ], "data_elements": [ { "id": "sig-life-de-covered-prior-signature", "name": "Covered prior signature reference and digest", "description": "Identifier of the prior proof record covered by this countersignature together with the digest of the exact bytes covered.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-006" ] }, { "id": "sig-life-de-chain-ordinal", "name": "Dependency chain ordinal", "description": "Monotonically increasing integer position of this countersignature within one chain, assigned by the system of record and never reused.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-015" ] }, { "id": "sig-life-de-chain-root-reference", "name": "Chain root reference", "description": "Reference to the first signature of the dependency chain, used to scope ordinals and to detect attempts to graft a position onto a different chain.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-015" ] }, { "id": "sig-life-de-dependency-binding-kind", "name": "Dependency binding kind", "description": "Whether the dependency is bound by covering the prior signature bytes or only by referencing the prior proof identifier, recorded because the two carry different assurance.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-004" ] }, { "id": "sig-life-de-position-status-indication", "name": "Recorded status indication for the position", "description": "Validation status indication and sub-indication for this chain position exactly as returned by the external validator, together with the validator reference.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061" ] } ], "artifacts": [ { "id": "sig-life-art-countersignature-record", "name": "Countersignature chain position record", "description": "The retained record of one dependency-ordered countersignature: original countersignature bytes, covered prior signature reference and digest, chain root, ordinal, binding kind, attestation scope and party reference.", "media_or_form": [ "Countersignature structure carried in an unprotected header of the covered signature", "Countersignature attribute attached to a signer information entry", "Ordered proof entry carrying a previous-proof pointer inside a host record", "Chained record in an adopting-Dimension store retaining the covered bytes and the countersignature bytes verbatim" ], "serial": true, "identity_strategy": "Use the authoritative master-system identifier issued by the system of record that produced or registered the countersignature. Where none exists, use a governed global identifier or IRI. Where neither exists, assign a UUID or ULID and mark it as locally assigned. The chain ordinal orders the record but is never its identifier, and no date may be used as an identifier.", "source_refs": [ "SRC-015", "SRC-006", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-life-participation-declaration", "name": "Required Participation, Purpose and Completion Reporting", "description": "The declaration of who must sign, in what role, for what purpose and in what dependency relation, and the disciplined reporting of how far that declaration has been fulfilled without inferring authorization, approval or threshold satisfaction from a subset of collected signatures.", "source_refs": [ "SRC-061", "SRC-092", "SRC-004", "SRC-093" ], "findings": [ { "id": "sig-life-participant-requirement-declaration", "name": "Required participant, dependency and threshold declaration", "description": "A declaration bound to a pinned payload version that names each required participation slot, its role and purpose, whether the slot is an independent co-signature or a dependency position, and a reference to the externally owned rule that decides when the requirement is met. The declaration states the requirement; it never states the outcome.", "source_refs": [ "SRC-092", "SRC-061", "SRC-004", "SRC-093" ], "questions": [ { "id": "sig-life-requirement-slot-definition", "text": "Which participants, roles or verification-method references are required, and is each required slot independent or part of a dependency order?", "kind": "requirement", "answer_data": [ "Slot list with slot identifier, required party or role reference, and optional verification-method constraint", "Per-slot topology marker distinguishing independent set membership from a dependency position", "Declared dependency edges between slots where order is required", "Minimum number of satisfied slots as declared, kept separate from any statement that the minimum has been reached" ] }, { "id": "sig-life-requirement-threshold-authority", "text": "Which external authority owns the threshold or signature policy rule, and which result artefact is the only acceptable evidence that the rule is met?", "kind": "authority", "answer_data": [ "Reference to the externally owned policy or registration rule", "Reference to the decision or validation result that may state satisfaction", "Named authority or service that issues that result", "Explicit statement that this model records but never evaluates the rule" ] }, { "id": "sig-life-requirement-slot-typing", "text": "How is each slot classified with respect to purpose, so that a signature collected for one purpose cannot be counted against a slot declared for another?", "kind": "classification", "answer_data": [ "Per-slot declared purpose code", "Matching rule requiring the collected proof's declared purpose to equal the slot's declared purpose", "Handling rule for proofs that arrive unsolicited or with a non-matching purpose", "Record of any slot whose purpose is unconstrained, with the reason" ] }, { "id": "sig-life-requirement-mutation-limits", "text": "Once the declaration is bound to a pinned payload version, may slots be added, removed or reordered, and what is required instead?", "kind": "constraint", "answer_data": [ "Rule that a bound declaration is immutable and changes require a new declaration version", "Supersession link from the new declaration version to the previous one", "Statement of what happens to signatures already collected under the previous declaration", "Precondition token required to append a new declaration version" ] }, { "id": "sig-life-requirement-substitution-protection", "text": "How is the declaration itself protected against substitution, given that it defines who must sign?", "kind": "security", "answer_data": [ "Digest of the canonical declaration bytes referenced from each collected proof", "Optional proof over the declaration itself, recorded as an ordinary proof record", "Reference to an external registration receipt or time-stamp evidencing the declaration's prior existence", "Detection rule for a collected proof that references a declaration digest not equal to the current one" ] } ], "data_elements": [ { "id": "sig-life-de-requirement-slot", "name": "Required participation slot", "description": "One declared slot with its identifier, required party or role reference, declared purpose, topology marker and any verification-method constraint.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-092", "SRC-004" ] }, { "id": "sig-life-de-declared-minimum-count", "name": "Declared minimum satisfied-slot count", "description": "The minimum number of satisfied slots stated in the declaration. It is an input to an external decision and is never itself a statement that the minimum has been reached.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-093" ] }, { "id": "sig-life-de-threshold-rule-reference", "name": "External threshold or signature policy reference", "description": "Pointer to the externally owned rule that determines whether the collected participation satisfies the requirement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-092" ] }, { "id": "sig-life-de-declaration-digest", "name": "Declaration canonical digest", "description": "Digest over the canonical bytes of the declaration, referenced by each collected proof so that substitution of the declaration is detectable.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-092" ] } ], "artifacts": [ { "id": "sig-life-art-participation-declaration", "name": "Multi-party signing requirement declaration", "description": "The retained, immutably bound declaration of required participation slots, dependency edges, per-slot purposes, declared minimum count and the reference to the externally owned threshold rule, together with its canonical digest.", "media_or_form": [ "Structured declaration document bound to one pinned payload version", "Registration-policy style precondition set held by the registering service", "Signing-plan record in an adopting-Dimension store", "Human-readable rendering used for participant instruction, derived from the bound canonical form" ], "serial": false, "identity_strategy": "Use the authoritative master-system identifier issued by the system of record that holds the signing process. Where none exists, use a governed global identifier or IRI. Where neither exists, assign a UUID or ULID and mark it as locally assigned. Declaration versions are distinguished by an explicit version reference and supersession link, never by a date in the identifier.", "source_refs": [ "SRC-092", "SRC-061" ] } ], "inline_only_rationale": null }, { "id": "sig-life-completion-reporting", "name": "Per-member and per-dependency completion reporting without inference", "description": "A read-only projection over what has actually been recorded: for each declared slot and each dependency position, whether a proof has been collected, what status an external validator returned for it, and where evidence is absent, stale or contradictory. Satisfaction of a threshold, an authorization or a workflow approval is reported only when an external decision result explicitly states it, and is otherwise reported as indeterminate.", "source_refs": [ "SRC-061", "SRC-092", "SRC-006", "SRC-093" ], "questions": [ { "id": "sig-life-completion-per-slot-state", "text": "What is the recorded completion state of each declared slot and each dependency position at a stated observation time?", "kind": "state", "answer_data": [ "Per-slot state from the closed set collected, not-collected, indeterminate or reported-failed", "Per-dependency-position state including whether the covered position has its own recorded outcome", "Observation instant as an RFC 3339 value with offset", "Reference to the declaration version the projection was computed against" ] }, { "id": "sig-life-completion-count-insufficiency", "text": "How many slots are satisfied, unsatisfied or indeterminate, and why is that count alone insufficient to conclude that the requirement is met?", "kind": "measurement", "answer_data": [ "Counts by state, each labelled as a count of recorded facts only", "Explicit non-inference statement attached to the counts", "List of conditions that the count cannot capture, such as purpose mismatch, stale validation or unresolved dependency", "Note that a threshold-produced signature occupies exactly one slot and does not represent multiple parties" ] }, { "id": "sig-life-completion-decision-reference", "text": "Which external decision or validation result, if any, explicitly states that the requirement is satisfied, and where is that result referenced?", "kind": "decision", "answer_data": [ "Reference to the external decision result record", "Issuing authority or service reference and the result's own observation time", "Verbatim satisfaction statement as returned, without local reinterpretation", "Explicit absent marker where no such result exists" ] }, { "id": "sig-life-completion-evidence-quality", "text": "What evidence supports each per-member outcome, and what is reported when that evidence is missing, stale or contradicted by another source?", "kind": "evidence", "answer_data": [ "Per-slot evidence reference such as a validation result, receipt or time-stamp token", "Freshness statement comparing the evidence's observation time to the projection's observation time", "Conflict entry listing contradictory outcomes with their sources", "Indeterminate reason code and text where evidence is insufficient" ] }, { "id": "sig-life-completion-attribution-exception", "text": "How are participants reported whose identity is sealed, or whose contribution is attributable only in aggregate?", "kind": "exception", "answer_data": [ "Sealed-slot representation carrying slot identifier and state but no party identity", "Aggregate-attribution marker for signatures where per-party attribution is not recoverable", "Condition and authority under which sealed identity may later be disclosed", "Statement that a sealed or aggregate slot never contributes to an inferred satisfaction conclusion" ] } ], "data_elements": [ { "id": "sig-life-de-slot-completion-state", "name": "Per-slot completion state", "description": "State of one declared slot at the projection's observation time, drawn from a closed set and derived only from recorded facts.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-061", "SRC-006" ] }, { "id": "sig-life-de-completion-observed-at", "name": "Completion projection observation time", "description": "The instant at which the projection was computed, recorded separately from the times of the underlying signing and validation events.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-009" ] }, { "id": "sig-life-de-external-decision-reference", "name": "External decision result reference", "description": "Pointer to the externally produced result that explicitly states requirement satisfaction. Absence of this reference means the projection reports indeterminate.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-092" ] }, { "id": "sig-life-de-indeterminate-reason", "name": "Indeterminate reason", "description": "Coded and human-readable reason why a slot, dependency position or overall requirement could not be resolved from recorded evidence.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061" ] } ], "artifacts": [], "inline_only_rationale": "The completion report is a derived, non-authoritative projection over records that already exist elsewhere in this model and over validation results owned by an external validator. Persisting it as an artifact would create a second, silently ageing statement about participation that consumers could mistake for an authoritative verdict, and would invite exactly the inference this model forbids. It is therefore defined as inline, recomputed on demand and always labelled with its observation time and the declaration version it was computed against. Where a durable statement of satisfaction is genuinely required, the durable object is the external decision result, referenced here and stored by the model that owns it." } ] } ] }, { "id": "sig-life-append-only-operations", "name": "Append-Only Proof Lifecycle Operations", "description": "The safety contract that governs every mutation of proof context: idempotency and optimistic-concurrency preconditions, immutability of original proof bytes and earlier versions, and the two reasoned append-only assertions by which reliance on a proof changes, namely scoped invalidation and directed supersession.", "rationale": "Every authoritative mechanism examined expresses lifecycle change by appending a new record that references the old one, never by rewriting signed bytes: revocation is itself a signature, transparency ledgers forbid modification, deletion and reordering, and provenance vocabularies model invalidation and revision as separate assertions rather than as edits. The mutation surface must therefore be additive and must be safe under retry and concurrency.", "source_refs": [ "SRC-085", "SRC-090", "SRC-091", "SRC-092", "SRC-005" ], "layers": [ { "id": "sig-life-mutation-safety", "name": "Mutation Safety: Idempotency, Concurrency and Immutability", "description": "The preconditions that every mutation must satisfy before it is accepted, and the invariants that hold afterwards: retries never duplicate a signature, concurrent appends never silently overwrite one another, and no original byte sequence or earlier version record is ever altered.", "source_refs": [ "SRC-085", "SRC-092", "SRC-019", "SRC-094" ], "findings": [ { "id": "sig-life-mutation-preconditions", "name": "Idempotency and optimistic-concurrency preconditions for every mutation", "description": "No co-sign, countersign, invalidate or supersede operation is accepted without a caller-supplied idempotency key with a request fingerprint, and an expected-version token for the target. A replayed key with an identical fingerprint returns the first stored outcome without appending anything; a replayed key with a differing fingerprint is rejected; a stale expected-version token fails the precondition and is never merged.", "source_refs": [ "SRC-085", "SRC-094", "SRC-092" ], "questions": [ { "id": "sig-life-precondition-inputs", "text": "Which idempotency key, request fingerprint and expected-version token must accompany a mutation before it may be accepted?", "kind": "process", "answer_data": [ "Caller-supplied idempotency key, unique within a declared scope and retention window", "Fingerprint over the canonical request content, including the pinned payload version and target reference", "Expected-version token for the target record or chain, obtained from a prior read", "Retention period for which the first stored outcome remains replayable" ] }, { "id": "sig-life-precondition-failure-modes", "text": "What is the exact outcome when a key is replayed with a different fingerprint, and separately when the expected-version token does not match the current version?", "kind": "exception", "answer_data": [ "Fingerprint-mismatch outcome: reject, append nothing, return a conflict indication naming the stored fingerprint", "Version-mismatch outcome: fail the precondition, append nothing, return the current version token", "Rule that neither failure produces a partial write or a merged record", "Guidance that the caller re-reads, re-evaluates and resubmits rather than retrying blindly" ] }, { "id": "sig-life-precondition-concurrent-cosign", "text": "When two participants co-sign concurrently, which attempt is serialized first and how is the second attempt preserved rather than lost?", "kind": "relationship", "answer_data": [ "Serialization rule assigning version tokens in a total order per target", "Statement that the loser receives the current version token and resubmits against it", "Rule that both co-signatures ultimately appear as independent set members, because neither depends on the other", "Contrasting rule for chain positions, where the loser must obtain the new next-free ordinal" ] }, { "id": "sig-life-precondition-retry-vs-second-signature", "text": "How is an accidental retry distinguished from a genuine second signature by the same participant over the same pinned payload version?", "kind": "quality", "answer_data": [ "Comparison of idempotency key and request fingerprint against stored values", "Comparison of the submitted proof bytes against already-stored bytes for the same participant and slot", "Rule that identical bytes with a new key are recorded as a duplicate submission rather than a second slot", "Rule that differing bytes with a new key are accepted only if a slot or purpose distinguishes them" ] }, { "id": "sig-life-precondition-time-recording", "text": "Which time is recorded for a replayed mutation: the instant of the first accepted attempt or the instant of the replay?", "kind": "temporal", "answer_data": [ "Rule that the recorded event time is that of the first accepted attempt and does not move on replay", "Separate observation time recorded for each replay handled", "Both values expressed with seconds and an explicit offset", "Statement that a claimed signing time supplied by the caller is stored as a claim, distinct from either recorded time" ] } ], "data_elements": [ { "id": "sig-life-de-idempotency-key", "name": "Idempotency key", "description": "Caller-supplied key identifying one logical mutation attempt so that retries can be recognised and answered from the stored first outcome.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-094", "SRC-085" ] }, { "id": "sig-life-de-request-fingerprint", "name": "Request fingerprint", "description": "Digest over the canonical content of the mutation request, used to detect reuse of an idempotency key with different content.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-094", "SRC-019" ] }, { "id": "sig-life-de-expected-version-token", "name": "Expected-version token", "description": "The version token the caller believes the target currently carries. A mismatch fails the precondition without any state change.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-085" ] }, { "id": "sig-life-de-resulting-version-token", "name": "Resulting version token", "description": "The version token produced by an accepted mutation, returned so that the caller can chain further preconditions.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-085" ] }, { "id": "sig-life-de-precondition-outcome", "name": "Precondition outcome", "description": "Coded result of precondition evaluation: accepted, replayed-from-stored-outcome, fingerprint-mismatch or version-mismatch.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-085", "SRC-094" ] } ], "artifacts": [], "inline_only_rationale": "Idempotency keys, request fingerprints and version tokens are control data scoped to a single mutation attempt, not evidence about the subject. They are carried on the request and echoed on the response, and their durable trace is the version record produced by the accepted mutation, which is modelled separately. Promoting them to standalone artifacts would create a parallel operations log that overlaps the externally owned audit store and would tempt consumers to treat control metadata as proof context. They are therefore inline fields on the mutation interface and on the resulting version record, with retention of the first stored outcome bounded by an explicitly declared window." }, { "id": "sig-life-immutability-invariant", "name": "Immutability of original proof bytes and earlier versions", "description": "The original byte sequence of every proof, and every earlier version record, are immutable once accepted. Change is expressed exclusively by appending a new version record. Nothing that was covered by a signature may be altered, and a detected mismatch between stored bytes and the recorded digest is reported as an integrity failure rather than corrected in place.", "source_refs": [ "SRC-092", "SRC-019", "SRC-061", "SRC-090" ], "questions": [ { "id": "sig-life-immutability-version-provenance", "text": "Which actor, method and time produced each retained version record, and how is the original byte sequence preserved unaltered across storage projections?", "kind": "provenance", "answer_data": [ "Actor reference for the append and the operation kind that produced the version", "Event time of the append and the separate observation time at which it was recorded", "Storage rule requiring the original bytes to be retained verbatim or content-addressed, never re-serialized", "Version ordinal and pointer to the immediately preceding version record" ] }, { "id": "sig-life-immutability-mutable-surface", "text": "Which fields may be appended to an existing record without breaking a recorded signature, and which may never change?", "kind": "constraint", "answer_data": [ "Immutable set: original proof bytes, covered digests, pinned payload version, canonicalization method, dependency edges and ordinals", "Appendable set: external evidence references, recorded external outcomes, observation timestamps and non-covered annotations", "Rule that appendable fields must lie outside anything the signature covers", "Rejection behaviour for any request that would modify a covered field" ] }, { "id": "sig-life-immutability-integrity-detection", "text": "How is a mismatch between stored bytes and the recorded digest detected and reported, and why must it never be repaired in place?", "kind": "validation", "answer_data": [ "Periodic and on-read digest comparison procedure and its outcome code", "Report format naming the affected record, the expected digest and the computed digest", "Rule that the record is marked indeterminate and escalated rather than rewritten", "Reference to any external proof-of-existence evidence that can adjudicate which byte sequence is original" ] }, { "id": "sig-life-immutability-retention-of-versions", "text": "For how long are earlier version records retained, and what is preserved when a record is tombstoned?", "kind": "retention", "answer_data": [ "Retention period set by the adopting Dimension for proof version records", "Tombstone content: identifier, digest, dependency position, reason and timestamps, without payload-bearing fields", "Rule that tombstoning never removes an earlier version and never renumbers ordinals", "Named owner of physical deletion execution and the disposition event reference recorded here" ] } ], "data_elements": [ { "id": "sig-life-de-version-ordinal", "name": "Version ordinal", "description": "Monotonically increasing integer identifying the position of a version record for one proof, assigned by the system of record and never reused.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-092" ] }, { "id": "sig-life-de-original-proof-bytes", "name": "Original proof bytes", "description": "The verbatim byte sequence of the proof as produced by the external signing operation, retained directly or as an immutable content-addressed reference.", "value_kind": "binary", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-015" ] }, { "id": "sig-life-de-record-integrity-state", "name": "Record integrity state", "description": "Result of comparing stored bytes against the recorded digest: intact, mismatch or not-yet-checked, with the instant of the last check.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-061" ] }, { "id": "sig-life-de-version-event-and-observation-time", "name": "Version event time and observation time", "description": "The instant the appending operation is deemed to have occurred and, separately, the instant this model recorded it.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009", "SRC-061" ] } ], "artifacts": [ { "id": "sig-life-art-proof-version-record", "name": "Immutable proof version record", "description": "One append-only version entry for a proof, retaining the original proof bytes or their content-addressed reference, the digest algorithm and value, the operation kind that created the version, actor reference, event and observation times, the preceding version pointer and the integrity state.", "media_or_form": [ "Append-only entry in an adopting-Dimension store", "Content-addressed object with an immutable reference", "Entry in an externally operated append-only log, referenced here by receipt", "Serialized version history document accompanying a detached proof" ], "serial": true, "identity_strategy": "Use the authoritative master-system identifier of the version entry issued by the system of record. Where none exists, use a governed global identifier or IRI. Where neither exists, assign a UUID or ULID and mark it as locally assigned. The version ordinal orders records within one proof but is never the identifier, and no date may be used as an identifier.", "source_refs": [ "SRC-092", "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "sig-life-reasoned-assertions", "name": "Reasoned Invalidation and Supersession Assertions", "description": "The two append-only assertions by which reliance on an existing proof changes: a scoped, reasoned invalidation that names what should no longer be relied upon and from when, and a directed supersession link that names which record replaces or corrects which, over which effective interval.", "source_refs": [ "SRC-090", "SRC-091", "SRC-092", "SRC-005", "SRC-052" ], "findings": [ { "id": "sig-life-invalidation-assertion", "name": "Scoped, reasoned invalidation assertion", "description": "An appended assertion by an entitled party that a named scope should no longer be relied upon from a stated instant. The scope is exactly one of: the proof instance, the signer or key binding, the payload binding, or a named policy use. The assertion carries a coded and human-readable reason. It does not revoke a key or certificate, does not write a credential status list, does not delete content and does not alter the proof it concerns.", "source_refs": [ "SRC-091", "SRC-090", "SRC-052", "SRC-092" ], "questions": [ { "id": "sig-life-invalidation-scope-choice", "text": "Which single scope does this assertion target: the proof instance, the signer or key binding, the payload binding, or one named policy use?", "kind": "classification", "answer_data": [ "Scope code drawn from the closed set of four scopes", "Reference to the exact target record or binding within that scope", "Statement of what remains unaffected, in particular sibling co-signatures bound to the same payload", "Rule that a broader effect requires additional assertions, each separately reasoned" ] }, { "id": "sig-life-invalidation-entitlement", "text": "Who is entitled to assert invalidation for that scope, and what recorded evidence supports the entitlement?", "kind": "authority", "answer_data": [ "Asserting party reference and the role claimed", "Reference to the entitlement rule or delegation held by the authority model", "Evidence reference such as a designated-revoker arrangement or an authority record", "Handling rule for assertions from parties whose entitlement cannot be established, which are retained but marked unentitled" ] }, { "id": "sig-life-invalidation-effective-instant", "text": "From which instant does non-reliance apply, and does the assertion disturb conclusions that were reached before that instant?", "kind": "temporal", "answer_data": [ "Effective instant expressed with seconds and an explicit offset", "Separate assertion event time and observation time where they differ", "Rule stating whether the effect is prospective only or retroactive to the proof's creation, recorded explicitly per assertion", "Reference to proof-of-existence evidence establishing what was knowable before the effective instant" ] }, { "id": "sig-life-invalidation-non-effects", "text": "What does this assertion explicitly not do to the key, the certificate, any status list, the transparency log entry or the stored content?", "kind": "constraint", "answer_data": [ "Explicit non-effect statement enumerating key and certificate revocation, status-list publication, log mutation and content deletion", "Named owner model for each of those effects", "Rule that a related external revocation is recorded here only as a referenced supporting event", "Rule that the invalidated record itself remains stored and unaltered" ] }, { "id": "sig-life-invalidation-trigger", "text": "What triggering event or finding prompted the assertion, and how is the reason recorded so that a consumer can act on it?", "kind": "event", "answer_data": [ "Reason code from a governed list, such as key compromise, superseded binding, erroneous issuance or no longer applicable", "Human-readable reason text intended for the relying party", "Reference to the triggering event, incident or validation result", "Whether the reason is disclosable to all readers or restricted" ] } ], "data_elements": [ { "id": "sig-life-de-invalidation-scope", "name": "Invalidation scope", "description": "Closed-set code naming what is no longer to be relied upon: proof instance, signer or key binding, payload binding, or a named policy use.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-091", "SRC-090" ] }, { "id": "sig-life-de-invalidation-reason", "name": "Invalidation reason code and text", "description": "Governed reason code together with human-readable text, following the practice that a revocation-style assertion carries a machine reason and an explanatory string.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-091", "SRC-052" ] }, { "id": "sig-life-de-invalidation-effective-at", "name": "Invalidation effective instant", "description": "The instant from which non-reliance applies, recorded separately from the assertion event time and the observation time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-090", "SRC-009" ] }, { "id": "sig-life-de-asserting-party", "name": "Asserting party reference and entitlement evidence", "description": "Reference to the party making the assertion and to the evidence that the party is entitled to assert for the named scope.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-091", "SRC-092" ] }, { "id": "sig-life-de-invalidation-retroactivity", "name": "Retroactivity declaration", "description": "Explicit statement of whether the assertion applies prospectively from the effective instant or retroactively to the proof's creation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-090", "SRC-052" ] } ], "artifacts": [ { "id": "sig-life-art-invalidation-assertion-record", "name": "Proof invalidation assertion record", "description": "The appended, immutable record of one scoped invalidation assertion: scope code and target reference, reason code and text, asserting party and entitlement evidence, effective instant, retroactivity declaration, event and observation times, and any supporting external event references.", "media_or_form": [ "Signed assertion record appended to the proof's version history", "Statement registered with an external append-only service and referenced by receipt", "Structured invalidation statement expressed with provenance invalidation vocabulary", "Record in an adopting-Dimension store, retained alongside the unaltered target record" ], "serial": false, "identity_strategy": "Use the authoritative master-system identifier issued by the system of record that accepted the assertion. Where none exists, use a governed global identifier or IRI. Where neither exists, assign a UUID or ULID and mark it as locally assigned. The effective instant is never part of the identifier.", "source_refs": [ "SRC-090", "SRC-091", "SRC-092" ] } ], "inline_only_rationale": null }, { "id": "sig-life-supersession-link", "name": "Supersession and correction link with effective interval", "description": "A directed, append-only link stating that one proof or proof version replaces or corrects another, with a reason distinguishing correction of an error from routine replacement, and an effective interval indicating when the superseding record is the one to rely on. Supersession does not by itself change the superseded proof's cryptographic validity; where non-reliance is intended, a separate invalidation assertion is required.", "source_refs": [ "SRC-090", "SRC-092", "SRC-005", "SRC-004" ], "questions": [ { "id": "sig-life-supersession-direction-and-reason", "text": "Which record supersedes which, and is the link a correction of an error or a routine replacement?", "kind": "relationship", "answer_data": [ "Reference to the superseding record and to the superseded record, in an explicitly directed link", "Reason code distinguishing correction, routine replacement, re-issuance under changed circumstances and consolidation", "Cycle-prevention rule and the check applied before the link is appended", "Handling rule where the superseded record already carries a conflicting supersession link" ] }, { "id": "sig-life-supersession-effective-interval", "text": "Over which effective interval is the superseding record the one to rely on, and how are overlapping or gapped intervals reported?", "kind": "temporal", "answer_data": [ "Effective-from instant and optional effective-until instant, each with seconds and an explicit offset", "Rule for reporting an overlap between the superseded and superseding intervals rather than silently truncating either", "Rule for reporting a gap where neither record is effective", "Separate observation time at which the link was recorded" ] }, { "id": "sig-life-supersession-derivation", "text": "What derivation relationship holds between superseding and superseded content, and how much of the earlier content is carried forward?", "kind": "provenance", "answer_data": [ "Derivation kind indicating substantial content carried forward versus independent re-creation", "Statement of which pinned payload version each record binds to", "List of differences that motivated the supersession, where recorded", "Reference to the actor and operation that produced the superseding record" ] }, { "id": "sig-life-supersession-validity-effect", "text": "Does supersession by itself change the superseded proof's recorded validity, and what must be asserted separately if non-reliance is intended?", "kind": "state", "answer_data": [ "Explicit statement that supersession is a relation, not a validity verdict", "Requirement for a separate invalidation assertion where non-reliance is intended, with its own scope and reason", "Rule that the superseded record and its recorded validation outcomes remain unaltered and readable", "Reporting rule for consumers that encounter a superseded but not invalidated proof" ] }, { "id": "sig-life-supersession-projection", "text": "How is the supersession link expressed when the underlying mechanism supports only re-registration under the same issuer and subject, with no explicit replacement pointer?", "kind": "interoperability", "answer_data": [ "Mapping rule from the explicit link to same-issuer, same-subject re-registration ordering", "Rule that the explicit link is retained locally even where the projection cannot carry it", "Note that consumers of the weaker projection must evaluate the full statement history themselves", "Record of information loss detected during projection" ] } ], "data_elements": [ { "id": "sig-life-de-supersedes-reference", "name": "Supersedes reference", "description": "Directed reference from the superseding record to the record it replaces or corrects.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-090", "SRC-092" ] }, { "id": "sig-life-de-supersession-reason", "name": "Supersession reason", "description": "Coded reason distinguishing correction of an error from routine replacement, re-issuance or consolidation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-090", "SRC-005" ] }, { "id": "sig-life-de-effective-interval", "name": "Effective interval", "description": "Effective-from and optional effective-until instants over which the superseding record is the one to rely on.", "value_kind": "duration", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-090" ] }, { "id": "sig-life-de-derivation-kind", "name": "Derivation kind", "description": "Whether the superseding record carries substantial content forward from the superseded one or was created independently.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-090" ] } ], "artifacts": [ { "id": "sig-life-art-supersession-link-record", "name": "Proof supersession link record", "description": "The appended, immutable record of one directed supersession relation: superseding and superseded references, reason code, derivation kind, effective interval, actor reference, event and observation times, and any detected overlap or gap notes.", "media_or_form": [ "Directed link record appended to the proof's version history", "Provenance revision statement relating two proof records", "Re-registered statement under the same issuer and subject in an external append-only service, referenced by receipt", "Link row or document in an adopting-Dimension store" ], "serial": false, "identity_strategy": "Use the authoritative master-system identifier issued by the system of record that accepted the link. Where none exists, use a governed global identifier or IRI. Where neither exists, assign a UUID or ULID and mark it as locally assigned. Effective-interval endpoints are attributes of the link and never part of its identifier.", "source_refs": [ "SRC-090", "SRC-092", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-vop-verification", "name": "Verification Runs, Verdicts and Comparison", "description": "Everything needed to request, record, interpret and compare a verification of a digital signature or proof: the pinned inputs that make a run reproducible, the time basis and proofs of existence the verdict is anchored to, the separated verdict dimensions with machine-readable reasons, the run record and its report projections, and the disciplined comparison of two runs over the same subject.", "rationale": "Authoritative validation procedures treat a verification result as the output of a parameterised process, not as an intrinsic property of the signature: the outcome depends on validation time, trust anchors, algorithm constraints, revocation freshness and available proofs of existence, and is reported as an indication with a sub-indication rather than a boolean (SRC-061, SRC-095, SRC-043, SRC-013). A model that stores only a pass or fail flag is therefore unfalsifiable and non-reproducible, which is why the run inputs, the time basis and the per-dimension reasons are modelled as first-class context.", "source_refs": [ "SRC-061", "SRC-095", "SRC-043", "SRC-004", "SRC-013", "SRC-097" ], "layers": [ { "id": "sig-vop-inputs", "name": "Run Inputs and Time Basis", "description": "The determinacy surface of a verification: the parameters that must be fixed before evaluation, and the time values and proof-of-existence assertions the evaluation is anchored to.", "source_refs": [ "SRC-061", "SRC-009", "SRC-043", "SRC-003", "SRC-097" ], "findings": [ { "id": "sig-vop-run-request", "name": "Verification run request and determinacy pins", "description": "The complete set of caller-supplied and defaulted inputs that make a verification run reproducible: the validation or as-of time, the exact payload and payload version the proof is asserted to cover, the trust anchor set and the snapshot of it that was consulted, the cryptographic suite policy including algorithm sunset dates, the maximum permitted age of status evidence, and the pinned identity of the evaluating tool and its data sources. Path validation inputs are parameterised and time-dependent (SRC-043) and constraint groups differ per policy (SRC-013, SRC-097), so an unpinned run cannot be re-derived or contested.", "source_refs": [ "SRC-061", "SRC-043", "SRC-096", "SRC-013", "SRC-097" ], "questions": [ { "id": "sig-vop-q-run-inputs-complete", "text": "Which inputs must be pinned before a verification run is accepted as reproducible?", "kind": "constraint", "answer_data": [ "Required pin list with per-pin presence status", "Rejection reason when a required pin is absent", "Policy identifier that defines the required pin list" ] }, { "id": "sig-vop-q-payload-binding", "text": "Which exact payload version is the proof asserted to cover, and how is that version identified?", "kind": "identity", "answer_data": [ "Payload reference to the host record and its version identifier", "Digest algorithm and digest value used as fixity for that version", "Placement of the proof relative to the payload (detached, enveloped, enveloping)" ] }, { "id": "sig-vop-q-trust-store-pin", "text": "Which trust anchor set was consulted, and which snapshot of it applied at run time?", "kind": "provenance", "answer_data": [ "Trust anchor set reference and snapshot identifier or publication instant", "Source of the snapshot as declared by its publisher", "Whether the snapshot was retrieved live or replayed from a stored copy" ] }, { "id": "sig-vop-q-algorithm-policy", "text": "Under whose cryptographic suite policy, and with which sunset dates, was this run evaluated?", "kind": "authority", "answer_data": [ "Policy identifier and version", "Per-algorithm status (acceptable, deprecated, disallowed, legacy verification only) and sunset date", "Party accountable for the policy content" ] }, { "id": "sig-vop-q-freshness-window", "text": "What maximum age of certificate status evidence was permitted relative to the as-of time?", "kind": "temporal", "answer_data": [ "Freshness limit expressed as a duration, or an explicit statement that freshness was not constrained", "Actual age of each status object used", "Whether nextUpdate was present and honoured" ] } ], "data_elements": [ { "id": "sig-vop-de-validation-time", "name": "Validation (as-of) time", "description": "The instant the verification is evaluated against; determines certificate validity assessment and status evidence acceptance.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-061", "SRC-043", "SRC-013" ] }, { "id": "sig-vop-de-payload-binding", "name": "Payload binding reference", "description": "Reference to the host payload and the exact version or revision the proof covers, held as a reference into the host model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-004" ] }, { "id": "sig-vop-de-payload-fixity", "name": "Payload fixity value", "description": "Digest algorithm identifier and digest value used to confirm that the payload presented at verification is the version the proof covers. Fixity, not identity.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009", "SRC-066" ] }, { "id": "sig-vop-de-trust-anchor-pin", "name": "Trust anchor set pin", "description": "Reference to the trust anchor set or trust list plus the snapshot identifier or publication instant actually used.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-043", "SRC-013" ] }, { "id": "sig-vop-de-crypto-policy-pin", "name": "Cryptographic suite policy pin", "description": "Reference and version of the algorithm policy, including the per-algorithm sunset dates applied in this run.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-096", "SRC-097" ] }, { "id": "sig-vop-de-status-freshness-limit", "name": "Status evidence freshness limit", "description": "Maximum accepted age of revocation or status evidence relative to the as-of time; absence means unconstrained and must be recorded explicitly.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-044", "SRC-097" ] }, { "id": "sig-vop-de-tool-pin", "name": "Evaluating tool pin", "description": "Name, version and configuration digest of the software that produced the result, plus versions of any external data sources it consulted.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-013", "SRC-097" ] } ], "artifacts": [], "inline_only_rationale": "A run request is a parameter set, not a document: every element is either a scalar, a duration, or a reference into a model that owns the referenced object (trust anchor sets, policies, host payloads, tool inventories). Materialising it as an artifact would create a second, competing copy of trust-list and policy content that this model has no authority to maintain. The pins are therefore held inline on the run record and resolved by reference at read time." }, { "id": "sig-vop-time-basis", "name": "Time basis and proofs of existence", "description": "Separation of the distinct time values a verdict can be anchored to: the claimed signing time asserted by the signer, the best-signature-time derivable from trusted evidence, the validation or as-of time, and the instants at which each evidence object was produced versus observed. Signature validity turns on key status at signing time rather than verification time, and that determination requires independent time evidence (SRC-003); proofs of existence are carried by time-stamp tokens and evidence records (SRC-009, SRC-066) and are what allow a signature to remain assessable after certificate expiry or revocation (SRC-061, SRC-097).", "source_refs": [ "SRC-061", "SRC-009", "SRC-066", "SRC-003", "SRC-097" ], "questions": [ { "id": "sig-vop-q-time-anchor", "text": "Which time value is this verdict anchored to, and why was that value selected?", "kind": "temporal", "answer_data": [ "Selected anchor kind (claimed signing time, best-signature-time, validation time)", "Selection rule and the policy that mandated it", "Alternative anchors that were available but not used" ] }, { "id": "sig-vop-q-poe-source", "text": "Which referenced objects establish that the proof existed before a given instant?", "kind": "evidence", "answer_data": [ "List of proof-of-existence assertions with the covered object, the instant and the evidence reference", "Evidence kind (time-stamp token, archive time-stamp, evidence record, external attestation)", "Whether each proof-of-existence evidence object itself verified in this run" ] }, { "id": "sig-vop-q-claimed-vs-proven", "text": "How is an unproven claimed signing time kept distinguishable from a proven one?", "kind": "quality", "answer_data": [ "Assertion strength flag per time value (self-asserted, third-party attested, chained to a preserved evidence sequence)", "Evidence reference supporting any non-self-asserted value", "Statement recorded when no independent time evidence exists" ] }, { "id": "sig-vop-q-observation-time", "text": "When was each status or evidence object produced, and when was it observed and recorded here?", "kind": "provenance", "answer_data": [ "Production instant reported by the producing service", "Observation or ingestion instant recorded by this model", "Retrieval channel and whether the object was replayed from cache" ] } ], "data_elements": [ { "id": "sig-vop-de-claimed-signing-time", "name": "Claimed signing time", "description": "Time asserted within the proof by the signer or creator; carries no independent weight on its own.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] }, { "id": "sig-vop-de-best-signature-time", "name": "Best signature time", "description": "Earliest instant at which it can be trusted that the proof existed, derived from available proof-of-existence evidence.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-061", "SRC-097" ] }, { "id": "sig-vop-de-poe-assertion", "name": "Proof-of-existence assertion", "description": "Structured assertion naming the covered object, the instant proven, the supporting evidence reference and the evidence kind.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-evidence-produced-at", "name": "Evidence production time", "description": "Instant the referenced evidence object was generated by its producing service, as reported by that service.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-044" ] }, { "id": "sig-vop-de-evidence-observed-at", "name": "Evidence observation time", "description": "Instant this model retrieved or registered the evidence object, recorded separately from its production time.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-044", "SRC-095" ] } ], "artifacts": [], "inline_only_rationale": "Time values and proof-of-existence assertions are derived scalars and references over evidence objects that are owned elsewhere: the time-stamp token or evidence record is the artifact, and it belongs to the preservation-evidence finding or to the referenced trust service. Producing a separate time artifact here would duplicate that evidence and invite the two copies to diverge, so the time basis is stored inline on the run record and resolved against the referenced evidence units." } ] }, { "id": "sig-vop-verdict", "name": "Verdicts, Run Records and Comparison", "description": "How a verification result is expressed, stored and later compared: separated verdict dimensions with machine-readable reasons, an immutable run record with report projections, and a change-attributing comparison between runs.", "source_refs": [ "SRC-061", "SRC-095", "SRC-004", "SRC-096", "SRC-013" ], "findings": [ { "id": "sig-vop-verdict-dimensions", "name": "Separated verdict dimensions and machine-readable reasons", "description": "A verification result is recorded as independent dimensions rather than a single verdict: cryptographic integrity of the proof over the bound payload; trust path to an accepted anchor; completeness of supporting evidence; conformance to the pinned policy including algorithm constraints; identity or attribution of the asserted signer; and legal conclusion. Each dimension carries its own status and reason codes drawn from a declared code system. Authoritative validation procedures already distinguish failure from indeterminacy and require a sub-indication explaining which condition was not met (SRC-061, SRC-095, SRC-013), and non-PKIX suites report verification alongside separate warning and error lists (SRC-004). The legal dimension is always recorded as not determined by this model unless an external authority record is referenced.", "source_refs": [ "SRC-061", "SRC-095", "SRC-004", "SRC-013", "SRC-097" ], "questions": [ { "id": "sig-vop-q-dimension-set", "text": "Which verdict dimensions are reported separately, and what exactly does each one assert?", "kind": "classification", "answer_data": [ "Dimension name with a one-sentence scope statement per dimension", "Status per dimension (passed, failed, indeterminate, not evaluated)", "Explicit not-evaluated marking where a dimension was out of the run's remit" ] }, { "id": "sig-vop-q-reason-codes", "text": "Which machine-readable reason code and code system explains each non-passing dimension?", "kind": "interoperability", "answer_data": [ "Reason code value and the identifier and version of its code system", "Human-readable gloss carried alongside, never instead of, the code", "Mapping note where a code was translated from a different code system" ] }, { "id": "sig-vop-q-aggregation-rule", "text": "How may dimension results be combined, and what must never be inferred from a single dimension?", "kind": "decision", "answer_data": [ "Declared aggregation rule and the party that set it", "Explicit non-inference statements (for example cryptographic pass does not imply trust or attribution)", "Whether an aggregate summary was produced and by which rule version" ] }, { "id": "sig-vop-q-legal-dimension", "text": "Who owns the legal conclusion about this proof, and what does this model record in its place?", "kind": "authority", "answer_data": [ "Reference to the external authority, determination record or jurisdictional regime, when one exists", "Fixed not-determined-here status when no such record exists", "Factual inputs recorded for that external decision without a conclusion attached" ] } ], "data_elements": [ { "id": "sig-vop-de-dimension-result", "name": "Verdict dimension result", "description": "One dimension of the verdict: dimension name, status, ordered reason codes, and references to the evidence objects that drove the status.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-061", "SRC-095" ] }, { "id": "sig-vop-de-dimension-status", "name": "Dimension status", "description": "Coded status per dimension distinguishing passed, failed, indeterminate and not evaluated; indeterminate is never collapsed into failed.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-061", "SRC-013" ] }, { "id": "sig-vop-de-reason-code", "name": "Reason code", "description": "Machine-readable reason attached to a non-passing dimension, resolvable within a declared code system.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-095", "SRC-013" ] }, { "id": "sig-vop-de-reason-code-system", "name": "Reason code system reference", "description": "Identifier and version of the vocabulary a reason code belongs to, so codes remain resolvable across bindings.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-095", "SRC-004" ] }, { "id": "sig-vop-de-legal-conclusion-ref", "name": "External legal determination reference", "description": "Reference to a determination made by an authority outside this model; never a conclusion authored here.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-078" ] } ], "artifacts": [], "inline_only_rationale": "Dimension results are structured fields of a run record and are meaningless detached from the pinned inputs that produced them; the transportable document is the run record's report projection, declared in the run-record finding. Emitting dimension results as a standalone artifact would let a verdict circulate without its inputs, which is precisely the failure mode the separation of dimensions exists to prevent." }, { "id": "sig-vop-run-record", "name": "Verification run record and report projection", "description": "The stored record of one verification: run identity, the digest of the pinned inputs, the dimension results, references to every evidence object consulted, the asserting party, and the start and end instants of evaluation. The record is an observation attributable to a party at a time, not a warrant of validity, and it is projected into report bindings for exchange. Standardised report structures carry the validation status, signer information, constraint evaluation, time information and the validation objects used (SRC-095); reference implementations show that a single run legitimately yields several non-equivalent report projections at different levels of detail (SRC-013, SRC-097).", "source_refs": [ "SRC-061", "SRC-095", "SRC-004", "SRC-013", "SRC-097" ], "questions": [ { "id": "sig-vop-q-run-identity", "text": "How is a single verification run identified so it can be cited later without ambiguity?", "kind": "identity", "answer_data": [ "Run identifier and the system that issued it", "Digest over the canonical pinned input set", "Subject reference identifying the proof and payload version verified" ] }, { "id": "sig-vop-q-run-immutability", "text": "Under what conditions, if any, may a stored run record be changed after it is written?", "kind": "lifecycle", "answer_data": [ "Append-only rule with the permitted correction mechanism", "Superseding record reference and correction reason when a record is withdrawn", "States a run record can occupy (provisional, complete, withdrawn) and who may set them" ] }, { "id": "sig-vop-q-report-selfdescription", "text": "What must a report projection of a run contain to remain self-describing away from its store?", "kind": "composition", "answer_data": [ "Mandatory sections: subject reference, pinned inputs, dimension results with reason codes, asserting party, times", "Projection binding identifier and its version", "Back-reference to the run identifier and the input digest" ] }, { "id": "sig-vop-q-run-asserter", "text": "Which party asserted this run, and under what declared competence or accreditation?", "kind": "ownership", "answer_data": [ "Asserting party identifier and role", "Declared competence, accreditation or service-level basis, or an explicit none", "Whether the asserting party also operated the signing or timestamping service (conflict flag)" ] }, { "id": "sig-vop-q-run-availability", "text": "How long must a run record stay retrievable to support later comparison and review?", "kind": "retention", "answer_data": [ "Minimum availability period and the rule reference that sets it", "Owner of the retention rule outside this model", "Consequence recorded when a prior run is no longer retrievable" ] } ], "data_elements": [ { "id": "sig-vop-de-run-id", "name": "Verification run identifier", "description": "Stable identifier for one run, issued by the authoritative verification system or assigned by the adopting Dimension.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-095", "SRC-013" ] }, { "id": "sig-vop-de-input-digest", "name": "Pinned input digest", "description": "Digest over the canonical serialisation of the pinned run inputs, enabling detection of any later input drift.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-097" ] }, { "id": "sig-vop-de-run-asserter", "name": "Asserting party reference", "description": "Reference to the party that ran and stands behind the verification, with its declared role.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-095", "SRC-078" ] }, { "id": "sig-vop-de-run-executed-at", "name": "Run execution instants", "description": "Start and completion instants of the evaluation, recorded separately from the as-of validation time.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-095", "SRC-003" ] }, { "id": "sig-vop-de-consulted-object-ref", "name": "Consulted validation object reference", "description": "Reference to each certificate, status response, time-stamp token or evidence record consulted during the run.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-095", "SRC-043", "SRC-044" ] }, { "id": "sig-vop-de-run-state", "name": "Run record state", "description": "State of the record itself: provisional, complete or withdrawn-and-superseded; never a state of the signature.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-095", "SRC-078" ] } ], "artifacts": [ { "id": "sig-vop-art-validation-report", "name": "Signature validation report", "description": "A self-describing projection of one run record for exchange or human review, carrying the subject reference, pinned inputs, per-dimension results with reason codes, consulted validation objects, asserting party and times. Multiple projections of differing detail may exist for the same run and are never treated as independent verdicts.", "media_or_form": [ "structured validation report following a standardised report schema", "detailed technical report enumerating each evaluation step", "concise summary report for human review", "verification result object in a proof-suite native form" ], "serial": true, "identity_strategy": "Identified by the run identifier issued by the authoritative verification system, plus a projection binding identifier and projection sequence number. Where no master-system identifier exists, the adopting Dimension assigns a UUID or ULID. Filenames, report titles and dates are never used as identity.", "source_refs": [ "SRC-095", "SRC-004", "SRC-013", "SRC-097" ] } ], "inline_only_rationale": null }, { "id": "sig-vop-run-comparison", "name": "Comparison of verification runs and change attribution", "description": "The disciplined comparison of two runs over the same proof and payload version, producing a per-dimension difference set in which each difference is attributed to a cause class: elapsed time and newly available proofs of existence, trust anchor set change, status evidence change, policy change, algorithm sunset, evidence added by preservation, or evaluating tool change. The earlier verdict is never overwritten or invalidated; it remains a true statement about the inputs that produced it. Cause classes follow directly from the parameters that authoritative procedures make variable (SRC-061, SRC-043, SRC-096, SRC-097).", "source_refs": [ "SRC-061", "SRC-043", "SRC-096", "SRC-013", "SRC-097" ], "questions": [ { "id": "sig-vop-q-comparability", "text": "Are these two runs comparable at all, and against which invariants was that decided?", "kind": "validation", "answer_data": [ "Invariant check results for subject proof identity, payload version and fixity value", "Comparability verdict with a refusal reason when invariants differ", "Note recording any deliberate cross-version comparison and its limits" ] }, { "id": "sig-vop-q-change-cause", "text": "Which cause class explains each dimension difference between the two runs?", "kind": "relationship", "answer_data": [ "Per-dimension difference with an assigned cause class", "Evidence reference supporting the assignment (changed pin, added evidence unit, new status object)", "Unattributed differences flagged rather than forced into a class" ] }, { "id": "sig-vop-q-no-supersession", "text": "Why does a later run never overwrite or retract the earlier recorded verdict?", "kind": "state", "answer_data": [ "Statement that each run is scoped to its own pinned inputs", "Ordering relation between runs without an implied precedence of truth", "Rule identifying which run a consumer should rely on for a given question and as-of time" ] }, { "id": "sig-vop-q-drift-measure", "text": "How much of the observed change is attributable to non-cryptographic causes?", "kind": "measurement", "answer_data": [ "Count of differences per cause class", "Flag when the cryptographic dimension is unchanged while other dimensions moved", "Comparison window between the two run execution instants" ] } ], "data_elements": [ { "id": "sig-vop-de-compared-run-ref", "name": "Compared run reference", "description": "Reference to each of the two run records being compared, in a declared earlier and later order.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-095", "SRC-013" ] }, { "id": "sig-vop-de-invariant-check", "name": "Comparability invariant check", "description": "Result of checking that both runs address the same proof, the same payload version and the same fixity value.", "value_kind": "boolean", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-066", "SRC-097" ] }, { "id": "sig-vop-de-dimension-delta", "name": "Dimension difference", "description": "One dimension whose status or reason set differs between the two runs, with both prior and later values retained.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-061", "SRC-095" ] }, { "id": "sig-vop-de-change-cause-class", "name": "Change cause class", "description": "Coded attribution of a difference to elapsed time, trust anchor change, status evidence change, policy change, algorithm sunset, added preservation evidence, tool change or unattributed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-043", "SRC-096", "SRC-097" ] } ], "artifacts": [ { "id": "sig-vop-art-run-comparison", "name": "Verification run comparison record", "description": "A record of one comparison between two run records: the invariant checks that established comparability, the per-dimension differences with prior and later values, the assigned cause classes, and any differences left unattributed. It adds interpretation and never restates either run's verdict as superseded.", "media_or_form": [ "structured comparison or delta record", "human-readable difference summary for review" ], "serial": true, "identity_strategy": "Identified by the comparison identifier issued by the system of record, ordered by comparison sequence and always carrying the two compared run identifiers. Where no master-system identifier exists, the adopting Dimension assigns a UUID or ULID.", "source_refs": [ "SRC-061", "SRC-096", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "sig-vop-preservation", "name": "Preservation Evidence, Projection and Disposition Readiness", "description": "Everything needed to keep a proof assessable over time and to move or retire it responsibly: additive preservation and renewal evidence, the calculated assessment of evidence coverage and renewal need, export projection into a selected binding with declared losses and separated access, and the reported readiness of a proof for disposition.", "rationale": "Cryptographic algorithms weaken over archival periods, so long-term assessability depends on adding time-stamp and evidence records before compromise rather than on the original proof alone, and renewal is defined as an additive operation over the existing evidence sequence (SRC-066, SRC-067). Preservation services are external providers with their own profiles, goals and object identifiers (SRC-072, SRC-098), and disposal is a distinct lifecycle category with its own program and system requirements (SRC-078). Bindings differ in the semantics they can carry, and an unrecognised critical extension invalidates a signature rather than degrading it (SRC-007), which makes projection loss a first-class fact.", "source_refs": [ "SRC-009", "SRC-066", "SRC-067", "SRC-007", "SRC-072", "SRC-098", "SRC-078" ], "layers": [ { "id": "sig-vop-evidence", "name": "Additive Preservation Evidence and Renewal", "description": "Evidence units added over the life of a proof to keep it assessable, and the derived assessment of whether current evidence still covers it.", "source_refs": [ "SRC-009", "SRC-066", "SRC-067", "SRC-096", "SRC-072" ], "findings": [ { "id": "sig-vop-evidence-unit", "name": "Preservation evidence unit and renewal record", "description": "One unit of evidence added to keep a proof assessable: an archive time-stamp token, an evidence record with its archive time-stamp chains and sequence, collected validation material, or evidence returned by an external preservation service. Units are recorded append-only and never modify the original proof bytes. Two renewal kinds are distinguished because they cover different risks: re-stamping the previous time-stamp addresses signature-algorithm weakening, while re-hashing the data objects together with the prior evidence addresses digest-algorithm weakening and starts a new chain (SRC-066, SRC-067).", "source_refs": [ "SRC-009", "SRC-066", "SRC-067", "SRC-072", "SRC-098" ], "questions": [ { "id": "sig-vop-q-evidence-additivity", "text": "What guarantees that registering this evidence unit leaves the original proof byte-identical?", "kind": "constraint", "answer_data": [ "Pre-registration and post-registration fixity values of the original proof", "Storage rule prohibiting in-place modification of the original proof", "Rejection reason recorded when a submitted unit would require rewriting the proof" ] }, { "id": "sig-vop-q-renewal-kind", "text": "Which renewal kind does this unit represent, and what does it re-cover?", "kind": "process", "answer_data": [ "Renewal kind (initial evidence, time-stamp renewal, hash-tree renewal, external preservation augmentation)", "Set of objects re-covered by the unit", "Digest and signature algorithms the unit introduces" ] }, { "id": "sig-vop-q-evidence-chaining", "text": "How does this unit chain to the evidence already recorded for the same proof?", "kind": "composition", "answer_data": [ "Predecessor unit reference and chain or sequence position", "Whether the unit continues an existing chain or opens a new one", "Detected break in continuity, if any, with the affected interval" ] }, { "id": "sig-vop-q-evidence-origin", "text": "Which external service produced this evidence unit, and under which declared policy?", "kind": "provenance", "answer_data": [ "Producing service reference and its policy or profile identifier", "Preservation object identifier or token serial issued by that service", "Production instant reported by the service and observation instant recorded here" ] }, { "id": "sig-vop-q-evidence-parameters", "text": "Which digest algorithm and canonicalization does this unit depend on for later verification?", "kind": "evidence", "answer_data": [ "Digest algorithm identifiers used across the unit", "Canonicalization or transform method identifier where the binding requires one", "Known status of each algorithm under the pinned algorithm policy" ] } ], "data_elements": [ { "id": "sig-vop-de-evidence-unit-id", "name": "Evidence unit identifier", "description": "Identifier of the evidence unit, preferring the identifier issued by the producing preservation or timestamping service.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-098" ] }, { "id": "sig-vop-de-evidence-kind", "name": "Evidence unit kind", "description": "Coded kind of unit: time-stamp token, archive time-stamp, evidence record, collected validation material, or service-issued preservation evidence.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-067", "SRC-072" ] }, { "id": "sig-vop-de-renewal-kind", "name": "Renewal kind", "description": "Whether the unit is initial evidence, a time-stamp renewal, a hash-tree renewal or an external augmentation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-evidence-coverage-set", "name": "Evidence coverage set", "description": "References to every object the unit demonstrably covers, including the proof, the payload version and prior evidence units.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-evidence-chain-position", "name": "Chain and sequence position", "description": "Position of the unit within its archive time-stamp chain and of that chain within the sequence.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-evidence-producer-ref", "name": "Producing service reference", "description": "Reference to the external timestamping or preservation service and the policy or profile under which the unit was issued.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-072", "SRC-098" ] } ], "artifacts": [ { "id": "sig-vop-art-evidence-unit", "name": "Preservation evidence unit", "description": "The stored evidence object itself, retained byte-exact as received from its producing service, together with the registration metadata that places it in the chain and sequence for a given proof. Registration records the object; it does not generate, re-sign or re-time it.", "media_or_form": [ "time-stamp token as issued by a timestamping authority", "evidence record in an ASN.1 binding", "evidence record in an XML binding", "archive time-stamp attribute carried inside a signature container", "preservation evidence object returned by an external preservation service" ], "serial": true, "identity_strategy": "Identified by the identifier issued by the producing service (for example the preservation object identifier or the token serial number scoped to that authority). Where no such identifier exists, the adopting Dimension assigns a UUID or ULID and records the producing service reference alongside. Sequence position is ordering metadata, never identity, and the production date is never used as an identifier.", "source_refs": [ "SRC-009", "SRC-066", "SRC-067", "SRC-098" ] } ], "inline_only_rationale": null }, { "id": "sig-vop-renewal-assessment", "name": "Evidence coverage and renewal-need assessment", "description": "A calculated, always re-derivable assessment of whether existing evidence still covers a proof: the interval currently covered, discontinuities in the chain, the sunset horizon of every digest and signature algorithm appearing in the chain under the pinned policy, and the latest date by which a further evidence unit must be obtained for coverage to remain unbroken. Renewal must occur before the relevant algorithm weakens (SRC-066), algorithm status changes over time and differs between generation and verification (SRC-096), and implementations distinguish hard failure from advisory warning around sunset dates (SRC-097). The assessment recommends; obtaining evidence is an external service action.", "source_refs": [ "SRC-066", "SRC-067", "SRC-096", "SRC-097", "SRC-072" ], "questions": [ { "id": "sig-vop-q-coverage-window", "text": "Through which interval is this proof currently covered by recorded evidence?", "kind": "temporal", "answer_data": [ "Coverage start and end instants derived from the evidence sequence", "Assessment as-of time and the algorithm policy version used", "Explicit uncovered statement when no evidence unit exists" ] }, { "id": "sig-vop-q-renewal-trigger", "text": "Which condition would trigger a renewal recommendation, and at what horizon?", "kind": "event", "answer_data": [ "Trigger condition (algorithm sunset, coverage expiry, policy change, chain break)", "Recommended-by date and the lead time applied", "Severity distinguishing advisory from blocking" ] }, { "id": "sig-vop-q-chain-gap", "text": "Where are the discontinuities or weak links in the recorded evidence chain?", "kind": "quality", "answer_data": [ "Interval and predecessor or successor references for each detected gap", "Units relying on an algorithm now disallowed for verification", "Confidence note where a gap cannot be distinguished from missing records" ] }, { "id": "sig-vop-q-renewal-owner", "text": "Which party is accountable for acting on a renewal recommendation?", "kind": "ownership", "answer_data": [ "Accountable party reference and its role", "External preservation service that would supply the evidence", "Escalation path recorded when the recommendation lapses unaddressed" ] } ], "data_elements": [ { "id": "sig-vop-de-coverage-interval", "name": "Evidence coverage interval", "description": "Derived start and end instants of continuous evidence coverage for the proof.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-algorithm-horizon", "name": "Algorithm sunset horizon", "description": "Per-algorithm date after which the pinned policy no longer accepts the algorithm, together with the algorithm's current status.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-096", "SRC-097" ] }, { "id": "sig-vop-de-renewal-by-date", "name": "Renewal-by date", "description": "Latest date by which a further evidence unit must be obtained for coverage to remain unbroken.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-066", "SRC-096" ] }, { "id": "sig-vop-de-chain-gap", "name": "Evidence chain gap", "description": "One detected discontinuity, with its interval and the units on either side.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "id": "sig-vop-de-assessment-basis", "name": "Assessment basis", "description": "As-of time, algorithm policy version and evidence set revision the assessment was computed from.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-096", "SRC-097" ] } ], "artifacts": [], "inline_only_rationale": "This assessment is entirely derived from the registered evidence units and the pinned algorithm policy, and it goes stale the moment either changes or the clock advances. Persisting it as an artifact would create a document that looks like preservation evidence but carries none, inviting consumers to rely on a stale renewal-by date. It is therefore held as inline computed context that must be recomputed with a stated as-of time and policy version on every read." } ] }, { "id": "sig-vop-projection", "name": "Export Projection and Disposition Readiness", "description": "Moving a proof and its evidence into another binding without silent semantic loss, and reporting whether the proof and its evidence are ready to be retired.", "source_refs": [ "SRC-095", "SRC-007", "SRC-004", "SRC-072", "SRC-078" ], "findings": [ { "id": "sig-vop-export-projection", "name": "Export projection, access separation and loss register", "description": "Projection of a proof and selected evidence into a target binding, where authorisation to disclose the payload and authorisation to disclose signer identity are evaluated separately, every semantic the target binding cannot carry is enumerated in a loss register, and any unsupported critical semantic causes refusal rather than silent downgrade. The refusal rule follows the established treatment of unrecognised critical extensions as invalidating rather than ignorable (SRC-007); payload separation follows detached-payload practice (SRC-007) and the report-object model that carries validation objects independently of the signed document (SRC-095). An exported proof asserts nothing about its own verification: any verification statement must travel as a separately identified run record.", "source_refs": [ "SRC-095", "SRC-067", "SRC-007", "SRC-004", "SRC-013" ], "questions": [ { "id": "sig-vop-q-export-access-split", "text": "Which authorisation covers the payload in this export, and which covers signer identity?", "kind": "access", "answer_data": [ "Separate authorisation references for payload disclosure and for signer or verification-method disclosure", "Resulting export mode (payload included, detached, or reference only) and identity mode (full, pseudonymised, withheld)", "Requesting party and the stated purpose of the export" ] }, { "id": "sig-vop-q-projection-loss", "text": "Which semantics are lost, approximated or renamed in the target binding?", "kind": "interoperability", "answer_data": [ "Loss register entry per affected semantic with its loss class (dropped, approximated, renamed, reordered)", "Target binding identifier and version", "Effect on later verifiability stated per entry" ] }, { "id": "sig-vop-q-critical-reject", "text": "Which unsupported critical semantics force this export to be refused outright?", "kind": "exception", "answer_data": [ "List of critical semantics the target binding cannot carry", "Refusal decision with a machine-readable refusal code", "Permitted alternative bindings, where any exist" ] }, { "id": "sig-vop-q-verification-non-implication", "text": "What statement must accompany an export so that presence is never read as validity?", "kind": "definition", "answer_data": [ "Fixed non-implication statement carried with every export", "Reference to a run record when a verification statement is deliberately included", "Absence marker recorded when no run record accompanies the export" ] }, { "id": "sig-vop-q-detached-payload", "text": "How is a detached payload referenced so the export stays verifiable at its destination?", "kind": "composition", "answer_data": [ "Payload reference, version identifier and fixity value carried in the export", "Retrieval hint or channel for the payload, where disclosure permits one", "Statement of what the recipient must supply to complete verification" ] } ], "data_elements": [ { "id": "sig-vop-de-export-id", "name": "Export identifier", "description": "Identifier of one export event, distinct from the identity of the proof and of any run record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-095", "SRC-078" ] }, { "id": "sig-vop-de-target-binding", "name": "Target binding reference", "description": "Identifier and version of the serialisation or container binding the proof is projected into.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-067", "SRC-007" ] }, { "id": "sig-vop-de-payload-disclosure-mode", "name": "Payload disclosure mode", "description": "Whether the payload is embedded, detached with a reference, or withheld entirely from the export.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-095" ] }, { "id": "sig-vop-de-identity-disclosure-mode", "name": "Signer identity disclosure mode", "description": "Whether signer identity and verification-method details are included, reduced or withheld, evaluated independently of payload disclosure.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-095" ] }, { "id": "sig-vop-de-loss-entry", "name": "Projection loss entry", "description": "One semantic lost, approximated, renamed or reordered by the projection, with its loss class and stated effect on verifiability.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-067", "SRC-007" ] }, { "id": "sig-vop-de-export-refusal", "name": "Export refusal record", "description": "Machine-readable refusal code and the unsupported critical semantics that caused an export to be declined.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "sig-vop-art-export-package", "name": "Projected proof export package", "description": "The materialised export in the selected target binding, containing the proof, the evidence units authorised for inclusion, the payload or a detached payload reference according to the disclosure mode, and the fixed statement that presence of the proof implies nothing about its verification.", "media_or_form": [ "detached, enveloped or enveloping signature serialisation", "signature container carrying collected validation material", "evidence record binding accompanying the exported proof", "verification result envelope referencing a run record" ], "serial": true, "identity_strategy": "Identified by the export identifier issued by the exporting system of record, carrying the subject proof identifier and the target binding identifier and version. Where no master-system identifier exists, the adopting Dimension assigns a UUID or ULID. Export timestamps and file names are metadata, never identity.", "source_refs": [ "SRC-095", "SRC-067", "SRC-007", "SRC-004" ] }, { "id": "sig-vop-art-loss-register", "name": "Projection loss register", "description": "The enumerated record of every semantic the target binding could not carry faithfully, classified as dropped, approximated, renamed or reordered, with the stated effect of each on later verifiability, plus any refusal decision and its code. Travels with the export package and is never merged into it.", "media_or_form": [ "structured loss register", "tabular loss list for human review" ], "serial": true, "identity_strategy": "Identified by the export identifier it belongs to plus a register sequence number; it has no independent identity and is void without its export package.", "source_refs": [ "SRC-067", "SRC-007", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "sig-vop-disposition-readiness", "name": "Disposition readiness report", "description": "A reported readiness state for retiring a proof and its evidence, combining the host record's lifecycle state, the applicable retention rule reference, any active legal hold or disposition freeze, outstanding preservation obligations from an external preservation arrangement, and blocking inbound references such as evidence units or run records that depend on the proof. Disposal is a distinct lifecycle category with its own program and system requirements and its own freeze semantics (SRC-078); preservation arrangements impose their own obligation periods and their own deletion surface (SRC-072, SRC-098). This model reports conditions and never executes, authorises or schedules deletion.", "source_refs": [ "SRC-066", "SRC-097", "SRC-072", "SRC-098", "SRC-078" ], "questions": [ { "id": "sig-vop-q-blocking-conditions", "text": "Which conditions currently block disposition of this proof and its evidence?", "kind": "state", "answer_data": [ "Enumerated blocking conditions with a per-condition source reference", "Overall readiness state (blocked, conditionally ready, ready) and the as-of time", "Condition whose resolution would change the state first" ] }, { "id": "sig-vop-q-hold-reference", "text": "Which legal hold or disposition freeze applies, and which party owns it?", "kind": "authority", "answer_data": [ "Hold or freeze reference and its issuing authority", "Scope of the hold over the proof, the payload and the evidence units", "Owner responsible for release, held outside this model" ] }, { "id": "sig-vop-q-retention-basis", "text": "Which retention rule and which host record govern the retention period here?", "kind": "retention", "answer_data": [ "Retention rule reference and the model that owns it", "Host record reference whose retention the proof inherits", "Any longer obligation imposed by a preservation arrangement" ] }, { "id": "sig-vop-q-residual-reference", "text": "What minimal reference must survive disposition so dependent records stay consistent?", "kind": "lifecycle", "answer_data": [ "Tombstone content: proof identifier, subject reference, disposition reason, effective instant", "Records that would otherwise dangle (run records, comparison records, evidence chains)", "Rule reference mandating the tombstone" ] }, { "id": "sig-vop-q-execution-owner", "text": "Which system executes the disposal, and which system records that it happened?", "kind": "process", "answer_data": [ "Executing system reference outside this model", "Recording system for the disposal event, outside this model", "Confirmation signal this model expects back and the field it updates" ] } ], "data_elements": [ { "id": "sig-vop-de-readiness-state", "name": "Disposition readiness state", "description": "Coded readiness state (blocked, conditionally ready, ready) valid only as of a stated instant.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-078" ] }, { "id": "sig-vop-de-blocking-condition", "name": "Blocking condition", "description": "One condition preventing disposition, with its class (host lifecycle, retention, legal hold, preservation obligation, blocking reference) and its source reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-072", "SRC-078" ] }, { "id": "sig-vop-de-retention-rule-ref", "name": "Retention rule reference", "description": "Reference to the retention rule or schedule governing the proof, owned by the records model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-078" ] }, { "id": "sig-vop-de-hold-ref", "name": "Legal hold or freeze reference", "description": "Reference to an active hold or disposition freeze and its issuing authority, mirrored here read-only.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-078" ] }, { "id": "sig-vop-de-blocking-reference", "name": "Blocking inbound reference", "description": "Reference to a dependent record, such as an evidence unit, run record or comparison, that would be orphaned by disposition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-066", "SRC-097" ] }, { "id": "sig-vop-de-readiness-as-of", "name": "Readiness as-of time", "description": "Instant at which the readiness state was computed; the state carries no validity beyond it.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-078", "SRC-003" ] } ], "artifacts": [ { "id": "sig-vop-art-disposition-readiness", "name": "Disposition readiness report", "description": "A dated statement of readiness for a named proof and its evidence set, listing every blocking condition with its class and source reference, the retention and hold references relied on, the dependent records that would be affected, and an explicit note that execution of disposal and recording of the disposal event lie outside this model.", "media_or_form": [ "structured readiness statement", "review-ready summary for a disposition reviewer" ], "serial": true, "identity_strategy": "Identified by the readiness report identifier issued by the system of record, carrying the subject proof identifier and a report sequence number; the as-of time is content, never identity. Where no master-system identifier exists, the adopting Dimension assigns a UUID or ULID.", "source_refs": [ "SRC-072", "SRC-098", "SRC-078" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "sig-core-fn-register-proof", "name": "Register a proof record", "description": "Create an identified proof record bound to exactly one host representation, capturing kind, method, proof value and the observation instant.", "inputs": [ "host representation reference", "binding mode code", "proof kind code", "method identifier", "serialized proof object", "source system reference" ], "outputs": [ "proof identifier", "capture digest", "record observation instant", "initial verification status of not-verified" ], "preconditions": [ "The host representation reference resolves", "An authoritative or governed identifier is available, or the reason for minting a Dimension identifier is recorded", "The proof value can be captured byte-exact" ], "effects": [ "A proof record exists in state issued with an explicit not-verified status", "The serialized proof object is stored with its capture digest" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-007" ] }, { "id": "sig-core-fn-classify-proof-kind", "name": "Classify proof kind", "description": "Assign an explicit proof kind and origination capability so that MACs, digests, seals, time-stamp tokens and selective-disclosure proofs are never normalised into digital signature.", "inputs": [ "proof record reference", "container profile code", "method identifier" ], "outputs": [ "proof kind code", "origination capability code", "external type identifiers" ], "preconditions": [ "The kind enumeration bound by the adopting Dimension is loaded" ], "effects": [ "The record carries an explicit kind and may not be treated as a digital signature unless classified as one", "Origination capability is available to downstream consumers" ], "source_refs": [ "SRC-006", "SRC-008", "SRC-011" ] }, { "id": "sig-core-fn-declare-method-and-parameters", "name": "Declare method and parameters", "description": "Record the algorithm or cryptosuite identifier, hash function, parameter set and variant options, together with whether the method identifier is cryptographically protected.", "inputs": [ "proof record reference", "method identifier", "hash identifier", "parameter values" ], "outputs": [ "normalised method declaration", "method protected flag", "deprecated-method warning where applicable" ], "preconditions": [ "The method identifier resolves in a named registry", "The registry version used is recorded" ], "effects": [ "Verification inputs are reproducible from the record", "Proofs using a method past a published sunset date are flagged without being altered" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] }, { "id": "sig-core-fn-bind-verification-method-reference", "name": "Bind verification-method reference", "description": "Attach a resolvable reference to the verification method, its asserted controller and any embedded hint, without importing key or credential content.", "inputs": [ "proof record reference", "verification method reference", "reference form code", "embedded hint set" ], "outputs": [ "stored verification-method reference", "hint coverage flag", "explicit non-establishment list" ], "preconditions": [ "The reference form is one the adopting Dimension permits", "No secret material is present in the input" ], "effects": [ "The proof can be routed to a verifier", "The record states explicitly what the reference does not establish about key trust, currency or revocation" ], "source_refs": [ "SRC-004", "SRC-007", "SRC-010" ] }, { "id": "sig-core-fn-declare-purpose-and-properties", "name": "Declare purpose and asserted properties", "description": "Record the declared proof purpose or commitment type together with a per-property declaration of which security and legal properties are and are not asserted, and on what basis.", "inputs": [ "proof record reference", "proof purpose code", "commitment type code", "asserted property set", "per-property basis set" ], "outputs": [ "purpose declaration", "asserted property matrix", "explicit non-asserted property list" ], "preconditions": [ "Every asserted property has a declared basis", "Legal effect, if listed at all, carries an external forum reference and no local determination" ], "effects": [ "Consumers cannot infer authorization, approval or legal effect from a cryptographic outcome", "Non-repudiation support is recorded only with its declared preconditions" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-012" ] }, { "id": "sig-core-fn-compose-proof-relationship", "name": "Compose proof relationship", "description": "Record the composition pattern, dependency edges and participation threshold linking this proof to other proofs over the same host.", "inputs": [ "proof record reference", "composition pattern code", "member or previous proof references", "required participant count" ], "outputs": [ "composition declaration", "dependency edge list", "threshold satisfied flag" ], "preconditions": [ "Ordered patterns supply a dependency target for every non-initial member", "Order claims cite order evidence rather than a signer-supplied time" ], "effects": [ "Independent co-signature sets, ordered chains, endorsements and threshold proofs remain distinguishable", "Partial satisfaction is representable without implying an aggregate outcome" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-007" ] }, { "id": "sig-core-fn-record-verification-outcome", "name": "Record an externally produced verification outcome", "description": "Ingest a verification outcome produced by an external signature validation application and append it as a status entry. This function performs no cryptographic operation, applies no validation policy and makes no acceptance decision.", "inputs": [ "proof record reference", "verification status code", "sub-status code", "evaluation instant", "verifier reference", "validation policy reference", "validation report reference" ], "outputs": [ "appended status entry", "status reliance limit", "coverage caveat note" ], "preconditions": [ "The outcome originates from an identified external verifier", "The evaluation instant and the record observation instant are supplied separately" ], "effects": [ "The status history gains an append-only entry recorded verbatim", "No prior status entry is modified or removed", "No enforcement or acceptance action is taken by this model" ], "source_refs": [ "SRC-004", "SRC-013" ] }, { "id": "sig-core-fn-transition-proof-state", "name": "Transition proof record state", "description": "Move the proof record between permitted states, recording actor, instant, reason and any external event that triggered the change.", "inputs": [ "proof record reference", "target state code", "reason code", "triggering event reference", "actor reference" ], "outputs": [ "updated proof state", "state transition record" ], "preconditions": [ "The transition is in the permitted set for the current state", "The actor holds the role authorised for that transition" ], "effects": [ "The record reflects the new state with its entry instant", "Withdrawal is recorded without asserting revocation of any key or credential" ], "source_refs": [ "SRC-004", "SRC-013" ] }, { "id": "sig-core-fn-project-proof-to-profile", "name": "Project a proof record to a container profile", "description": "Emit a container-profile projection of the format-neutral proof record for exchange, reusing the stored proof value without re-serializing it.", "inputs": [ "proof record reference", "target container profile code", "requested field subset" ], "outputs": [ "container-profile projection", "unmapped field report", "capture digest of the emitted proof value" ], "preconditions": [ "The stored capture digest re-checks successfully", "The target profile can express the recorded proof kind and method" ], "effects": [ "An interoperable projection is produced without altering canonical semantics", "Fields with no target-profile equivalent are reported rather than silently dropped" ], "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-008" ] }, { "id": "sig-payload-fn-declare-protected-subject", "name": "Declare protected subject", "description": "Create or supersede the descriptor naming the unit placed under protection, its topology relative to the proof and its declared boundary.", "inputs": [ "host record reference", "protected subject kind", "envelope topology", "subject boundary statement" ], "outputs": [ "protected subject descriptor", "descriptor identifier", "event time and observation time" ], "preconditions": [ "The host record reference resolves through the referenced host model", "The subject kind is drawn from the governed classifier set" ], "effects": [ "A protected subject descriptor exists and can be cited by binding, digest and scope records", "No change is made to the host record" ], "source_refs": [ "SRC-006", "SRC-016", "SRC-004" ] }, { "id": "sig-payload-fn-record-binding-descriptor", "name": "Record payload binding descriptor", "description": "Record whether the payload is bound directly or by digest reference, its carriage and encoding, its locators, and any external-resource pin.", "inputs": [ "protected subject descriptor identifier", "binding mode", "payload carriage and encoding flag", "reference locators", "external resource pin values" ], "outputs": [ "payload binding descriptor", "external resource pin records", "guarantee limitation statement" ], "preconditions": [ "A protected subject descriptor exists", "For a detached payload, a payload supply contract reference is present" ], "effects": [ "The binding mode and its limits are recorded for relying parties", "The descriptor becomes the anchor for digest evidence and scope manifests" ], "source_refs": [ "SRC-014", "SRC-006", "SRC-008", "SRC-016", "SRC-018" ] }, { "id": "sig-payload-fn-declare-protection-scope", "name": "Declare protection scope", "description": "Record whether the whole object or a selected part is protected and enumerate included and excluded regions in a named selection language.", "inputs": [ "payload binding descriptor identifier", "scope mode", "selection expression language", "included and excluded region descriptors" ], "outputs": [ "protected scope manifest", "unprotected remainder statement", "excluded-content constraint set" ], "preconditions": [ "A payload binding descriptor exists", "Every excluded region carries a constraint on what it may contain" ], "effects": [ "An independent party can reconstruct the identical digest input selection", "The unprotected remainder is stated rather than assumed" ], "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "sig-payload-fn-record-digest-evidence", "name": "Record digest evidence", "description": "Retain a digest produced by an external digest provider together with its algorithm identifier, encoding and a precise description of the digested input. This function never computes a digest.", "inputs": [ "externally computed digest value", "digest algorithm identifier", "digest encoding label", "digest input description", "scope manifest reference" ], "outputs": [ "digest evidence record", "governing digest selection where several exist" ], "preconditions": [ "The algorithm identifier resolves in a governed registry", "The digest length is consistent with the declared algorithm", "The digest input description names any canonicalization or transform algorithm applied" ], "effects": [ "Digest evidence is retained verbatim and never re-encoded on write", "Parallel digests coexist without displacing one another" ], "source_refs": [ "SRC-006", "SRC-009", "SRC-016", "SRC-018" ] }, { "id": "sig-payload-fn-partition-parameters", "name": "Partition proof parameters", "description": "Classify each proof parameter as protected or unprotected, mark the critical must-be-understood subset and record the precedence rule for duplicates.", "inputs": [ "parameter name and position list", "criticality declarations", "governing standard alignment reference" ], "outputs": [ "protected parameter list", "unprotected parameter list", "critical parameter list", "precedence rule statement" ], "preconditions": [ "Every parameter declared critical is present in a protected position", "The governing standard alignment names a version and section" ], "effects": [ "Relying parties can determine exactly what the proof covers", "A critical parameter outside the protected position is flagged as invalid" ], "source_refs": [ "SRC-007", "SRC-014", "SRC-008" ] }, { "id": "sig-payload-fn-bind-purpose-context", "name": "Bind purpose and context parameters", "description": "Record the proof purpose, audience or domain, challenge or nonce, external authenticated data reference and bound expiry, each with the position it occupies in the protected input.", "inputs": [ "proof purpose", "audience or domain values", "challenge or nonce", "bound expiry instant", "external authenticated data reference" ], "outputs": [ "bound parameter set with positions", "excluded-use statement", "replay limitation note" ], "preconditions": [ "The chosen proof method relies on the parameter being bound", "A challenge is present whenever an audience or domain is bound" ], "effects": [ "The intended purpose and context of the proof are explicit", "Evaluation of these values remains with the referenced verification model" ], "source_refs": [ "SRC-008", "SRC-004" ] }, { "id": "sig-payload-fn-preserve-protected-input", "name": "Preserve protected input for dependent proofs", "description": "Freeze the exact protected input or its digest at the moment a dependent countersignature or chained proof is taken, and record the chain ordinal.", "inputs": [ "target proof reference", "preserved form selection", "protected input octets or digest reference", "finality assertion" ], "outputs": [ "preserved protected-input record", "chain ordinal", "target digest at time of dependence" ], "preconditions": [ "The target structure's cryptographic functions are finalized", "Retention of full octets is permitted by the host record's classification" ], "effects": [ "A dependent proof can be checked against the identical input later", "The preserved record is immutable once a dependent proof references it" ], "source_refs": [ "SRC-006", "SRC-015", "SRC-004" ] }, { "id": "sig-payload-fn-resolve-or-fail-payload", "name": "Resolve protected payload or raise explicit failure", "description": "Attempt to obtain the exact protected representation named by a binding descriptor and, where that is not possible, emit a classified failure instead of any empty, default or nearest-match value.", "inputs": [ "payload binding descriptor identifier", "resolution context", "supplied payload candidate or locator" ], "outputs": [ "resolved payload handle", "binding failure record", "failure observation instant" ], "preconditions": [ "The descriptor records a binding mode and at least one locator, digest evidence entry or supply contract" ], "effects": [ "An unresolvable, mutable, ambiguous or version-mismatched payload is recorded as an explicit failure", "No substituted value is ever returned in place of the protected representation" ], "source_refs": [ "SRC-008", "SRC-016", "SRC-017" ] }, { "id": "sig-payload-fn-compare-recorded-digest", "name": "Compare supplied digest against recorded evidence", "description": "Compare a digest supplied by an external provider with the recorded digest evidence for the same descriptor and emit match, mismatch or indeterminate. This function performs no cryptographic computation, no signature verification and no enforcement.", "inputs": [ "digest evidence record identifier", "externally computed digest value", "digest algorithm identifier", "digest encoding label" ], "outputs": [ "comparison outcome", "comparison rationale", "observation instant" ], "preconditions": [ "The algorithm identifier and encoding label of the supplied digest match those of the recorded evidence, or the outcome is indeterminate", "The digest input description of the recorded evidence is available" ], "effects": [ "A comparison outcome is retained as evidence for the referenced verification model", "No acceptance, rejection or enforcement decision is made or implied by this model" ], "source_refs": [ "SRC-016", "SRC-004", "SRC-018" ] }, { "id": "sig-c14n-fn-declare-chain", "name": "Declare canonical derivation chain", "description": "Record the ordered transform chain for a selected input, with each step's presence kind, governed algorithm identifier, version, bound parameters and input and output media types, producing an immutable chain manifest version.", "inputs": [ "Selected input reference", "Ordered transform step declarations", "Algorithm identifiers, versions and parameter bindings", "Input and output media types per step" ], "outputs": [ "Versioned canonicalization chain manifest", "Explicit presence classification for every chain position" ], "preconditions": [ "The host subject reference resolves in the referenced payload model", "Every algorithm identifier is a governed URI or a registered name from its defining authority", "No step relies on an implicit default canonicalization" ], "effects": [ "A new chain manifest version is created and any prior version is marked superseded with an effective-from instant", "An absent step and a declared identity step are recorded as distinct values and never collapsed" ], "source_refs": [ "SRC-016", "SRC-004", "SRC-030", "SRC-020" ] }, { "id": "sig-c14n-fn-record-protected-bytes", "name": "Record protected-bytes derivation result", "description": "Attach the outcome of an externally executed derivation to a chain manifest version: protected octet length, digest algorithm identifier, digest value and the implementation pin that produced them.", "inputs": [ "Chain manifest version identifier", "Protected octet length", "Digest algorithm identifier and digest value produced by an external processor", "Implementation product, version and configuration", "Derivation event instant" ], "outputs": [ "Protected-bytes derivation record", "Implementation pin record" ], "preconditions": [ "The chain manifest version is complete and immutable", "The external processor reports successful completion of every declared step" ], "effects": [ "The derivation record is bound to exactly one chain manifest version", "Transform execution remains with the external processor and is attributed here, never performed here", "Event instant and observation instant are stored separately when they differ" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-017", "SRC-022" ] }, { "id": "sig-c14n-fn-assemble-resolution-context", "name": "Assemble input resolution context", "description": "Fix and record what a reference resolved to at derivation time: the reference expression, the base URI and the precedence rule that supplied it, the media type governing fragment interpretation, the comparison level and whether external dereferencing was permitted.", "inputs": [ "Reference expression", "Candidate base URI and its establishment rule", "Governing media type for fragment interpretation", "External-retrieval permission and authorised retrieving component" ], "outputs": [ "Resolution context record", "Normalized reference form and the comparison level applied" ], "preconditions": [ "A base URI can be established by a declared precedence rule whenever the reference is relative", "The governing media type for the fragment is known" ], "effects": [ "The resolved reference used at derivation time is fixed and no longer re-derivable by implication", "Dereferencing and retrieval remain with the external component named in the record" ], "source_refs": [ "SRC-024", "SRC-016", "SRC-022" ] }, { "id": "sig-c14n-fn-bind-context-parameters", "name": "Bind domain separation and purpose parameters", "description": "Place domain separation, purpose, audience, challenge, explicit type and external additional authenticated data into the protected region of the structure so that the derivation cannot be reused in another context.", "inputs": [ "Domain separation tag or structure context label", "Proof purpose", "Domain or audience and challenge or nonce", "Explicit type label and content type label", "External additional authenticated data" ], "outputs": [ "Context-binding parameter set carried inside the protected structure", "Empty-versus-absent determination for each optional binding" ], "preconditions": [ "Every parameter is placed in the protected region, not an unprotected region", "The domain separation tag is application-unique, nonzero length and carries a version component" ], "effects": [ "The derivation is separated from other uses of the same key and algorithm", "Acceptance of the bound values is delegated to the referenced verification and policy models" ], "source_refs": [ "SRC-026", "SRC-004", "SRC-008", "SRC-027" ] }, { "id": "sig-c14n-fn-record-fidelity-and-criticality", "name": "Record coverage, fidelity delta and critical steps", "description": "Record which parts of the input are covered and excluded, which steps are irreversible, where the retained pre-transform representation lives, and which steps and parameters are declared must-understand together with the complexity limits that bound derivation.", "inputs": [ "Selection or exclusion map", "Irreversible step flags and discarded-information descriptions", "Pre-transform representation reference and digest", "Critical step and parameter labels", "Complexity limits" ], "outputs": [ "Selection and exclusion map", "Derivation fidelity record", "Critical-step and complexity-limit declaration" ], "preconditions": [ "The pre-transform representation is retained by the payload model and is addressable", "Coverage is expressed as an exclusion list wherever the addressing scheme allows it" ], "effects": [ "Uncovered and discarded content is explicit rather than implied", "Critical steps are declared fail-closed for the external evaluator, which owns the refusal decision and its audit record" ], "source_refs": [ "SRC-017", "SRC-023", "SRC-007", "SRC-025", "SRC-021" ] }, { "id": "sig-c14n-fn-compare-reproduction", "name": "Compare independent reproduction against the record", "description": "Take a digest recomputed by a second, independently pinned implementation and compare it with the stored derivation record, producing a reproducibility determination or a divergence observation.", "inputs": [ "Chain manifest version identifier", "Digest recomputed by an external processor", "Second implementation pin", "Observation instant" ], "outputs": [ "Reproducibility determination", "Divergence observation record naming the disputed step where identifiable" ], "preconditions": [ "A protected-bytes derivation record exists for the chain manifest version", "The second implementation applied the same declared parameters, including those left at specification defaults" ], "effects": [ "A reproducibility determination is appended to the derivation record without altering it", "Recomputation is performed externally; only the comparison outcome and its two instants are stored here", "A mismatch is recorded as divergent and is never silently repaired" ], "source_refs": [ "SRC-019", "SRC-021", "SRC-022", "SRC-030" ] }, { "id": "sig-proj-select-binding-form", "name": "Select and record binding form", "description": "Chooses the binding form for a proof given payload location, host mutability and consumer constraints, and records the selection with the forms the target projection cannot express.", "inputs": [ "Payload location and mutability constraints", "Host artifact type and its addressing scheme", "Required multi-proof topology", "Candidate target projection codes" ], "outputs": [ "Binding form selection record with rationale", "List of forms marked unavailable for each candidate projection" ], "preconditions": [ "At least one candidate projection profile is declared", "The covered payload or payload reference is identified" ], "effects": [ "Records the selected binding form and level of assertion", "Marks unsupported forms as blocked with a specification citation", "Never encodes or produces a signature" ], "source_refs": [ "SRC-006", "SRC-016", "SRC-013" ] }, { "id": "sig-proj-declare-projection-profile", "name": "Declare projection profile and template", "description": "Registers a versioned profile for one target binding together with its encoding template, required and forbidden parameters, identifier space, media type and governing specification citation.", "inputs": [ "Target projection code and serialization variant", "Parameter requirements and prohibitions", "Governing specification identifier with edition", "Registry snapshot reference" ], "outputs": [ "Projection profile record", "Encoding template artifact reference", "Verification status flags for non-retrievable clauses" ], "preconditions": [ "An owner package is assigned", "At least one primary specification citation is available" ], "effects": [ "Creates a new profile version without altering earlier versions", "Marks paywalled or unretrievable clause requirements as unverified", "Does not make the profile a default for any other projection" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-016", "SRC-004", "SRC-038" ] }, { "id": "sig-proj-describe-payload-reference", "name": "Describe detached payload reference", "description": "Produces the descriptor a consumer needs to locate detached content: locator, digest algorithm and value, transform chain, byte range or header set, and concatenation order. Performs no dereferencing.", "inputs": [ "Payload locator or byte range", "Declared digest method and value where carried", "Transform or processing chain identifiers", "Multi-object ordering where applicable" ], "outputs": [ "Detached payload reference descriptor", "Resolution-input checklist for the referenced runtime" ], "preconditions": [ "The binding form is detached or the host uses a byte-range binding", "The locator scheme is known to the profile" ], "effects": [ "Records locator, digest and processing declarations", "Leaves dereferencing, digest computation and comparison to the referenced resolver", "Records an unresolvable or mismatch state only as reported by that resolver" ], "source_refs": [ "SRC-016", "SRC-036", "SRC-037", "SRC-008" ] }, { "id": "sig-proj-compare-projections", "name": "Compare projections and build loss ledger entries", "description": "Compares a source profile with a target profile across the enumerated loss classes and produces ledger entries with severity, affected elements and cause classification.", "inputs": [ "Source projection profile record", "Target projection profile record", "Loss class enumeration" ], "outputs": [ "Loss ledger entries with severity and cause", "Draft projection loss report" ], "preconditions": [ "Both profiles are declared and versioned", "Both registry snapshots are recorded" ], "effects": [ "Creates append-only ledger entries scoped to the pair", "Records assessment event time separately from ingestion time", "Never removes an earlier entry, only supersedes it by reference" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-015", "SRC-006", "SRC-004", "SRC-035" ] }, { "id": "sig-proj-map-method-identifier", "name": "Map method identifier across identifier spaces", "description": "Maps an algorithm, digest or canonicalization identifier from the source identifier space to the target space, marking unmapped identifiers and parameters that cannot be carried.", "inputs": [ "Source identifier value and its space", "Target identifier space and registry snapshot", "Associated parameter set where carried separately" ], "outputs": [ "Target identifier value or an explicit unmapped marker", "Parameter carriage note describing folded or dropped parameters" ], "preconditions": [ "Both identifier spaces are declared by their profiles", "The registry snapshots used are recorded" ], "effects": [ "Records the mapping and its direction", "Raises a loss ledger entry when the mapping is partial or absent", "Never substitutes a near-equivalent algorithm silently" ], "source_refs": [ "SRC-032", "SRC-006", "SRC-016", "SRC-038" ] }, { "id": "sig-proj-record-conversion-block", "name": "Record conversion blocking condition", "description": "Registers a condition that makes a conversion impossible or unsafe, with its specification citation and whether re-signing rather than re-encoding would be required.", "inputs": [ "Source and target profile identifiers", "Observed structural or cryptographic obstacle", "Specification citation" ], "outputs": [ "Blocking condition record", "Updated conversion verdict for the pair" ], "preconditions": [ "A loss comparison exists for the pair", "The obstacle is traceable to a cited specification statement or a recorded profile constraint" ], "effects": [ "Sets or downgrades the pair verdict to conditional or blocked", "Records the forbidden fallback paths associated with the condition", "Does not itself prevent any runtime action; enforcement belongs to the referenced runtime" ], "source_refs": [ "SRC-007", "SRC-014", "SRC-008" ] }, { "id": "sig-proj-assemble-conformance-report", "name": "Assemble binding conformance report", "description": "Aggregates externally produced encoder, parser and validator results with the profile record, verdicts, ambiguity flags and evidence conflicts into a serial report.", "inputs": [ "External component results with their producing component identifiers", "Projection profile record and version", "Conversion verdicts and blocking conditions" ], "outputs": [ "Binding conformance report artifact", "Supersession reference where an earlier report is replaced" ], "preconditions": [ "Every external result carries its own provenance and observation time", "The profile version under test is identified" ], "effects": [ "Records results by reference without re-running or re-interpreting them", "States alignment findings and explicitly avoids asserting conformance", "Appends rather than overwrites, citing any superseded report" ], "source_refs": [ "SRC-007", "SRC-016", "SRC-004" ] }, { "id": "sig-proj-register-version-binding", "name": "Register version binding across the three axes", "description": "Binds a record to its binding profile version, logical proof version and host artifact version, together with the specification edition and registry snapshot in force.", "inputs": [ "Binding profile version", "Logical proof version", "Host artifact version reference", "Specification edition and registry snapshot references" ], "outputs": [ "Version binding record", "Compatibility verdict for the version step" ], "preconditions": [ "The profile version exists", "The host artifact version is obtainable from the host model as a reference value" ], "effects": [ "Keeps the three version axes distinct and separately queryable", "Flags any version step that would alter the signing input as requiring a new proof", "Records paywalled or unretrievable clause status against the edition citation" ], "source_refs": [ "SRC-033", "SRC-004", "SRC-036", "SRC-041" ] }, { "id": "sig-chain-fn-record-method-binding", "name": "Record verification-method binding", "description": "Attach a verification-method reference to a signature instance in its declared binding form, capturing the resolution inputs supplied, the resolution metadata returned and the version reference in effect. Does not perform resolution, does not create or update the external record, and does not judge the method's acceptability.", "inputs": [ "Signature instance reference", "Verification-method identifier or DID URL", "Binding form code", "Resolution options supplied and resolution metadata returned by the external resolver", "Observation time" ], "outputs": [ "Verification-method binding record with pinned version reference", "Declared purpose and mandatory relying-party feature fields extracted from the retrieved material" ], "preconditions": [ "The signature instance exists and is attachable by this mixin", "The verification-method identifier is expressed in a namespace the adopting Dimension has declared in scope" ], "effects": [ "The signature instance gains a resolvable, version-pinned verification-method reference", "Any purpose mismatch between the declared usage and the relied-on operation is flagged for the record, without an acceptance decision being made" ], "source_refs": [ "SRC-043", "SRC-050", "SRC-051" ] }, { "id": "sig-chain-fn-record-path-candidates", "name": "Record candidate paths and selection", "description": "Record the candidate certification paths assembled toward a trust anchor, the retrieval source and observation time for each member certificate, and which candidate an external path builder selected on which recorded criteria. Does not build paths and does not execute path validation.", "inputs": [ "Verification-method binding record", "Candidate path descriptions supplied by an external path builder", "Retrieval source and endpoint per member certificate", "Path builder identity and version" ], "outputs": [ "Candidate path records with ordered certificate references", "Selected path reference with recorded selection criteria", "Certification path certificate set artifact" ], "preconditions": [ "At least one candidate path has been supplied by an external builder", "The binding form is one for which a certification path is meaningful" ], "effects": [ "Alternative paths remain visible rather than being silently discarded by the selection", "The captured certificate set becomes replayable without re-contacting directories or authority information access endpoints" ], "source_refs": [ "SRC-043", "SRC-045" ] }, { "id": "sig-chain-fn-record-constraint-outcomes", "name": "Record path validation inputs and constraint outcomes", "description": "Record the initial policy set, control flags and subtree inputs supplied for a determination, together with the per-certificate and per-path constraint outcomes reported back — basic constraints, name constraints, policy state and unrecognized critical extensions. The algorithm itself is executed by an external validator whose identity and version are recorded alongside.", "inputs": [ "Selected path reference", "Initial policy set, control flags, permitted and excluded subtrees", "Constraint outcomes reported by the external validator", "Validator identity and version" ], "outputs": [ "Constraint input record", "Per-certificate and per-path constraint outcome record" ], "preconditions": [ "A selected path reference exists", "The reporting validator is identified so its outcomes are attributable" ], "effects": [ "The determination becomes reproducible because the exact inputs are retained beside the exact reported outcomes", "Unrecognized critical extensions are recorded as facts rather than resolved into an acceptance verdict" ], "source_refs": [ "SRC-043", "SRC-046" ] }, { "id": "sig-chain-fn-pin-anchor-context", "name": "Pin trust-anchor and trust-store context", "description": "Pin the trust anchor that terminated the selected path, its anchor-carried path controls, the trust store or trust list snapshot in force by sequence number, issue date-time and digest, and the service status observed for it. Does not admit, remove or supervise anchors and does not operate the trust list.", "inputs": [ "Selected path reference", "Trust anchor name and key identifier", "Trust store or trust list location, sequence number, issue date-time and digest", "Observed service status and its status starting date and time" ], "outputs": [ "Trust anchor context record", "Trust-store snapshot pin" ], "preconditions": [ "The selected path terminates at an anchor present in a declared trust store or trust list", "The snapshot digest was computed over the exact retrieved snapshot bytes" ], "effects": [ "A later reader can reproduce the anchor context by fetching the pinned issue and verifying the digest", "A change of trust-store snapshot is detectable, because the pin differs even when the anchor name is unchanged" ], "source_refs": [ "SRC-046", "SRC-013", "SRC-053" ] }, { "id": "sig-chain-fn-attach-status-evidence", "name": "Attach revocation status evidence", "description": "Capture a signed status statement byte-preservingly, record its mechanism, reported value, reason, effective date, scope, this-update and next-update bounds, signer, delegation basis, nonce state, delivery channel and digest, and link it to the subject verification method. Does not request revocation, does not operate the responder or publisher, and does not interpret the value as an acceptance outcome.", "inputs": [ "Verification-method binding record or path certificate reference", "Retrieved status evidence bytes and their retrieval endpoint", "Status signer identity and reported delegation basis", "Nonce state and delivery channel", "Observation time" ], "outputs": [ "Captured status evidence object artifact", "Status determination record with freshness and scope fields", "Status authorization and binding record" ], "preconditions": [ "The evidence claims a scope that covers the subject, or the out-of-scope condition is recorded explicitly", "A digest over the exact retrieved bytes has been computed" ], "effects": [ "The status statement becomes independently re-verifiable from the retained bytes", "A declared no-revocation-available or responder-no-check condition is recorded as a positive fact rather than as absent evidence" ], "source_refs": [ "SRC-043", "SRC-044", "SRC-047", "SRC-048", "SRC-052" ] }, { "id": "sig-chain-fn-record-observed-status-transition", "name": "Record an observed status transition", "description": "Record that an authoritative source has reported a change in the subject's status — revocation, hold or release, supersession, or a compromise-driven reason change — with its published effective date and the separate time at which this model observed it. The transition itself is decided and published by the issuing authority; this function records the observation only.", "inputs": [ "Prior status determination record", "Newly captured status evidence object", "Published effective date and reason code", "Observation time" ], "outputs": [ "Observed status transition record linking prior and new determinations", "Updated reversibility and supersession fields" ], "preconditions": [ "Both the prior and the new determination are attributable to an authorized status signer for the subject", "The published effective date is present or its absence is recorded" ], "effects": [ "Prior determinations are marked superseded rather than overwritten, preserving the historical view", "Reversible states such as hold and release are distinguishable from permanent revocation in the retained history" ], "source_refs": [ "SRC-043", "SRC-044", "SRC-052" ] }, { "id": "sig-chain-fn-declare-validation-instant", "name": "Declare the validation instant", "description": "Declare which instant a trust-chain record is framed against — current time, best-signature time supported by a proof of existence, or a replayed historical instant — and record the clock-skew tolerance and time source used when comparing that instant to evidence windows. Does not issue proofs of existence and does not decide whether the framing yields an acceptable result.", "inputs": [ "Trust-chain record reference", "Instant kind and instant value with seconds and an explicit offset", "Proof-of-existence reference where the instant is in the past", "Clock-skew tolerance and time source reference" ], "outputs": [ "Validation instant record", "Comparison basis used against evidence this-update and next-update bounds" ], "preconditions": [ "A past instant is accompanied by a proof-of-existence reference, or the absence of one is recorded explicitly", "The instant value carries seconds and an explicit offset" ], "effects": [ "Current-time framing, best-signature-time framing and historical replay are held as distinct records over the same evidence", "Re-framing at a different instant produces a new record instead of mutating the existing one" ], "source_refs": [ "SRC-044", "SRC-048", "SRC-013" ] }, { "id": "sig-chain-fn-assess-record-completeness", "name": "Assess record completeness and determinacy", "description": "Classify this model's own record as determinate, evidence-incomplete or not assessed at the declared instant, by checking which required elements are present, stale, out of scope or unreachable, and carry any externally issued validation indication verbatim with its issuer. This is an assessment of evidence sufficiency in the record, not a trust decision, a policy evaluation or an enforcement action.", "inputs": [ "Trust-chain record with path, anchor and status evidence attached", "Validation instant record", "Externally issued validation indication and sub-indication with issuer identity, where available", "Declared failure-handling stance reference, where one has been declared elsewhere" ], "outputs": [ "Determinacy classification with per-element presence and staleness findings", "Missing-element inventory with a reason for each entry", "Carried indication fields attributed to their issuing validator" ], "preconditions": [ "A validation instant has been declared", "Each element checked is either present with a verifiable digest or explicitly recorded as absent" ], "effects": [ "Missing or stale status evidence is recorded as evidence-incomplete and is never rewritten as a cryptographic failure or as a revocation", "The declared failure-handling stance is carried as an attributed reference, leaving the accept-or-reject decision with the policy model that owns it" ], "source_refs": [ "SRC-044", "SRC-047", "SRC-048", "SRC-013", "SRC-054" ] }, { "id": "sig-chain-fn-assemble-replay-package", "name": "Assemble a trust-chain replay package", "description": "Assemble the selected path, anchor and trust-store pin, captured status evidence, declared instant, proof-of-existence references and determinacy record into a versioned, self-contained container that an external validator can re-evaluate later offline. Produces evidence for replay; it does not perform the replay and is not an audit record.", "inputs": [ "Trust-chain record reference", "Certification path certificate set artifact", "Captured status evidence object artifacts", "Validation instant and determinacy records", "Package owner and requested package sequence number" ], "outputs": [ "Trust-chain evidence replay package artifact", "Member manifest with per-member digests and pinned external references" ], "preconditions": [ "Every included member carries a digest that reproduces over its retained bytes", "The determinacy classification for the declared instant is present, including where it reports evidence-incomplete" ], "effects": [ "A later determination at the same instant can proceed without contacting certificate authorities, responders, trust lists or resolvers", "Export of the package is recorded with the requesting principal and declared purpose, with the audit entry itself held by the adopting Dimension's audit model" ], "source_refs": [ "SRC-044", "SRC-045", "SRC-013" ] }, { "id": "sig-verdict-fn-resolve-suite", "name": "Resolve a declared algorithm identifier into a complete suite descriptor", "description": "Normalises a container-asserted algorithm identifier against its registry namespace and expands it into the full parameter set required for unambiguous verification, recording any parameter that is absent, inherited or ambiguous as an explicit gap.", "inputs": [ "asserted algorithm identifier and registry namespace", "container format or profile", "any inherited or externally supplied parameters" ], "outputs": [ "normalised suite descriptor", "parameter completeness status", "ambiguity reason codes" ], "preconditions": [ "a signature record exists carrying at least one asserted algorithm identifier", "the registry alignment for that namespace is declared" ], "effects": [ "writes the normalised suite descriptor and completeness status onto the signature record", "records unresolved parameters as a gap instead of applying a silent default", "performs no cryptographic operation and changes no signature bytes" ], "source_refs": [ "SRC-001", "SRC-059", "SRC-038", "SRC-063" ] }, { "id": "sig-verdict-fn-classify-status", "name": "Classify approval state and security strength against a pinned policy", "description": "Compares a normalised suite descriptor with a pinned algorithm policy snapshot and records the approval state, security-strength assessment and sunset comparison for each governing authority, preserving disagreements rather than resolving them.", "inputs": [ "normalised suite descriptor", "pinned policy snapshot reference", "evaluation time basis" ], "outputs": [ "approval state per authority", "security strength assessment", "sunset comparison result", "authority disagreement note" ], "preconditions": [ "a policy snapshot is pinned with its version and digest", "an evaluation time basis has been chosen and recorded" ], "effects": [ "writes a non-enforcing classification onto the record", "records divergence between authorities without selecting a winner", "does not accept or reject the signature; acceptance remains a decision of the adopting Dimension's policy engine" ], "source_refs": [ "SRC-055", "SRC-056", "SRC-057", "SRC-058", "SRC-063" ] }, { "id": "sig-verdict-fn-detect-downgrade", "name": "Compare the container-asserted algorithm with the accepted-algorithm set", "description": "Records whether the algorithm asserted in the signature container fell inside the verifier-side accepted set, whether the key-to-algorithm binding was checked, and whether an unauthenticated or non-signing algorithm value was present.", "inputs": [ "container-asserted algorithm identifier", "accepted algorithm set reference and version", "key-to-algorithm binding reference" ], "outputs": [ "set membership result", "downgrade or confusion indicator", "rejection reason code" ], "preconditions": [ "an accepted-algorithm set is referenced with its policy source recorded", "the verification episode is identified" ], "effects": [ "records the comparison result and its reason code", "flags cases where algorithm selection came from the container rather than verifier policy", "raises no enforcement action and blocks nothing" ], "source_refs": [ "SRC-038", "SRC-027" ] }, { "id": "sig-verdict-fn-pin-context", "name": "Pin the verification context for an episode", "description": "Freezes the inputs that a later re-derivation must reproduce: validation time and its basis, the policy and vocabulary versions in force, the verifier and tool identity, and the references to supplied validation material.", "inputs": [ "validation time and time basis", "policy snapshot and vocabulary version references", "verifier, tool and configuration identity", "supplied validation material references" ], "outputs": [ "immutable verification context record", "context identifier", "non-reproducible factor list" ], "preconditions": [ "the signature record and its covered-content digest are resolvable", "the covered-content digest algorithm is named" ], "effects": [ "creates an immutable context that later verdicts cite", "records observation or ingestion time separately from validation time", "does not fetch, validate or evaluate any referenced material" ], "source_refs": [ "SRC-006", "SRC-009", "SRC-061", "SRC-062" ] }, { "id": "sig-verdict-fn-record-verdict", "name": "Record a structured, dimension-separated verdict with evidence references", "description": "Stores an outcome produced by an external verifier, together with its reason codes, independent per-dimension outcomes, and the digest-bound reference to the validation report or other evidence that justifies it.", "inputs": [ "outcome value and reason codes from the external verifier", "per-dimension outcomes and not-assessed markers", "evidence or report reference with digest", "pinned verification context identifier" ], "outputs": [ "verdict record", "list of dimensions explicitly not assessed", "evidence binding record" ], "preconditions": [ "a pinned verification context exists", "the outcome vocabulary version is declared", "the producing verifier and tool version are known" ], "effects": [ "stores the verdict without recomputing the underlying cryptographic check", "marks unassessed dimensions explicitly instead of defaulting them to valid", "binds referenced evidence by digest while leaving the producing system's execution and audit trail entirely outside this model" ], "source_refs": [ "SRC-061", "SRC-062", "SRC-004", "SRC-013" ] }, { "id": "sig-verdict-fn-supersede-verdict", "name": "Supersede a prior verdict on re-validation", "description": "Appends a new verdict that cites its predecessor and the reason for re-validation, and records the drift between the two pinned policy snapshots so that a changed result can be attributed to policy movement rather than to the signature.", "inputs": [ "prior verdict identifier", "new pinned verification context", "reason for re-validation" ], "outputs": [ "superseding verdict record linked to its predecessor", "policy-pin drift note", "changed-dimension list" ], "preconditions": [ "a prior verdict exists and is immutable", "the new policy pin and vocabulary version are recorded" ], "effects": [ "appends rather than overwrites, preserving the earlier verdict and its evidence binding", "records algorithm-state drift between the two policy pins", "leaves disposition of the superseded record to the retention rule and to the owning retention policy" ], "source_refs": [ "SRC-056", "SRC-058", "SRC-061" ] }, { "id": "sig-evid-fn-record-proof", "name": "Record proof bytes with an explicit binding", "description": "Admit a proof artefact into the evidence set together with a statement of what it covers, its digests and the separation of event time from ingestion time.", "inputs": [ "Proof artefact bytes exactly as received", "Declared binding: covered object reference and the digest that ties them", "Acquisition source and ingestion instant" ], "outputs": [ "Immutable proof record with identifiers, digests and both time classes", "Rejection with a stated reason where the binding cannot be established" ], "preconditions": [ "A digest algorithm acceptable under the current algorithm policy is available", "The covered object is resolvable by version-pinned reference or its digest is supplied" ], "effects": [ "Appends an immutable record and never overwrites an existing one", "Registers digests for later integrity re-checking", "Records the asserted event time and the ingestion time as separate values" ], "source_refs": [ "SRC-009", "SRC-066", "SRC-016" ] }, { "id": "sig-evid-fn-record-time-evidence", "name": "Record trusted-time evidence", "description": "Attach an independently issued proof of existence to a covered object, verifying the imprint and nonce echo before admission and deriving only those orderings the accuracy bounds permit.", "inputs": [ "Time-stamp token or equivalent proof of existence", "Request imprint and nonce where available", "Authority and policy reference" ], "outputs": [ "Trusted-time evidence record with generation time, accuracy and serial", "Ordering assertions qualified by accuracy intervals", "Updated best-signature-time for the covered object" ], "preconditions": [ "The token message imprint matches a recorded digest of the covered object", "Any nonce present in the request is echoed identically in the token", "The token status is a granted issuance" ], "effects": [ "Establishes a proof-of-existence instant for the covered object", "Leaves any signer-claimed time recorded as an unproven claim", "Refuses to assert strict ordering between instants whose accuracy intervals overlap" ], "source_refs": [ "SRC-009", "SRC-065", "SRC-003" ] }, { "id": "sig-evid-fn-assemble-validation-material", "name": "Assemble a certification path and revocation snapshot", "description": "Collect the certificates and revocation data relied on for a validation and freeze them with their own time fields, so revocation state can later be re-derived without live responders.", "inputs": [ "Signing certificate and any discovered intermediates", "Revocation lists and status responses retrieved", "Freshness constraint in force and the validation instant" ], "outputs": [ "Validation material set with per-element time fields and responder identities", "Per-source freshness verdict", "Gap list naming any element that could not be obtained" ], "preconditions": [ "A validation instant has been fixed", "Each retrieved element is retained byte-identically before any interpretation" ], "effects": [ "Creates a snapshot that survives responder withdrawal", "Records the pre-produced-response caveat where no nonce was used", "Marks the snapshot incomplete rather than valid when an element is missing" ], "source_refs": [ "SRC-044", "SRC-043", "SRC-068" ] }, { "id": "sig-evid-fn-record-verdict", "name": "Record an externally produced validation outcome", "description": "Store the indication, sub-indication, reasons and dependency references returned by an accepted validation application. This function records an outcome; it performs no evaluation, no decision and no enforcement.", "inputs": [ "Validation report or verdict from an accepted validation application", "Validation instant and constraint snapshot reference", "Verifier product, version, build and configuration" ], "outputs": [ "Immutable verdict record with dependency references and both time values", "Replayability flag derived from missing dependencies" ], "preconditions": [ "The producing application is listed in the accepted-validator registry", "Every object the verdict depends on is retained by value or referenced with a digest" ], "effects": [ "Appends a dated observation that never alters an earlier verdict", "Preserves unrecognised sub-indication values verbatim rather than discarding them", "Marks the verdict non-replayable where a dependency is absent" ], "source_refs": [ "SRC-061", "SRC-062", "SRC-013" ] }, { "id": "sig-evid-fn-export-replay-package", "name": "Export a self-contained replay package", "description": "Emit the invariant inputs named by the replay contract in a chosen projection, so an independent party can re-run the validation without access to this system.", "inputs": [ "Subject signature identifier", "Replay contract identifier and version", "Target projection or container format" ], "outputs": [ "Replay package containing proof bytes, input manifest, validation material, constraint snapshot and recorded verdicts", "Manifest of digests for every included element", "Explicit list of elements that must still be fetched remotely" ], "preconditions": [ "Every invariant named by the replay contract is retained or referenced with a digest", "The target projection can carry the digests without re-encoding proof bytes" ], "effects": [ "Produces an export without mutating any source record", "Fails closed and reports the shortfall where an invariant is missing", "Preserves proof bytes byte-identically across the projection" ], "source_refs": [ "SRC-066", "SRC-067", "SRC-062" ] }, { "id": "sig-evid-fn-record-renewal", "name": "Record an evidence renewal", "description": "Register a renewal of durable evidence, distinguishing a new time-stamp over prior evidence from a rebuild under a new digest algorithm, and recompute chain continuity.", "inputs": [ "Renewing time-stamp or archive time-stamp", "Renewal kind and the trigger that prompted it", "Set of objects the renewal covers" ], "outputs": [ "Renewal record placed in its chain position", "Updated chain continuity status and next renewal due instant", "Gap report where the chain is broken" ], "preconditions": [ "The renewing token verifies against the material it covers", "For a hash-tree rebuild, the original data and all prior evidence are available" ], "effects": [ "Extends the evidence chain without altering earlier entries", "Adds digests under the new algorithm alongside historical ones", "Represents any gap explicitly rather than closing it by renumbering" ], "source_refs": [ "SRC-066", "SRC-067", "SRC-068" ] }, { "id": "sig-evid-fn-attach-corroboration", "name": "Attach a transparency corroboration reference", "description": "Record inclusion and consistency proof references and a signed checkpoint as optional corroboration of publication, always accompanied by its negative scope statement.", "inputs": [ "Log identifier, entry locator and leaf digest", "Inclusion or consistency proof material", "Signed checkpoint or tree head current at capture" ], "outputs": [ "Corroboration reference record with verification result", "Mandatory scope statement of what the corroboration does not establish" ], "preconditions": [ "The proof verifies against the supplied checkpoint", "The checkpoint signature verifies under a recorded log key" ], "effects": [ "Adds corroboration without altering any validation verdict", "Never contributes to signer identification or content-truth claims", "Leaves log operation, monitoring and merge behaviour with the log model" ], "source_refs": [ "SRC-069" ] }, { "id": "sig-evid-fn-assert-supersession", "name": "Assert supersession or invalidation over prior evidence", "description": "Record that the interpretation of named evidence has changed, leaving every named record byte-identical and unmodified.", "inputs": [ "Anomaly class and the triggering observation or external determination", "References and digests of every affected record", "Residual assurance statement" ], "outputs": [ "Append-only supersession assertion linked to the affected records", "Updated interpretation flags on reads of those records" ], "preconditions": [ "Each affected record is present and its stored digest still matches", "Where the anomaly rests on an external determination, that determination is referenced rather than restated" ], "effects": [ "Changes interpretation without changing bytes", "Chains to any prior assertion over the same subject", "Records the observation instant separately from the underlying event instant" ], "source_refs": [ "SRC-066", "SRC-044", "SRC-061" ] }, { "id": "sig-evid-fn-report-evidence-gaps", "name": "Report replay-sufficiency gaps", "description": "Inspect an evidence set against its declared replay contract and renewal deadlines and report shortfalls. The function reports; it does not enforce, escalate or dispose.", "inputs": [ "Subject signature identifier", "Replay contract identifier and version", "Current algorithm policy and renewal deadlines" ], "outputs": [ "Gap report naming missing invariants, stale revocation data and overdue renewals", "Per-gap consequence statement for replayability" ], "preconditions": [ "A replay contract has been declared for the subject", "The algorithm policy is resolvable at the requested version" ], "effects": [ "Produces a read-only assessment with no change to evidence", "Distinguishes a gap in evidence from an invalid signature", "Feeds remediation to the owning roles without taking any enforcement action" ], "source_refs": [ "SRC-066", "SRC-061", "SRC-013" ] }, { "id": "sig-gov-fn-open-proof-record", "name": "Open a governed proof record", "description": "Creates the governed record for a proof attached to a host subject, assigning identity, responsible owner, method and policy pins, and an initial governance state. It performs no cryptographic operation and asserts no validation outcome.", "inputs": [ "Host subject reference", "Identifier selected by the stated identity priority", "Responsible owner reference", "Signing method identifier and pinned parameters", "Signature policy, validation policy and trust-anchor set references with versions", "Signing event time in RFC 3339 with seconds and explicit offset" ], "outputs": [ "Governed proof record in its initial state", "Identity assignment evidence naming which priority tier was used", "Pin set applicable at event time" ], "preconditions": [ "Host subject reference resolves", "A responsible owner is assigned", "No higher-priority identifier exists that was passed over without a recorded reason" ], "effects": [ "An append-only record is created", "The reported validation outcome remains unset until an external validator reports one", "No key is generated, accessed or used" ], "source_refs": [ "SRC-061", "SRC-004", "SRC-073" ] }, { "id": "sig-gov-fn-record-supersession", "name": "Record supersession of a proof record", "description": "Records that a successor proof record replaces a prior one, moving the prior record to a superseded state while keeping it resolvable with its original pins and reported outcomes.", "inputs": [ "Prior proof record reference", "Successor proof record reference", "Supersession reason code", "Acting role reference", "Recorded-at time" ], "outputs": [ "Supersession record", "Updated governance state on the prior record", "Forward and back chain links with position" ], "preconditions": [ "Both records resolve", "The prior record is not already superseded by a different successor", "The acting role holds state-change authority" ], "effects": [ "The prior record is retained and resolvable, not deleted", "Chain position is incremented and forks are rejected", "Original pins and reported outcomes on the prior record are unchanged" ], "source_refs": [ "SRC-004", "SRC-073", "SRC-043", "SRC-075" ] }, { "id": "sig-gov-fn-record-control-change", "name": "Record a controlled change to method, key reference, trust anchors or policy pin", "description": "Records an approved change to the signing method, key or signing-service reference, trust-anchor set or pinned policy, with its transition status, effective interval and the remediation obligations it imposes on existing records.", "inputs": [ "Change kind and prior and new values", "Transition status and its source regime", "Effective interval", "Approving authority and review record references", "Affected scope selection criteria" ], "outputs": [ "Method change record or policy and anchor pin record", "Remediation obligation list with affected scope", "New pin applicable to subsequent proof records" ], "preconditions": [ "The change is approved by the competent authority role", "The prior pin is resolvable", "The requesting role is not the sole approving role" ], "effects": [ "Subsequent records use the new pin", "Existing records retain their original pins and are flagged with obligations where required", "No key rotation, re-signing or policy authoring is performed here" ], "source_refs": [ "SRC-071", "SRC-004", "SRC-055", "SRC-057", "SRC-013" ] }, { "id": "sig-gov-fn-record-compromise-response", "name": "Record an emergency compromise response", "description": "Records a referenced external compromise declaration, its asserted invalidity time, the frozen set of affected proof records, the required response actions with their owning models, and the outcomes reported by the executing parties.", "inputs": [ "External compromise declaration reference and reason code", "Asserted invalidity time", "Scope selection criteria such as key reference, method or anchor set", "Responder role references", "Mitigation evidence references such as time-stamp tokens or preserved evidence sets" ], "outputs": [ "Compromise response record", "Frozen affected-scope list with freeze time", "Governance state changes on affected records", "Mitigation determination per record where evidence supports it" ], "preconditions": [ "The declaration is issued by an authorised external party and resolves", "The asserted invalidity time is present or explicitly recorded as unknown", "A responsible owner is assigned to receive the response" ], "effects": [ "Affected records are flagged and their scope is frozen", "Reported outcomes are recorded per action", "Revocation, key destruction and certificate reissuance are executed externally and only reported here" ], "source_refs": [ "SRC-073", "SRC-043", "SRC-055", "SRC-077" ] }, { "id": "sig-gov-fn-register-bounded-exception", "name": "Register a bounded acceptance exception", "description": "Registers a time-boxed, purpose-limited acceptance of a proof that does not satisfy its pinned policy, with a compensating condition, an approving authority and a defined rollback.", "inputs": [ "Target proof record references", "Exception ground code and purpose limitation", "Mandatory expiry time", "Approving role reference", "Compensating condition and rollback condition" ], "outputs": [ "Exception record with expiry", "Acceptance flag scoped to the stated purpose", "Registered rollback condition" ], "preconditions": [ "The approver holds exception authority and did not make the decision being excepted", "An expiry is present and bounded", "The reported cryptographic outcome being tolerated is already recorded" ], "effects": [ "Acceptance is time-boxed and lapses at expiry", "The reported cryptographic outcome is unchanged", "The pinned policy is not amended" ], "source_refs": [ "SRC-061", "SRC-071", "SRC-013" ] }, { "id": "sig-gov-fn-record-review-decision", "name": "Record a review and approval decision", "description": "Records that a governance decision was reviewed by a competent, independent role, capturing the reviewed inputs with their versions, the decision, conditions or dissent, and the reference to the external audit entry.", "inputs": [ "Decision subject reference", "Reviewer role reference and independence evidence", "Reviewed input references with versions or digests", "Decision code, conditions and dissent", "Recorded-at time" ], "outputs": [ "Review and approval record", "Effective status of the reviewed decision", "Audit entry reference for reconciliation" ], "preconditions": [ "The reviewer is independent of the decision-maker, or an exception is recorded", "All required inputs resolve at decision time", "The decision type is on the review-required list" ], "effects": [ "The decision becomes effective per the owner package rules", "An audit entry is created and retained by the external audit model and referenced here", "Audit content and audit retention are not held locally" ], "source_refs": [ "SRC-071", "SRC-074", "SRC-077", "SRC-078" ] }, { "id": "sig-gov-fn-classify-disclosure", "name": "Assign disclosure classes to proof-record components", "description": "Assigns an independent disclosure class to each component of a proof record and binds each class to an externally authored access policy reference, without evaluating or enforcing any grant.", "inputs": [ "Component references for payload, proof bytes, certificates, signer attributes, revocation evidence and diagnostics", "Disclosure class vocabulary version", "External access policy references" ], "outputs": [ "Disclosure classification schedule entries", "Class-to-policy bindings", "Default class assignments for unclassified components" ], "preconditions": [ "The class vocabulary version is pinned", "All component references resolve" ], "effects": [ "Each component carries exactly one class", "A grant on proof bytes never implies a grant on host content or signer attributes", "Grants are evaluated and enforced entirely by the external access model" ], "source_refs": [ "SRC-004", "SRC-073", "SRC-074", "SRC-076" ] }, { "id": "sig-gov-fn-bind-retention-and-tombstone", "name": "Bind retention and hold obligations and emit a tombstone reference", "description": "Binds a proof record to externally owned retention schedule, legal hold and preservation profile references, and, when the owning model reports that disposition has occurred, emits a minimal tombstone entry in place of the disposed record.", "inputs": [ "Retention schedule reference with version and issuing authority", "Legal hold or preservation order references", "Preservation profile and preserved evidence set references", "Reported disposition event with executing party and time" ], "outputs": [ "Retention, hold and preservation binding register entries", "Tombstone entry carrying identifier, supersession links, reason code, reported time and authority reference" ], "preconditions": [ "A records authority is assigned", "A schedule or hold resolves; where neither resolves the record is retained and flagged", "Disposition is reported by the owning model, never initiated here" ], "effects": [ "An active hold suspends disposition, with the suspension enforced by the records model", "Prior references continue to resolve to the tombstone", "Physical erasure, backup expiry and audit-record retention remain external" ], "source_refs": [ "SRC-072", "SRC-074", "SRC-075", "SRC-078" ] }, { "id": "sig-slayer-fn-resolve-bootstrap", "name": "Resolve bootstrap contract", "description": "Reads the AGENTS.md bootstrap descriptor, resolves its declared references in the mandatory order, checks that each resolution is integrity-protected, and either admits the agent to a declared scope or halts with an unresolved-reference code.", "inputs": [ "Bootstrap descriptor location", "Requesting role and requested scope" ], "outputs": [ "Admitted scope set with resolved specification, storage-type, interface and process references", "Unresolved-reference code and halt disposition when resolution or integrity fails" ], "preconditions": [ "All eight required bootstrap fields are present and non-empty", "Retrieval of each reference provides integrity protection" ], "effects": [ "Records the resolution attempt outcome and its observation timestamp", "Withholds every scope when any reference fails, without substituting cached or default values" ], "source_refs": [ "SRC-007", "SRC-080", "SRC-008" ] }, { "id": "sig-slayer-fn-canonicalize-record", "name": "Produce canonical record form", "description": "Applies the declared canonicalization profile to this model's own context record and returns its canonical octet sequence with a digest, aborting on unrepresentable input or on exceeding the declared complexity bound. It never recomputes, substitutes or re-derives the transformation owned by a referenced cryptosuite or envelope.", "inputs": [ "Context record in any input serialization", "Canonical form profile reference" ], "outputs": [ "Canonical octet sequence", "Digest algorithm identifier and digest value", "Canonicalization abort code when processing terminates" ], "preconditions": [ "Record passes the declared input-subset restrictions", "Complexity bound for canonicalization work is configured" ], "effects": [ "Fails closed on duplicate names, unrepresentable numbers, invalid Unicode or non-finite values", "Aborts early on inputs exceeding the complexity bound rather than continuing", "Leaves externally produced signing inputs untouched and marked opaque" ], "source_refs": [ "SRC-019", "SRC-021", "SRC-008", "SRC-082" ] }, { "id": "sig-slayer-fn-assign-record-identity", "name": "Assign identity under the priority ladder", "description": "Selects an identifier for a record or artifact by walking the identity priority ladder, and records which rung was used and why higher rungs were unavailable.", "inputs": [ "Candidate identifiers from issuing systems", "Governed IRI candidates", "Dimension minting service reference" ], "outputs": [ "Assigned identifier", "Priority rung indicator with justification" ], "preconditions": [ "Issuing systems of record have been consulted before minting", "No candidate identifier is a date, timestamp, version label or file name" ], "effects": [ "Marks a Dimension-minted identifier as local and never re-exports it as authoritative", "Records key hints, digests and authority-scoped serial numbers as non-identity values" ], "source_refs": [ "SRC-081", "SRC-050", "SRC-007", "SRC-009" ] }, { "id": "sig-slayer-fn-record-change-set", "name": "Record and apply a change set", "description": "Validates a proposed atomic change set against its preconditions and the prohibition on mutating signed material, applies it all-or-nothing, and emits a serially numbered change set record with prior and resulting canonical digests and an assigned compatibility class.", "inputs": [ "Proposed ordered operation list with precondition tests", "Current record and its canonical digest", "Requesting role" ], "outputs": [ "Applied record version and its new canonical digest", "Change set record", "Rejection code when a precondition fails or a prohibited target is touched" ], "preconditions": [ "Prior canonical digest matches the asserted precondition", "No operation targets stored proof octets, subject digests, protected parameters or pre-authentication inputs" ], "effects": [ "Leaves the record unchanged when any operation fails", "Assigns a compatibility class and marks canonicalization, identity-priority and binding changes as breaking", "Creates a supersession pointer instead of an in-place edit where signed material would otherwise change" ], "source_refs": [ "SRC-079", "SRC-082", "SRC-081", "SRC-001" ] }, { "id": "sig-slayer-fn-project-with-loss-report", "name": "Project record and report losses", "description": "Emits a WM-XCT-034 record into a requested container, database, interface or embedded binding, attaches a projection loss report enumerating fidelity losses, and asserts that the projection is not canonical.", "inputs": [ "Canonical record and its digest", "Projection target identifier", "Consumer scope" ], "outputs": [ "Projected representation", "Projection loss report with round-trip digest comparison" ], "preconditions": [ "Canonical form and digest exist for the record", "Projection target's known loss classes are declared in advance" ], "effects": [ "Never presents a projection as canonical and always carries a pointer back to the canonical form", "Flags elements that must be re-read from the canonical source", "Preserves opaque octets verbatim rather than re-encoding them for the target" ], "source_refs": [ "SRC-082", "SRC-019", "SRC-073", "SRC-021" ] }, { "id": "sig-slayer-fn-classify-access-request", "name": "Classify an access request against declared scopes", "description": "Maps a request to the scope and material category it touches, returns the declared access class and any exception reference required, and refers the actual grant or denial to the adopting Dimension's access system.", "inputs": [ "Requested scope and material category", "Requesting role", "Exception reference where presented" ], "outputs": [ "Declared access class for the scope and category", "Exception requirement statement with the external issuing system reference" ], "preconditions": [ "Scope classification table is present for the record", "Exception reference, if supplied, carries an expiry with an explicit offset" ], "effects": [ "Returns a declarative classification and never itself grants, denies or enforces access", "Marks unprotected parameters as unusable for the decision", "Refers issuance, enforcement and usage recording to the named external system" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-080", "SRC-073" ] }, { "id": "sig-slayer-fn-request-disposition", "name": "Request disposition of a record", "description": "Produces a disposition instruction and tombstone for this model's own context records when their retention class ends, and hands execution to the retention and storage systems that own physical deletion.", "inputs": [ "Record identity and its retention class", "Named retention policy reference" ], "outputs": [ "Disposition instruction addressed to the owning system", "Tombstone carrying identity, disposition reference and disposition time" ], "preconditions": [ "Retention class and governing policy reference are declared for the record", "Referenced external evidence is identified so that no attempt is made to dispose of another system's artifact" ], "effects": [ "Retains a tombstone sufficient to resolve dangling references without retaining the disposed content", "Never deletes or instructs deletion of externally owned evidence such as time-stamp tokens, status responses or log entries", "Records the disposition request and defers execution and confirmation to the owning system" ], "source_refs": [ "SRC-055", "SRC-080", "SRC-009", "SRC-069" ] }, { "id": "sig-prep-fn-read-current", "name": "Read current proof state of a host record", "description": "Returns the proof descriptors attached to the host record version current at read time, with a consistency token usable as a later precondition, and explicit completeness and filtering flags. Performs no cryptographic operation and makes no validity assertion.", "inputs": [ "Host record reference", "Requested proof detail level", "Caller access scope" ], "outputs": [ "Current host version identifier", "Attached proof descriptors with pinned payload digests and securing mechanism codes", "Read consistency token", "Completeness flag, applied filter identifier and withheld count" ], "preconditions": [ "Host record reference resolves to exactly one record", "Caller holds read scope for the host record and for the requested detail level; protected input octets require an elevated scope" ], "effects": [ "No state change; the operation is read-only and idempotent by construction", "Returns a projection labelled current-at-token, carrying no assertion of cryptographic validity, signer standing or business acceptability", "Triggers no verification and mutates no request state" ], "source_refs": [ "SRC-084", "SRC-085", "SRC-005" ] }, { "id": "sig-prep-fn-read-as-of", "name": "Read as-of proof state of a host record", "description": "Returns the proof state as at an explicitly supplied historical instant, evaluated against a caller-stated basis. Verification observations recorded at or before that point are returned as historical evidence bound to their observation instant.", "inputs": [ "Host record reference", "As-of instant as RFC 3339 with seconds and an explicit offset or Z", "As-of basis code (event time or observation time)", "Caller access scope" ], "outputs": [ "Host version resolved at the as-of point", "Proof descriptors attached as at that point", "Verification observations at or before that point, each marked non-current with its observation instant", "Completeness flag and withheld count" ], "preconditions": [ "The as-of instant is a complete RFC 3339 timestamp with seconds and an explicit offset or Z; unqualified local time is rejected", "The as-of basis is stated explicitly by the caller and is never inferred or defaulted silently", "Caller access scope permits reading the underlying historical host version" ], "effects": [ "No state change; read-only", "Historical verification observations are returned as evidence bound to their observation instant and never as current validity", "Where event time and observation time differ, both are returned rather than reconciled" ], "source_refs": [ "SRC-084", "SRC-005", "SRC-088" ] }, { "id": "sig-prep-fn-prepare-input", "name": "Prepare protected signing input and pin proof configuration", "description": "Resolves the host payload to one immutable version, applies a named and versioned deterministic transformation, and records the exact protected input or its digest together with the pinned proof configuration, correlation identifier and expiry. Touches no key and executes no cryptographic primitive.", "inputs": [ "Pinned immutable host payload version reference", "Transformation profile identifier and version", "Proof options: algorithm or cryptosuite, parameters, verification-method reference, proof purpose", "Context bindings: domain or audience, challenge or nonce, presentation header, external additional authenticated data", "Policy and profile pins", "Idempotency key", "Expected host version or entity-tag" ], "outputs": [ "Protected signing input octets or digest, with digest algorithm identifier and length", "Signing input manifest reference", "Pinned proof configuration reference", "Request correlation identifier", "Preparation instant and expiry instant as RFC 3339 with seconds and explicit offset" ], "preconditions": [ "The expected host version precondition matches the current host version; a mismatch fails the call with a precondition failure rather than preparing against drifted content", "A repeat call with the same idempotency key returns the previously prepared manifest and configuration unchanged and creates nothing new", "The payload version is immutable and content-addressed; a mutable payload reference is refused", "The transformation profile is named, versioned, deterministic and independently reproducible; unnamed or unversioned profiles are refused", "The algorithm, cryptosuite and parameters appear on the adopting Dimension's allow-list" ], "effects": [ "Creates exactly one immutable signing input manifest and one pinned proof configuration", "Opens one request record in the prepared state with its correlation identifier and expiry window", "Accesses no key material and executes no signing, proving or verification primitive" ], "source_refs": [ "SRC-084", "SRC-007", "SRC-008", "SRC-019", "SRC-085" ] }, { "id": "sig-prep-fn-request-external-proof", "name": "Request a signature or proof from an external executor", "description": "Dispatches the pinned protected input and configuration to the designated external executor and records the correlation, dispatch instant and acknowledgement. Signer authorization and primitive execution are performed by the executor; this function records only the handoff and its outcome.", "inputs": [ "Signing input manifest reference", "Pinned proof configuration reference", "Executor endpoint reference from the Dimension's executor registry", "Operation mode (synchronous or asynchronous)", "Response delivery reference where asynchronous", "Idempotency key", "Expected request revision" ], "outputs": [ "Dispatched request record with correlation identifier and current revision", "Dispatch instant and unchanged expiry instant", "Executor acknowledgement reference", "Dispatch outcome code" ], "preconditions": [ "The request record is in a state permitting dispatch and the expected request revision matches; a mismatch refuses the dispatch with a precondition failure", "Re-dispatch under the same idempotency key returns the existing dispatch, creates no second request and does not extend the expiry window", "Every reference in the outgoing payload resolves to immutable content pinned by digest; any mutable reference fails the dispatch", "No private key material, key-activation secret or authorization credential value is included in the payload", "The executor endpoint is registered by the adopting Dimension and the channel is authenticated" ], "effects": [ "Transitions the request record from prepared to dispatched and starts the expiry window", "Delegates key access, signer or prover authorization and cryptographic primitive execution wholly to the executor", "Records the correlation and acknowledgement only; asserts nothing about whether the executor will or should produce a proof" ], "source_refs": [ "SRC-085", "SRC-009", "SRC-086", "SRC-087" ] }, { "id": "sig-prep-fn-attach-proof", "name": "Admit and attach a returned proof", "description": "Runs the full admission check set against a returned proof and, only on a complete pass, appends it as an immutable host-bound version. Refuses mismatched, expired, replayed, duplicate and unsolicited proofs.", "inputs": [ "Returned proof octets and declared proof metadata", "Claimed request correlation identifier", "Idempotency key", "Expected host version or entity-tag", "Expected request revision" ], "outputs": [ "Admission outcome record: accepted, or refused with reason codes", "On acceptance, a new host-bound attached proof version", "Resulting proof set membership or chain position with previous-proof reference", "Response receipt instant and attachment instant as RFC 3339 with seconds and explicit offset" ], "preconditions": [ "A dispatched, unexpired request record exists for the claimed correlation identifier; an unsolicited or already-closed correlation is refused", "The protected input recomputed from the pinned payload version is byte-identical to the manifest value", "The returned algorithm, parameters and verification-method reference equal the pinned proof configuration exactly", "The returned context bindings — domain or audience, challenge or nonce, presentation header — equal the pinned values", "The replay scope key of nonce, host record, proof purpose and audience has not been used before", "The response was received at or before the request expiry instant", "The expected host version and expected request revision both match; a mismatch fails attachment with a precondition failure", "Replaying the same idempotency key returns the existing attachment and produces no additional host version" ], "effects": [ "On acceptance, appends exactly one immutable host-bound proof version with proof octets stored byte-exact and never re-encoded", "Closes the request record; on refusal the material is quarantined under its disposition rule and is never attached", "Alters no host payload and no previously attached proof", "Creates no host identity, grants no approval, asserts no trust standing, performs no cryptographic verification and constructs no audit trail" ], "source_refs": [ "SRC-084", "SRC-022", "SRC-019", "SRC-085", "SRC-005" ] }, { "id": "sig-life-fn-append-cosignature", "name": "Append an independent co-signature", "description": "Record an additional proof that binds independently to an already pinned payload version and canonical byte form, as an unordered member of a co-signature set. The signature bytes are produced outside this model and supplied as input.", "inputs": [ "Pinned payload version reference with canonicalization method and payload digest", "Signer or attesting party reference and verification-method or key reference", "Declared proof purpose and, where a declaration exists, the target slot identifier and declaration digest", "Externally produced signature bytes with the declared suite or algorithm identifier", "Idempotency key with request fingerprint", "Expected-version token for the co-signature set" ], "outputs": [ "Appended co-signature proof record with topology marker set to independent-set", "New proof version record and the resulting version token", "Per-slot completion state for the affected slot, reported as collected but validation-indeterminate until an external outcome is recorded", "Precondition outcome code" ], "preconditions": [ "The referenced payload version exists, is pinned, and its stored digest matches the digest supplied with the request", "Where a signing requirement declaration is bound, the declaration digest matches and the target slot's declared purpose equals the declared proof purpose", "The idempotency key is unused, or is replayed with an identical request fingerprint", "The expected-version token equals the current version token of the target set" ], "effects": [ "Appends one new proof record and one new version record; no existing record is modified", "Leaves every sibling co-signature and its recorded outcomes unchanged", "Does not compute, verify or validate the signature; validation outcomes are recorded only when returned by the external validator", "Does not create, evaluate or enforce any authorization decision and does not assert that a threshold has been reached", "Does not write to any key, certificate, status-list, transparency-log or audit store" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-085", "SRC-019" ] }, { "id": "sig-life-fn-append-countersignature", "name": "Append a dependency-aware countersignature", "description": "Record a proof that covers the exact bytes or digest of one named prior signature, occupying the next free ordinal in that signature's dependency chain. The covered signature is left byte-for-byte unchanged.", "inputs": [ "Reference to the covered prior proof record and the digest of the exact covered bytes", "Chain root reference and the dependency binding kind", "Countersigning party reference, verification-method reference, declared purpose and attestation scope", "Externally produced countersignature bytes with the declared suite or algorithm identifier", "Idempotency key with request fingerprint", "Expected-version token for the chain" ], "outputs": [ "Appended countersignature record with an assigned chain ordinal and topology marker set to dependency-chain", "Recorded dependency edge from the new position to the covered position", "New proof version record and the resulting version token", "Per-dependency-position completion state, propagating indeterminate where the covered position has no recorded outcome" ], "preconditions": [ "The covered prior proof record exists, is immutable and its stored digest equals the digest supplied with the request", "The requested position is the next free ordinal for the named chain root, and no ordinal is being reused or renumbered", "The dependency binding kind is declared explicitly, distinguishing covered-bytes binding from prior-proof-identifier pointing", "The idempotency key is unused or replayed with an identical fingerprint, and the expected-version token matches the chain's current version token" ], "effects": [ "Appends one ordered chain position and one version record; the covered signature bytes and every earlier position remain unchanged", "Records that a later position may never report a stronger status than the position it covers", "Does not compute or verify any signature and does not upgrade a recorded status indication", "Does not reorder, remove or rewrite any existing position; an order correction requires a superseding chain", "Does not decide, evaluate or enforce policy and does not write to an external audit or log store" ], "source_refs": [ "SRC-015", "SRC-006", "SRC-004", "SRC-085" ] }, { "id": "sig-life-fn-assert-invalidation", "name": "Append a scoped invalidation assertion", "description": "Record a reasoned assertion by an entitled party that a named scope, namely the proof instance, the signer or key binding, the payload binding or one named policy use, should no longer be relied upon from a stated instant.", "inputs": [ "Invalidation scope code and reference to the exact target within that scope", "Reason code from the governed list and human-readable reason text", "Asserting party reference and entitlement evidence reference", "Effective instant, retroactivity declaration, and any supporting external event references", "Idempotency key with request fingerprint and expected-version token for the target" ], "outputs": [ "Appended invalidation assertion record", "Updated reliance signal for the named scope, effective from the stated instant", "New version record and the resulting version token", "Entitlement marker where the asserting party's entitlement could not be established" ], "preconditions": [ "The target of the named scope exists and is identified unambiguously", "The scope is exactly one of the four permitted scopes; broader effects require separate assertions", "The effective instant is present and expressed with seconds and an explicit offset", "Idempotency and expected-version preconditions are satisfied" ], "effects": [ "Appends one immutable assertion record; the target proof record and its bytes remain stored and unaltered", "Does not revoke a key, subkey or certificate and does not create or modify any credential status-list entry", "Does not delete proof bytes, host content or any external log entry", "Does not enforce non-reliance; enforcement belongs to the relying party's own policy component", "Does not alter sibling co-signatures unless each is separately named by its own assertion" ], "source_refs": [ "SRC-091", "SRC-090", "SRC-052", "SRC-092" ] }, { "id": "sig-life-fn-record-supersession", "name": "Record a supersession or correction link", "description": "Append a directed link stating that one proof or proof version replaces or corrects another, with a reason and an effective interval, without altering the superseded record or asserting anything about its cryptographic validity.", "inputs": [ "Reference to the superseding record and to the superseded record", "Supersession reason code and derivation kind", "Effective-from instant and optional effective-until instant", "Idempotency key with request fingerprint and expected-version token" ], "outputs": [ "Appended supersession link record", "Effective interval with any detected overlap or gap reported explicitly", "New version record and the resulting version token", "Projection note where the target securing mechanism cannot carry an explicit replacement pointer" ], "preconditions": [ "Both records exist, are immutable and are readable at the time of the append", "Appending the link introduces no cycle in the supersession graph", "Interval endpoints are expressed with seconds and an explicit offset, and effective-until, where present, is not earlier than effective-from", "Any pre-existing conflicting link on the superseded record is itself already superseded, or the conflict is recorded rather than silently resolved" ], "effects": [ "Appends one directed derivation link and one version record; the superseded record and its recorded outcomes remain unchanged", "Does not by itself invalidate the superseded proof; non-reliance requires a separate invalidation assertion", "Does not modify effective intervals of other links and does not merge overlapping intervals", "Does not refresh, re-issue or re-sign any payload and does not trigger any external issuance process" ], "source_refs": [ "SRC-090", "SRC-092", "SRC-005", "SRC-085" ] }, { "id": "sig-life-fn-project-completion-state", "name": "Project multi-party completion state", "description": "Compute a read-only, time-labelled report of how far a bound participation declaration has been fulfilled, per declared slot and per dependency position, relaying externally supplied validation outcomes verbatim and marking everything unsupported by evidence as indeterminate.", "inputs": [ "Bound participation declaration reference and its digest", "Collected co-signature and countersignature records for the same pinned payload version", "Validation status indications and sub-indications supplied by the external validator, each with its own observation time", "Optional reference to an external decision result that explicitly states requirement satisfaction", "Observation instant for the projection" ], "outputs": [ "Per-slot completion state and per-dependency-position state, each with its supporting evidence reference", "Counts by state, labelled as counts of recorded facts only", "Indeterminate entries with coded and human-readable reasons, including stale, missing and contradictory evidence", "A satisfaction statement only where an external decision result explicitly states it, reproduced verbatim with its source reference", "Sealed-slot and aggregate-attribution markers where per-party attribution is not available" ], "preconditions": [ "Read-only access is sufficient and no mutation is attempted", "The declaration is bound to the same pinned payload version as the collected proofs and its digest matches", "Every relayed validation outcome carries its issuing validator reference and observation time", "The projection observation instant is supplied and expressed with seconds and an explicit offset" ], "effects": [ "Changes no state and appends no record", "Performs no cryptographic verification and derives no validation status of its own", "Never infers threshold satisfaction, authorization or workflow approval from a count of collected signatures", "Reports a threshold-produced signature as exactly one slot and never as multiple parties", "Produces a projection that is superseded by recomputation rather than stored as an authoritative verdict" ], "source_refs": [ "SRC-061", "SRC-093", "SRC-004", "SRC-092" ] }, { "id": "sig-vop-fn-pin-run-inputs", "name": "Assemble and validate verification run inputs", "description": "Collects the caller-supplied and defaulted parameters for a verification, checks that every required pin is present and resolvable, and produces a canonical pinned input set with its digest. Refuses to proceed when a required pin is missing rather than substituting a silent default.", "inputs": [ "Subject proof reference and payload version reference", "Requested validation or as-of time", "Trust anchor set reference and snapshot selector", "Cryptographic suite policy reference and version", "Status evidence freshness limit, where constrained", "Evaluating tool identity and configuration digest" ], "outputs": [ "Canonical pinned input set", "Pinned input digest", "Missing or unresolvable pin list with refusal codes" ], "preconditions": [ "The subject proof and the payload version it is asserted to cover are both resolvable", "The referenced trust anchor snapshot and policy version exist and are readable" ], "effects": [ "Produces an immutable pinned input set that later runs and comparisons reference", "Records a refusal with codes when the input set cannot be made determinate; no evaluation occurs" ], "source_refs": [ "SRC-061", "SRC-043", "SRC-013", "SRC-097" ] }, { "id": "sig-vop-fn-resolve-time-basis", "name": "Resolve time basis and proofs of existence", "description": "Calculates which time value the verdict will be anchored to and assembles the proof-of-existence assertions available from referenced time-stamp tokens and evidence records, recording production and observation instants separately. Performs no timestamping and requests no new time evidence.", "inputs": [ "Pinned input set", "Referenced time-stamp tokens and evidence unit references", "Claimed signing time carried by the proof, where present" ], "outputs": [ "Selected time anchor with its selection rule", "Proof-of-existence assertion set", "Best signature time, or an explicit statement that none is derivable" ], "preconditions": [ "The pinned input set includes a validation or as-of time", "Each referenced evidence object is resolvable, or its absence is recorded" ], "effects": [ "Fixes the temporal basis used by every dimension of the run", "Marks self-asserted times as unproven when no independent evidence supports them" ], "source_refs": [ "SRC-061", "SRC-009", "SRC-066", "SRC-003", "SRC-097" ] }, { "id": "sig-vop-fn-evaluate-dimensions", "name": "Evaluate and record verification dimensions", "description": "Evaluates the cryptographic, trust, evidence-completeness, policy, identity-attribution and legal-conclusion dimensions against the pinned inputs and resolved time basis, and records each with its own status and reason codes. Cryptographic primitive computation and certification path construction are performed by the referenced external evaluator; this function consumes their reported outcomes and does not enforce any decision.", "inputs": [ "Pinned input set and pinned input digest", "Resolved time basis and proof-of-existence assertions", "Outcomes reported by the external cryptographic and path-validation evaluator", "Status and evidence objects consulted" ], "outputs": [ "Per-dimension status with ordered reason codes and code system references", "Consulted validation object reference list", "Not-evaluated markers for dimensions outside the run's remit" ], "preconditions": [ "Input pins are complete and the input digest is computed", "A reason code system is declared and its version recorded" ], "effects": [ "Records a verdict per dimension without producing an aggregate pass or fail", "Sets the legal-conclusion dimension to not-determined-here unless an external determination is referenced" ], "source_refs": [ "SRC-061", "SRC-095", "SRC-004", "SRC-013", "SRC-097" ] }, { "id": "sig-vop-fn-emit-run-record", "name": "Emit verification run record and report projection", "description": "Writes the append-only run record and projects it into a selected report binding, carrying the subject reference, pinned inputs, dimension results, consulted objects, asserting party and times so the projection is self-describing away from its store.", "inputs": [ "Dimension results and consulted object list", "Pinned input set and digest", "Asserting party reference and execution instants", "Requested report binding identifier and version" ], "outputs": [ "Stored run record with its identifier", "Report projection in the requested binding", "Projection notes where the binding cannot carry a field" ], "preconditions": [ "Dimension evaluation is complete or explicitly marked not evaluated", "An asserting party is identified" ], "effects": [ "Creates an immutable run record; corrections are made only by a superseding record", "Produces one or more non-authoritative projections that always reference the run identifier" ], "source_refs": [ "SRC-095", "SRC-004", "SRC-013", "SRC-097" ] }, { "id": "sig-vop-fn-compare-runs", "name": "Compare two verification runs and attribute change", "description": "Checks that two runs are comparable, computes per-dimension differences retaining both prior and later values, and attributes each difference to a cause class such as elapsed time, trust anchor change, status evidence change, policy change, algorithm sunset, added preservation evidence or tool change. Leaves unexplained differences flagged rather than forcing an attribution.", "inputs": [ "References to the earlier and later run records", "Pinned input sets of both runs", "Evidence units registered between the two runs" ], "outputs": [ "Comparability verdict with invariant check results", "Per-dimension difference set with assigned cause classes", "Unattributed difference list" ], "preconditions": [ "Both run records are retrievable with their pinned input sets", "The subject proof and payload version invariants are checkable" ], "effects": [ "Produces a comparison record that adds interpretation without altering either run", "Never marks the earlier verdict as wrong, superseded or retracted" ], "source_refs": [ "SRC-061", "SRC-043", "SRC-096", "SRC-013", "SRC-097" ] }, { "id": "sig-vop-fn-register-evidence-unit", "name": "Register a preservation evidence unit", "description": "Records an evidence unit obtained from an external timestamping or preservation service against a proof, capturing its kind, renewal kind, coverage set, chain and sequence position, producing service and policy, and both production and observation instants. Registration is additive and byte-preserving; it neither generates nor re-signs evidence.", "inputs": [ "Evidence unit as received from its producing service", "Producing service reference and policy or profile identifier", "Subject proof reference and asserted coverage set", "Pre-registration fixity value of the original proof" ], "outputs": [ "Registered evidence unit with its identifier and chain position", "Post-registration fixity confirmation for the original proof", "Rejection record where the unit would require modifying the proof or its coverage cannot be resolved" ], "preconditions": [ "The subject proof exists and its current fixity value is known", "The producing service reference and its policy identifier are supplied" ], "effects": [ "Appends the unit to the evidence sequence without altering the original proof or any earlier unit", "Refuses registration and records a reason when additivity or coverage cannot be demonstrated" ], "source_refs": [ "SRC-009", "SRC-066", "SRC-067", "SRC-072", "SRC-098" ] }, { "id": "sig-vop-fn-assess-renewal-need", "name": "Assess evidence coverage and renewal need", "description": "Calculates the currently covered interval, detects chain discontinuities, derives the sunset horizon of every digest and signature algorithm in the chain under the pinned policy, and reports the latest date by which further evidence must be obtained. Reports only; it does not request, schedule or obtain evidence.", "inputs": [ "Registered evidence unit set for the proof", "Cryptographic suite policy reference and version", "Assessment as-of time" ], "outputs": [ "Coverage interval or an explicit uncovered statement", "Chain gap list and per-algorithm sunset horizons", "Renewal-by date with severity and the accountable party reference" ], "preconditions": [ "An algorithm policy version is pinned for the assessment", "The evidence set revision used is recorded" ], "effects": [ "Produces a derived assessment that must be recomputed when evidence, policy or the clock changes", "Raises a recommendation without initiating any preservation action" ], "source_refs": [ "SRC-066", "SRC-067", "SRC-096", "SRC-097", "SRC-072" ] }, { "id": "sig-vop-fn-project-export", "name": "Project a proof and evidence into a target binding", "description": "Builds an export in a selected binding after evaluating payload disclosure and signer-identity disclosure authorisations separately, enumerates every projection loss with its class and effect on verifiability, and refuses the export outright when the binding cannot carry a critical semantic.", "inputs": [ "Subject proof reference and selected evidence unit references", "Target binding identifier and version", "Payload disclosure authorisation and signer-identity disclosure authorisation", "Requesting party reference and stated purpose" ], "outputs": [ "Export package with its export identifier, or a refusal with a machine-readable code", "Projection loss register", "Fixed non-implication statement bound into the export" ], "preconditions": [ "Both disclosure authorisations have been resolved independently by the referenced access model", "The target binding and version are known and their carrying capability is described" ], "effects": [ "Creates an export event record separate from the identity of the proof", "Refuses rather than silently downgrading when unsupported critical semantics are present", "Never attaches or implies a verification verdict; any verdict travels only as a referenced run record" ], "source_refs": [ "SRC-095", "SRC-067", "SRC-007", "SRC-004", "SRC-013" ] }, { "id": "sig-vop-fn-report-disposition-readiness", "name": "Report disposition readiness", "description": "Computes and reports whether a proof and its evidence are currently blocked from disposition, enumerating host lifecycle state, retention rule reference, active holds, outstanding preservation obligations and blocking inbound references, and stating which external systems own execution and recording of any disposal.", "inputs": [ "Subject proof reference and its evidence unit set", "Host record lifecycle state and retention rule reference", "Active hold or freeze references", "Preservation arrangement obligations and inbound dependency references", "Readiness as-of time" ], "outputs": [ "Readiness state with the as-of time", "Enumerated blocking conditions with classes and source references", "Tombstone content specification and the external execution and recording owners" ], "preconditions": [ "The host record and its retention rule reference are resolvable, or their absence is recorded as a blocking condition", "Hold and preservation references are readable from their owning models" ], "effects": [ "Produces a dated readiness report that expires with its as-of time", "Makes no disposal decision, issues no instruction to delete and releases no hold" ], "source_refs": [ "SRC-066", "SRC-097", "SRC-072", "SRC-098", "SRC-078" ] } ], "composition": [ { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "Register this proof mixin beneath its parent cross-cutting model so shared conventions for host attachment and reference handling are inherited rather than restated here.", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "Host record model that the proof secures", "relation": "MIX-IN", "purpose": "Attach proofs to any signable host record. The host's content model, canonical representation, transforms and lifecycle remain entirely with the host model; only the binding declaration is carried here.", "required": true, "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ] }, { "target": "Cryptographic key and verification-method model", "relation": "REFERENCE", "purpose": "Resolve the nominated verification method and its controller. Key generation, storage, rotation, revocation and all secret material stay with that model; this model carries only the reference, its form and its coverage flag.", "required": true, "source_refs": [ "SRC-001", "SRC-004", "SRC-007" ] }, { "target": "Party and agent identity model covering natural persons, legal persons, devices and software agents", "relation": "REFERENCE", "purpose": "Resolve claimed signer, signing actor, controller, credential subject and represented party. Identity records, their assurance and their lifecycle are owned there.", "required": true, "source_refs": [ "SRC-005", "SRC-011" ] }, { "target": "Credential and public-key certificate model", "relation": "REFERENCE", "purpose": "Resolve certificates, verifiable credentials and holder key confirmations invoked by a proof. Issuance, subject claims, status and revocation are owned there.", "required": true, "source_refs": [ "SRC-005", "SRC-006", "SRC-010" ] }, { "target": "Trust anchor and trusted list model", "relation": "REFERENCE", "purpose": "Reference the trust anchors and trusted lists a verifier used. Anchor selection, list publication and qualification determination are owned there.", "required": false, "source_refs": [ "SRC-013", "SRC-011" ] }, { "target": "Time-stamping and proof-of-existence model", "relation": "REFERENCE", "purpose": "Reference external attestations that a proof or its content existed before a stated instant. Token issuance, authority operation and accuracy claims are owned there.", "required": false, "source_refs": [ "SRC-009", "SRC-003" ] }, { "target": "Signature validation policy and validation report model", "relation": "REFERENCE", "purpose": "Reference the validation policy applied and the report produced. Evaluation, constraint interpretation, indication assignment and enforcement of outcomes are owned there; only the resulting status value and report reference are recorded here.", "required": true, "source_refs": [ "SRC-013", "SRC-004" ] }, { "target": "Authorization policy and decision model", "relation": "REFERENCE", "purpose": "Reference the policy that decides whether a signer was permitted to sign. Policy authoring, evaluation and enforcement are owned there; this model only declares whether authorization is asserted and on what basis.", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] }, { "target": "Event and audit record model", "relation": "REFERENCE", "purpose": "Emit and reference audit records for status, state and disposition changes. Audit-trail semantics, immutability guarantees and audit retention are owned there.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "W3C Verifiable Credential Data Integrity proof model", "relation": "ALIGN", "purpose": "Align the local proof fields with the Data Integrity proof properties, proof sets and proof chains, and verification result structure, recording mapping and residual differences without claiming conformance.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "IETF CMS SignedData, JOSE JWS and COSE signature structures", "relation": "ALIGN", "purpose": "Align binding modes, protected and unprotected coverage, signer identification, multiple-signature handling and countersignature semantics across the principal container families, recording where their meanings diverge.", "required": false, "source_refs": [ "SRC-006", "SRC-007", "SRC-008" ] }, { "target": "AdES baseline levels, commitment types and qualified signature and seal profiles", "relation": "ALIGN", "purpose": "Align proof kind, qualification claim, commitment type and recorded status with the European validation model and regulated categories, as a regionally bounded alignment only.", "required": false, "source_refs": [ "SRC-013", "SRC-011" ] }, { "target": "NIST approved signature algorithm suites (FIPS 186-5 and FIPS 204)", "relation": "ALIGN", "purpose": "Align method identifiers, parameter sets and claimed security categories with an approved-algorithm regime, without importing algorithm specification or approval authority.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Selective-disclosure and holder key-binding presentation profile", "relation": "ALIGN", "purpose": "Align selective-disclosure proof kinds, disclosure digests and holder key binding as a qualified proof kind, keeping disclosure mechanics and unlinkability properties with that profile.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "WM-XCT-006 - registered parent model of the XCT signature and proof family", "relation": "CHILD", "purpose": "WM-XCT-034 is registered beneath WM-XCT-006, which holds the shared signature and proof frame; this model contributes the mixin a host record carries. The structural precedent is that signature containers hold signer information and content binding as separate parts of one enclosing structure.", "required": true, "source_refs": [ "SRC-006", "SRC-008" ] }, { "target": "Host statement, artifact-version, field-set, graph or event model of the adopting Dimension", "relation": "MIX-IN", "purpose": "This model attaches to a host record to declare what is protected. The host retains identity, versioning, storage, editorial lifecycle and deletion execution; the cited standards permit the protected content to be absent from the signature structure entirely, which makes the separation explicit.", "required": true, "source_refs": [ "SRC-006", "SRC-016", "SRC-004" ] }, { "target": "Canonicalization and transform algorithm provider covering XML canonicalization, RDF dataset canonicalization, JSON canonicalization and equivalents", "relation": "REFERENCE", "purpose": "Structured payloads must be converted to an octet stream before digesting. This model carries the algorithm identifier and version in the digest input description only; the algorithm's mechanics, parsers and edge-case behaviour stay with the provider.", "required": true, "source_refs": [ "SRC-016", "SRC-004" ] }, { "target": "Digest and proof algorithm registries including IANA JOSE and COSE registries, XML Security algorithm identifiers, cryptosuite registries and media-type registries", "relation": "ALIGN", "purpose": "Algorithm and content-type identifiers are taken verbatim from governed registries with a recorded registry version; this model never redefines or paraphrases an identifier or its semantics.", "required": true, "source_refs": [ "SRC-007", "SRC-006", "SRC-008", "SRC-016", "SRC-004" ] }, { "target": "Proof method, signer and key material model covering verification method, certificates, trust anchors and cryptographic execution", "relation": "REFERENCE", "purpose": "The chosen proof method fixes which protected-input construction applies and whether purpose, audience and expiry parameters are relied on. Key material, signer identity and the computation of any digest or signature remain with that model; this model carries descriptors and recorded outcomes.", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-004" ] }, { "target": "IETF RFC 5652 Cryptographic Message Syntax SignedData content binding", "relation": "ALIGN", "purpose": "Alignment to encapsulated content type and detached content, the mandatory content-type and message-digest signed attributes, and the verification requirement that the signed content-type match the encapsulated type. Recorded with version and section; no conformance is claimed without test evidence.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "IETF RFC 7515 and RFC 7797 JWS signing input and unencoded payload option", "relation": "ALIGN", "purpose": "Alignment to a single concatenated signing input, the protected versus unprotected header split, the critical must-be-understood parameter, and the payload encoding flag that itself changes the protected bytes.", "required": false, "source_refs": [ "SRC-007", "SRC-014" ] }, { "target": "IETF RFC 9052 COSE Sig_structure and RFC 9338 Countersign_structure", "relation": "ALIGN", "purpose": "Alignment to the explicit signing structure with body and signer protected buckets, externally supplied authenticated data, detached payload representation, and the countersignature structure that binds the finalized target's signature value.", "required": false, "source_refs": [ "SRC-008", "SRC-015" ] }, { "target": "W3C XML Signature Syntax and Processing Version 1.1 Reference model", "relation": "ALIGN", "purpose": "Alignment to digest-based reference binding, the optional reference locator, the advisory type attribute, the transform chain as selection, and the two-step core validation separating reference checking from signature checking.", "required": false, "source_refs": [ "SRC-016" ] }, { "target": "W3C Verifiable Credential Data Integrity 1.0 proof binding", "relation": "ALIGN", "purpose": "Alignment to the transformation, hashing and proof serialization stages, the proof purpose, domain, challenge, nonce and expiry parameters, and proof chains bound through a previous-proof reference.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "C2PA Technical Specification hard-binding assertions", "relation": "ALIGN", "purpose": "Alignment to selected-part protection over media: byte-range hashing with exclusion ranges, box and container hashing, hashed URI references, and the constraint that excluded content must not change interpretation of the protected part.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "Time-stamping authority and trusted-time model", "relation": "REFERENCE", "purpose": "A time-stamp binds only a hash imprint of the protected input, and the authority never inspects the datum. This model may carry the digest and a token reference; issuing, operating, trusting or evaluating a time-stamp is external.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Content repository and version master system", "relation": "REFERENCE", "purpose": "Supplies the authoritative content identifier, version and retrievable octets, and owns storage, versioning and the execution of retention and erasure. This model records the reference and pins the representation by digest.", "required": true, "source_refs": [ "SRC-016", "SRC-017", "SRC-018" ] }, { "target": "Verification evaluator, enforcement and audit-trail model", "relation": "REFERENCE", "purpose": "Executes reference and signature validation, evaluates purpose, audience and expiry, enforces acceptance or rejection and operates the audit trail. This model supplies binding descriptors and comparison inputs and retains outcomes as evidence only; referencing the evaluator grants no ownership of evaluation, execution, enforcement or audit-trail semantics.", "required": true, "source_refs": [ "SRC-016", "SRC-004" ] }, { "target": "Approval workflow and countersignature orchestration model", "relation": "REFERENCE", "purpose": "Determines who signs, in what order and with what business consequence. This model only preserves the exact finalized protected input a dependent proof must bind and records the chain ordinal.", "required": false, "source_refs": [ "SRC-006", "SRC-015", "SRC-004" ] }, { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "Attach the canonical-derivation and context-binding surface to the parent cryptographic and trust model, which owns the signature value, the key reference and the trust posture; this model owns only what those bytes are and how they were produced.", "required": true, "source_refs": [ "SRC-007", "SRC-008", "SRC-016" ] }, { "target": "Signed host record types in the adopting Dimension", "relation": "MIX-IN", "purpose": "Attach this mixin's declarations to any host record that carries or references a signature or proof, without importing the host's own lifecycle, states or business semantics.", "required": true, "source_refs": [ "SRC-004", "SRC-016" ] }, { "target": "Payload / host subject model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Carry the reference, resolution context and digest of the data object that entered the chain, and the reference to the retained pre-transform representation; identity, semantics and custody of that content stay in the target.", "required": true, "source_refs": [ "SRC-016", "SRC-017", "SRC-024" ] }, { "target": "Proof verification and key-resolution model", "relation": "REFERENCE", "purpose": "Carry the verification-method reference and the binding parameters a verifier consumes, and store the outcome it reports as evidence; signature computation, key resolution and the accept or reject decision remain in the target.", "required": true, "source_refs": [ "SRC-004", "SRC-007", "SRC-008" ] }, { "target": "Security-policy evaluation, enforcement and audit model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Expose criticality declarations, admitted-transform references and complexity limits for evaluation; refusal of unrecognised critical steps, enforcement and audit-trail storage are executed and retained by the target.", "required": true, "source_refs": [ "SRC-023", "SRC-027", "SRC-007" ] }, { "target": "W3C Canonical XML 1.1 and Canonical XML 2.0", "relation": "ALIGN", "purpose": "Map declared XML canonicalization algorithm identifiers, named parameters and their documented defaults; the algorithms and their known defects remain defined by W3C.", "required": false, "source_refs": [ "SRC-020", "SRC-030" ] }, { "target": "RFC 8785 JSON Canonicalization Scheme", "relation": "ALIGN", "purpose": "Map JSON-family ordering, escaping, number serialization and I-JSON validity declarations onto the normalization findings without adopting them as universal rules.", "required": false, "source_refs": [ "SRC-019", "SRC-028" ] }, { "target": "W3C RDF Dataset Canonicalization (RDFC-1.0)", "relation": "ALIGN", "purpose": "Map graph-shaped canonicalization: algorithm identifier, internal hash algorithm parameter, canonical N-Quads output and the complexity limits guarding against poison datasets.", "required": false, "source_refs": [ "SRC-021" ] }, { "target": "W3C Verifiable Credential Data Integrity 1.0 cryptosuites", "relation": "ALIGN", "purpose": "Map versioned cryptosuite identifiers, the transform-hash-prove pipeline and the proofPurpose, domain, challenge and previousProof bindings; cryptosuite definitions and proof verification remain with W3C and the verifier.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "IETF JOSE and COSE signing-input structures (RFC 7515, RFC 9052)", "relation": "ALIGN", "purpose": "Map protected versus unprotected regions, structure context strings, external additional authenticated data and critical-header semantics onto the chain and context-binding declarations.", "required": false, "source_refs": [ "SRC-007", "SRC-008", "SRC-029" ] }, { "target": "RFC 9421 HTTP Message Signatures signature base", "relation": "ALIGN", "purpose": "Map covered-component selection, derived components and signature parameters onto the coverage and context-binding findings, including the documented component-source ambiguity risk.", "required": false, "source_refs": [ "SRC-022" ] }, { "target": "Unicode Standard Annex #15 Normalization Forms", "relation": "ALIGN", "purpose": "Map the declared normalization form and Unicode version, and the irreversibility of compatibility normalization, onto the lexical normalization and fidelity findings.", "required": false, "source_refs": [ "SRC-025" ] }, { "target": "C2PA hard-binding hash assertions with exclusion ranges", "relation": "ALIGN", "purpose": "Map exclusion-list coverage over binary assets and deterministic claim serialization onto the coverage and chain findings; assertion semantics and manifest structure remain with C2PA.", "required": false, "source_refs": [ "SRC-017", "SRC-029" ] }, { "target": "RFC 8725 JSON Web Token Best Current Practices", "relation": "ALIGN", "purpose": "Map explicit typing, mutually exclusive validation rules per structure kind and audience validation onto the context-binding and threat-posture declarations; the validation logic itself belongs to the verifier.", "required": false, "source_refs": [ "SRC-027" ] }, { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "WM-XCT-034 is registered beneath WM-XCT-006, which owns the broader containing concern into which a proof is bound. This model contributes only proof binding, projection and interoperability semantics and never restates the parent's record identity, lifecycle or operational functions.", "required": true, "source_refs": [ "SRC-033", "SRC-016" ] }, { "target": "Host artifact or signable record model of the adopting Dimension", "relation": "MIX-IN", "purpose": "As a mixin, WM-XCT-034 attaches proof structure to a host record. The host keeps its own identity, versioning and revision history; this model contributes only the attachment point, the covered region and the binding declarations.", "required": true, "source_refs": [ "SRC-033", "SRC-016", "SRC-036" ] }, { "target": "IETF RFC 7515 JSON Web Signature with RFC 7797 unencoded payload option", "relation": "ALIGN", "purpose": "Alignment target for the JWS projection: serialization variants, protected and unprotected header semantics, criticality, key-identification headers, detached content and the b64 restrictions. Alignment only; no conformance is claimed and the specification is not reproduced.", "required": false, "source_refs": [ "SRC-007", "SRC-014" ] }, { "target": "IETF RFC 9052 COSE with RFC 9338 countersignatures and RFC 9360 X.509 header parameters", "relation": "ALIGN", "purpose": "Alignment target for the COSE projection: structure choice and tags, header buckets, Sig_structure context, detached nil payload, external authenticated data, countersignature coverage and certificate carriage parameters.", "required": false, "source_refs": [ "SRC-008", "SRC-015", "SRC-031", "SRC-032" ] }, { "target": "IETF RFC 5652 Cryptographic Message Syntax with ETSI EN 319 122-1 CAdES", "relation": "ALIGN", "purpose": "Alignment target for the CMS and CAdES projection: external signatures, signer identification, signed and unsigned attributes, certificate and CRL carriage and baseline levels. ETSI clause-level requirements are recorded as unverified where the text was not machine-retrievable.", "required": false, "source_refs": [ "SRC-006", "SRC-039" ] }, { "target": "W3C XML Signature Syntax and Processing 1.1 with ETSI EN 319 132-1 XAdES", "relation": "ALIGN", "purpose": "Alignment target for the XML projection: the three classical forms, Reference and transform processing, canonicalization, Object and Manifest placement, and signed and unsigned qualifying properties.", "required": false, "source_refs": [ "SRC-016", "SRC-035", "SRC-040" ] }, { "target": "ETSI EN 319 142-1 PAdES over ISO 32000-2 PDF 2.0", "relation": "ALIGN", "purpose": "Alignment target for the PDF projection: signature dictionary and SubFilter pair, byte-range coverage, incremental-update placement, document timestamps and Document Security Store carriage. ISO clause content is paywalled and is treated as an unverified alignment target.", "required": false, "source_refs": [ "SRC-036", "SRC-041", "SRC-042" ] }, { "target": "W3C Verifiable Credential Data Integrity 1.0 with Securing Verifiable Credentials using JOSE and COSE", "relation": "ALIGN", "purpose": "Alignment target for embedded proof properties and enveloping proofs: DataIntegrityProof structure, proof purpose, proof sets and chains, transformation requirements, and the registered credential media types.", "required": false, "source_refs": [ "SRC-004", "SRC-034" ] }, { "target": "External signature encoder, parser and validator runtime", "relation": "REFERENCE", "purpose": "This model carries the runtime reference, the profile binding and subject-specific parameters. Encoding, parsing, canonicalization, digest and signature computation, verification, enforcement of blocking conditions and any audit record the runtime emits are owned entirely by that runtime.", "required": true, "source_refs": [ "SRC-007", "SRC-016", "SRC-004" ] }, { "target": "X.509 certificate, trust-status and revocation-evidence model", "relation": "REFERENCE", "purpose": "Carries key-identification mechanisms and pointers to certificates, chains, thumbprints and revocation items. Path building, trust anchor selection, revocation determination and certificate lifecycle stay with the referenced model.", "required": true, "source_refs": [ "SRC-031", "SRC-006" ] }, { "target": "Time-stamp token model per IETF RFC 3161", "relation": "REFERENCE", "purpose": "Records the attachment point of a timestamp and what its message imprint covers. Token issuance, TSA policy, accuracy interpretation and the token's own validation belong to the referenced model.", "required": true, "source_refs": [ "SRC-009", "SRC-036" ] }, { "target": "IANA JOSE and COSE parameter and algorithm registries", "relation": "REFERENCE", "purpose": "Supplies the governed identifier space for header parameter names, labels and algorithm values. This model pins a registry snapshot and reuses identifiers verbatim; registration procedures and expert review remain with IANA and the defining specifications.", "required": true, "source_refs": [ "SRC-038", "SRC-032" ] }, { "target": "WM-XCT-006 (registered parent model of WM-XCT-034)", "relation": "CHILD", "purpose": "WM-XCT-034 is registered as a child of WM-XCT-006 and inherits its broader cryptographic-trust framing. No relation rationale is published for this parent link and the registry review state is boundary-review-required, so the division of signature identity, algorithm and evidence concerns between parent and this mixin is provisional and must not be treated as settled.", "required": true, "source_refs": [ "SRC-043", "SRC-013" ] }, { "target": "Signed subject model (any model whose records carry a signature or proof)", "relation": "MIX-IN", "purpose": "Attach signature, trust-chain and status-evidence context to a subject record without altering, duplicating or constraining the subject's own semantics or lifecycle.", "required": false, "source_refs": [ "SRC-043", "SRC-052" ] }, { "target": "Certificate authority and trust service operations model", "relation": "REFERENCE", "purpose": "Carry references to issuers, responders, revocation records and their published effective dates. Issuance, the decision to revoke or suspend, responder operation and revocation publication remain owned there; this model records only observations and captured bytes.", "required": true, "source_refs": [ "SRC-043", "SRC-044", "SRC-054" ] }, { "target": "Trust list and trust anchor store governance model", "relation": "REFERENCE", "purpose": "Pin the trust store or trust list snapshot by location, sequence number, issue date-time and digest, and record the service status observed. List issuance, supervision, qualification and status determination remain owned there.", "required": true, "source_refs": [ "SRC-046", "SRC-013", "SRC-053" ] }, { "target": "DID method registry and DID resolution model", "relation": "REFERENCE", "purpose": "Reference verification methods by DID URL and carry the resolution options supplied, the resolution metadata returned and the version pinned. DID document lifecycle, deactivation and resolver operation remain owned there.", "required": false, "source_refs": [ "SRC-050", "SRC-051" ] }, { "target": "Credential status list publication model", "relation": "REFERENCE", "purpose": "Reference the status list credential and index used for a credential-bound verification method and capture the value read. List construction, index assignment, publication cadence and herd-privacy sizing remain owned there.", "required": false, "source_refs": [ "SRC-052" ] }, { "target": "Policy decision and enforcement model", "relation": "REFERENCE", "purpose": "Carry an attributed reference to the declared failure-handling stance for missing or stale status evidence. Evaluation of that stance, the accept-or-reject decision and any enforcement action remain owned there; this model records evidence completeness only.", "required": true, "source_refs": [ "SRC-049", "SRC-054" ] }, { "target": "Time-stamping and proof-of-existence model", "relation": "REFERENCE", "purpose": "Reference the proof of existence that fixes best-signature time or supports historical replay. Token issuance, timestamping authority trust and archival preservation remain owned there.", "required": false, "source_refs": [ "SRC-044", "SRC-013" ] }, { "target": "Audit trail and event log model", "relation": "REFERENCE", "purpose": "Locate audit entries for evidence captures and replay-package exports by reference. Audit record structure, tamper evidence, retention and query semantics remain owned there; referencing an audit record grants this model no audit-trail semantics.", "required": false, "source_refs": [ "SRC-044", "SRC-013" ] }, { "target": "Cryptographic algorithm and suite registry model", "relation": "REFERENCE", "purpose": "Reference signature, digest and key-agreement suite identifiers used by the signature and by the status evidence. Algorithm implementation, execution and deprecation scheduling remain owned there.", "required": false, "source_refs": [ "SRC-043", "SRC-048" ] }, { "target": "RFC 5280 certification path validation and CRL profile", "relation": "ALIGN", "purpose": "Field-level alignment for path validation inputs, basic, name and policy constraints, key usage and extended key usage, and CRL evidence fields. Alignment only; no conformance is claimed absent a cited conformance test result.", "required": false, "source_refs": [ "SRC-043" ] }, { "target": "RFC 6960 Online Certificate Status Protocol and the RFC 9919 lightweight profile", "relation": "ALIGN", "purpose": "Field-level alignment for certificate identifier scope, status values, production and update times, responder authorization, nonce behaviour and caching. Alignment only; the profile version in use is recorded with each determination.", "required": false, "source_refs": [ "SRC-044", "SRC-048" ] }, { "target": "ETSI EN 319 102-1 signature validation indications, as documented by the European Commission DSS reference implementation", "relation": "ALIGN", "purpose": "Carry the indication and sub-indication vocabulary verbatim, in particular the indeterminate cases that distinguish incomplete evidence from cryptographic failure. The ETSI normative text could not be retrieved directly, so this alignment is provisional and is not a conformance claim.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "W3C Bitstring Status List credential status model", "relation": "ALIGN", "purpose": "Field-level alignment for credential status entries, status purposes including the reversible suspension case, and status list validity and time-to-live fields. Alignment only.", "required": false, "source_refs": [ "SRC-052" ] }, { "target": "WM-XCT-006 (parent cryptographic-context model in the XCT family)", "relation": "CHILD", "purpose": "This mixin is registered beneath WM-XCT-006 and specialises its framing for signatures and proofs only. Generic cryptographic-context identity, authority and conflict machinery stays in the parent; only signature-specific suite declaration, agility posture and verdict semantics are elaborated here.", "required": true, "source_refs": [ "SRC-001", "SRC-055" ] }, { "target": "Cryptographic key and verification-method model", "relation": "REFERENCE", "purpose": "Carry the verification-method or key reference, its algorithm binding and subject-specific parameters. Key generation, custody, rotation, revocation and device assurance remain the target's lifecycle and are not reproduced here.", "required": true, "source_refs": [ "SRC-055", "SRC-027", "SRC-004" ] }, { "target": "Certificate trust-path and revocation validation model", "relation": "REFERENCE", "purpose": "Reference the trust-path determination and its reason codes as one reported dimension of a verdict. Path construction, revocation retrieval and trusted-list evaluation are the target's operational functions.", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "target": "Time-stamp and proof-of-existence model", "relation": "REFERENCE", "purpose": "Reference time-stamp tokens as external evidence supporting a signing-time claim and as the time basis for sunset comparison. Token issuance, TSA policy and time-source traceability stay with the target.", "required": false, "source_refs": [ "SRC-009", "SRC-061" ] }, { "target": "Verification service execution and audit-record model", "relation": "REFERENCE", "purpose": "Record verifier identity, tool version and validation-report references as provenance. Executing verification, enforcing acceptance and maintaining the audit trail belong exclusively to the target.", "required": false, "source_refs": [ "SRC-062", "SRC-013" ] }, { "target": "Signed host record or artifact model", "relation": "MIX-IN", "purpose": "Attach signature and proof context to any host record or artifact. The host retains its own content model, business lifecycle and retention execution; this mixin adds only the signature, algorithm-policy and verdict facets.", "required": true, "source_refs": [ "SRC-006", "SRC-004" ] }, { "target": "NIST digital-signature algorithm catalogue (FIPS 186-5 and FIPS 204)", "relation": "ALIGN", "purpose": "Align local suite descriptors with NIST-approved algorithm names and parameter sets. NIST retains definition and approval authority; alignment is a mapping and is never recorded as a conformance claim.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "IANA COSE and JOSE algorithm registries", "relation": "ALIGN", "purpose": "Bind registry-scoped identifiers together with their recommendation or implementation-requirement states. The registries remain the change-controlled source and are referenced, never mirrored or re-minted.", "required": false, "source_refs": [ "SRC-059", "SRC-038" ] }, { "target": "ETSI AdES validation-semantics profile (EN 319 102-1 and TS 119 102-2)", "relation": "ALIGN", "purpose": "Map local outcome and reason codes onto ETSI status indications and sub-indications, marking lossy mappings explicitly. The validation procedure itself is executed under the target's rules, not here.", "required": false, "source_refs": [ "SRC-061", "SRC-062", "SRC-013" ] }, { "target": "Qualification and legal-effect determination model", "relation": "REFERENCE", "purpose": "Reference an external qualification or legal-effect determination with its jurisdiction, instrument and date as separate reported dimensions. The determination is made under the target's authority and is never inferred from a cryptographic result.", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "target": "Post-quantum transition policy model", "relation": "REFERENCE", "purpose": "Reference a named migration policy and jurisdiction that assigns the recorded migration state. Setting transition dates, mandates and compliance deadlines belongs to that policy, not to this model.", "required": false, "source_refs": [ "SRC-057", "SRC-058" ] }, { "target": "WM-XCT-006 (registered parent of WM-XCT-034)", "relation": "CHILD", "purpose": "Signature and proof evidence is a subordinate part of the enclosing cryptographic-attestation context registered as the parent. Standards treat validation data as belonging to the electronic signature rather than standing alone, so this model nests rather than competes; the parent supplies the enclosing subject and its own identity and lifecycle.", "required": true, "source_refs": [ "SRC-068", "SRC-061" ] }, { "target": "Subject entity models carrying signed artefacts (documents, credentials, records, messages) in the adopting Dimension", "relation": "MIX-IN", "purpose": "As a mixin this model attaches proof and validation evidence to any signed subject without redefining that subject's identity, classification or lifecycle. The subject model remains the system of record for the object; this model records only what proves and validates the signature over it.", "required": true, "source_refs": [ "SRC-068", "SRC-061" ] }, { "target": "Trust-service registry model covering certification and time-stamping authorities, trusted lists and supervision status", "relation": "REFERENCE", "purpose": "Carry authority identifiers, certificate references, policy pointers, a trusted-list state digest and the observed qualification status as parameters of a specific validation. Issuance, supervision, status publication and authority lifecycle stay with the target; this model must not reproduce or re-derive them.", "required": true, "source_refs": [ "SRC-043", "SRC-013", "SRC-070" ] }, { "target": "Transparency-log model covering append-only log operation, checkpoints and monitoring", "relation": "REFERENCE", "purpose": "Carry log identity, entry locator and proof references as optional corroboration of publication, with a mandatory negative scope statement. Log operation, merge delay, gossip, monitoring and the log's own audit semantics remain with the target.", "required": false, "source_refs": [ "SRC-069" ] }, { "target": "Signed content and document model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Bind evidence to the signed data object by version-pinned reference plus digest, so that replay can proceed on digests alone when content is detached or unavailable. The content model owns that object's versioning, storage and lifecycle.", "required": true, "source_refs": [ "SRC-016", "SRC-068" ] }, { "target": "Retention, disposition and legal-hold model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Deletion, hold and disposition over proof bytes and validation records are decided and executed under the target model. This model contributes only the immutability constraint, the minimum-evidence retention floor and the tombstone shape, and never asserts that a disposition was lawfully executed.", "required": true, "source_refs": [ "SRC-066", "SRC-070" ] }, { "target": "ETSI EN 319 102-1 and ETSI TS 119 102-2 signature validation and validation-report model", "relation": "ALIGN", "purpose": "Align indications, sub-indications, validation objects, validation time and proof-of-existence semantics so that verdict records interchange cleanly. This is an alignment for interoperability, not a conformance claim; no clause-level conformance is asserted here.", "required": false, "source_refs": [ "SRC-061", "SRC-062", "SRC-013" ] }, { "target": "IETF evidence record syntax family (RFC 4998 and RFC 6283)", "relation": "ALIGN", "purpose": "Align renewal kinds, chain and sequence continuity and redundant-chain semantics with archive time-stamp structures, while keeping the model independent of any single container so that embedded and detached evidence are treated alike.", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "target": "WM-XCT-006 (registered parent cross-cutting model)", "relation": "CHILD", "purpose": "This entry is registered under WM-XCT-006 and is carried as a mixin attached to a host record, following the embedded-proof pattern in which a proof object is attached to the material it covers. The parent's generic cross-cutting semantics are inherited by reference and are not restated here.", "required": true, "source_refs": [ "SRC-004", "SRC-073" ] }, { "target": "Host record model that carries this mixin (document, dataset, message, claim or asset)", "relation": "MIX-IN", "purpose": "Attach proof identity, method, evidence and governance to a host subject. Host content, versioning and lifecycle remain entirely with the host model.", "required": true, "source_refs": [ "SRC-004", "SRC-073" ] }, { "target": "Cryptographic key and credential model (generation, custody, cryptoperiod, key states, destruction)", "relation": "REFERENCE", "purpose": "Carry key and credential references, cryptoperiod claims and compromise declarations by reference. Key generation, custody, activation, rotation, destruction and cryptographic execution remain in the target.", "required": true, "source_refs": [ "SRC-055", "SRC-001", "SRC-077" ] }, { "target": "PKI, trust service and trusted-list model (CA, TSA, revocation services, trusted lists)", "relation": "REFERENCE", "purpose": "Pin trust-anchor sets, certificate references, revocation and status evidence and time-stamp tokens by reference and version. Certificate issuance, revocation publication, time-stamp issuance and trusted-list maintenance remain in the target.", "required": true, "source_refs": [ "SRC-043", "SRC-073", "SRC-013" ] }, { "target": "Identity and actor model (signer identity, identity proofing, role holders)", "relation": "REFERENCE", "purpose": "Bind signer and role-holder references without copying identity attributes. Identity proofing, credential binding and assurance-level assignment remain in the target.", "required": true, "source_refs": [ "SRC-061", "SRC-074", "SRC-076" ] }, { "target": "Records retention, legal hold and disposition model", "relation": "REFERENCE", "purpose": "Bind retention schedule, legal hold and preservation obligations by reference and receive reported disposition. Schedule authorship, hold issuance and disposition execution remain in the target.", "required": true, "source_refs": [ "SRC-074", "SRC-075", "SRC-078" ] }, { "target": "Access control and authorization policy model", "relation": "REFERENCE", "purpose": "Bind disclosure classes to externally authored access policies. Policy evaluation, grant decisions and enforcement remain in the target.", "required": true, "source_refs": [ "SRC-004", "SRC-013" ] }, { "target": "Audit and event log model", "relation": "REFERENCE", "purpose": "Store audit entry references for reconciliation only. Audit capture, storage, query, tamper-evidence and audit retention remain in the target.", "required": false, "source_refs": [ "SRC-077", "SRC-078" ] }, { "target": "ETSI EN 319 102-1 AdES signature validation status vocabulary and validation process", "relation": "ALIGN", "purpose": "Record reported validation indications and sub-indications using the external vocabulary as a pinned alignment. The validation process itself is not implemented here and no conformance is claimed.", "required": false, "source_refs": [ "SRC-061", "SRC-013" ] }, { "target": "ETSI TS 119 172-1 signature policy structure and applicability rules", "relation": "ALIGN", "purpose": "Pin signature policy, applicability-rule and policy-issuer references. Policy authoring and signing remain with the signature-policy authority.", "required": false, "source_refs": [ "SRC-071" ] }, { "target": "W3C Verifiable Credential Data Integrity 1.0 proof properties", "relation": "ALIGN", "purpose": "Map proof identity, previousProof chaining, created and expires, and verificationMethod onto local elements without adopting its serialization or its JSON-LD processing model.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "C2PA Technical Specification claim-signature, update-manifest and validation status model", "relation": "ALIGN", "purpose": "Map append-only correction via update manifests and validation status codes onto local supersession and reported-outcome elements. C2PA trust-list operation and manifest generation remain external.", "required": false, "source_refs": [ "SRC-073" ] }, { "target": "RFC 5280 certificate revocation reason codes and invalidityDate semantics", "relation": "ALIGN", "purpose": "Reuse revocation reason codes and the asserted invalidity time as a recorded vocabulary for compromise response. Certificate and CRL semantics are not extended to proofs themselves.", "required": false, "source_refs": [ "SRC-043" ] }, { "target": "Regulation (EU) No 910/2014 qualified signature, seal, validation, preservation and trust-service regime", "relation": "ALIGN", "purpose": "Carry jurisdictional regime references with jurisdiction code and effective interval. Legal-effect determination and qualified-status conferral are external and never universal model facts.", "required": false, "source_refs": [ "SRC-076", "SRC-013" ] }, { "target": "ETSI TS 119 511 long-term preservation service policy and preservation evidence", "relation": "ALIGN", "purpose": "Reference preservation profiles and preservation evidence policies that define the evidence set required for long-term verifiability. Preservation service operation and evidence generation remain external.", "required": false, "source_refs": [ "SRC-072" ] }, { "target": "Cryptographic algorithm transition regime (NIST SP 800-131A and successor guidance)", "relation": "ALIGN", "purpose": "Adopt transition status vocabulary for method identifiers by reference, with the source regime and its status recorded. Transition dates are pinned, not asserted locally.", "required": false, "source_refs": [ "SRC-057", "SRC-001" ] }, { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "WM-XCT-034 is the signature and proof specialization within its registry-declared parent. It contributes only proof-object description, signer and binding context and referenced verification evidence, and inherits the parent's framing of a proof as a component attached to secured material rather than a free-standing object.", "required": true, "source_refs": [ "SRC-004", "SRC-008", "SRC-081" ] }, { "target": "Host record model carrying the secured material (document, credential, message, media asset, package or ledger entry)", "relation": "MIX-IN", "purpose": "Attaches proof context to a host record without assuming its identity, payload semantics or lifecycle; the binding is made only through subject resource descriptors and digests, and the host remains the system of record for its own content.", "required": true, "source_refs": [ "SRC-081", "SRC-073", "SRC-004" ] }, { "target": "Cryptographic key management and custody model", "relation": "REFERENCE", "purpose": "Carries a verification-method or key-identifier reference and the binding parameters needed to locate a key, while key generation, protection, cryptoperiods, custody and compromise handling remain wholly in the referenced model.", "required": true, "source_refs": [ "SRC-055", "SRC-007", "SRC-050" ] }, { "target": "Trusted time-stamp authority and time-evidence model", "relation": "REFERENCE", "purpose": "Carries pointers to time-stamp tokens with their issuing authority, policy identifier, granularity and accuracy claim; issuance, signing and any authoritative time determination stay with the authority.", "required": false, "source_refs": [ "SRC-009", "SRC-083", "SRC-073" ] }, { "target": "Certificate, trust-list and revocation-status model", "relation": "REFERENCE", "purpose": "Records which credential chain, trust-list entry and revocation-status evidence were referenced and where they are retained; issuance, trust-list membership and revocation decisions remain with the issuing and configuring authorities.", "required": false, "source_refs": [ "SRC-073", "SRC-080" ] }, { "target": "Transparency log and inclusion-proof model", "relation": "REFERENCE", "purpose": "References log entries, signed timestamps and inclusion or consistency proofs as evidence; log operation, monitoring and the client policy that decides how much evidence suffices remain outside this model.", "required": false, "source_refs": [ "SRC-069" ] }, { "target": "Signature verification and validation-policy engine", "relation": "REFERENCE", "purpose": "Points to the engine, its validation policy and the recorded status indication, sub-indication and augmentation level as referenced outcomes; execution of verification, the acceptance decision and any enforcement remain entirely in the referenced system.", "required": true, "source_refs": [ "SRC-080", "SRC-004", "SRC-007" ] }, { "target": "Approved signature algorithm and cryptosuite registries", "relation": "ALIGN", "purpose": "Aligns carried algorithm and cryptosuite identifiers with governed registries so that deprecation and errata propagate from the registry rather than being decided locally.", "required": true, "source_refs": [ "SRC-001", "SRC-004", "SRC-008" ] }, { "target": "Data Integrity proof vocabulary", "relation": "ALIGN", "purpose": "Aligns proof-object terms, proof-purpose values and proof-set versus proof-chain composition with the published vocabulary, recording alignment without claiming conformance.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "Detached signing envelope and attestation statement models", "relation": "ALIGN", "purpose": "Aligns envelope, statement and subject-descriptor structure so that payload type, signature entries and digest-bound subjects are carried with their original semantics and byte fidelity.", "required": false, "source_refs": [ "SRC-082", "SRC-081" ] }, { "target": "Adopting-Dimension access control and audit model", "relation": "REFERENCE", "purpose": "Supplies scope and material-category classifications for use by that model, and receives exception references from it; issuance, evaluation, enforcement and audit-record storage stay in the referenced model.", "required": true, "source_refs": [ "SRC-080", "SRC-073" ] }, { "target": "Adopting-Dimension retention and disposition policy", "relation": "REFERENCE", "purpose": "Names the policy that assigns retention classes to this model's own records and executes disposition; this model emits disposition instructions and tombstones and never performs physical deletion.", "required": true, "source_refs": [ "SRC-055", "SRC-080" ] }, { "target": "Regulatory qualification and legal-effect model", "relation": "REFERENCE", "purpose": "Carries a pointer to any qualification determination and the policy under which it was made; the determination of legal effect and evidentiary weight is made and owned elsewhere.", "required": false, "source_refs": [ "SRC-080", "SRC-073" ] }, { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "WM-XCT-034 is a contained specialisation within its parent's cross-cutting attachment container, matching the embedded-proof pattern in which a proof graph is held by the secured document rather than standing alone. The parent owns container semantics; this model owns only the proof attachment itself.", "required": true, "source_refs": [ "SRC-084", "SRC-005" ] }, { "target": "Host record model adopting this mixin", "relation": "MIX-IN", "purpose": "Applied to any host record type needing integrity or authenticity attachment, exactly as a securing mechanism is applied to an arbitrary conforming document, an HTTP message or a CBOR payload. The host retains its identity, content and lifecycle; the mixin adds only proof context and the pinned bindings it commits to.", "required": true, "source_refs": [ "SRC-084", "SRC-022", "SRC-008", "SRC-005" ] }, { "target": "External signing and proving executor (remote signing service, cryptographic module or holder-side prover)", "relation": "REFERENCE", "purpose": "Carries the executor endpoint reference, the pinned request parameters and the correlation binding only. Key custody, signer authorization, sole-control enforcement, primitive execution and proof derivation are owned entirely by the target; this model reproduces none of the executor's lifecycle or operational functions and must never send it an unpinned mutable reference or a key value.", "required": true, "source_refs": [ "SRC-001", "SRC-086", "SRC-087", "SRC-089" ] }, { "target": "Verification method and key material resolution model", "relation": "REFERENCE", "purpose": "Carries the pinned verification-method URL, key identifier or credential identifier and the scheme governing it. Dereferencing, key lifecycle, controller relationships, trust-anchor selection and revocation evaluation stay with the target.", "required": true, "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-087" ] }, { "target": "Verification and validation model", "relation": "REFERENCE", "purpose": "Supplies the pinned inputs a verifier needs and stores the verification observations a verifier returns, as historical evidence. Evaluation of authenticity, application of relying-party policy and the reliance decision are executed and owned by the target; this model never infers validity from proof presence or from a prior observation.", "required": true, "source_refs": [ "SRC-084", "SRC-005" ] }, { "target": "Time-stamping authority and trusted time model", "relation": "REFERENCE", "purpose": "Pins a timestamp-token reference and the message imprint it corresponds to, where the adopting Dimension requires trusted time. Token issuance, authority policy and authority trust evaluation are owned by the target.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Adopting-Dimension retention, records-management and audit models", "relation": "REFERENCE", "purpose": "Receives the minimum fields this model emits about its own preparation, dispatch, admission and attachment operations, and owns disposition execution, legal hold, archival preservation and all audit-record format, storage, sealing and retention. This model states only what must survive disposition and never performs or authorises deletion or audit-trail construction.", "required": true, "source_refs": [ "SRC-084", "SRC-005" ] }, { "target": "W3C Data Integrity DataIntegrityProof, IETF JOSE (RFC 7515), IETF COSE (RFC 9052) and HTTP Message Signatures (RFC 9421)", "relation": "ALIGN", "purpose": "Field-level alignment of the local proof descriptor, protected input and context bindings to external securing mechanisms so a projection into any of them is lossless in the fields those mechanisms define. Alignment only: no conformance is claimed, and the identifier and time-representation conflicts between these mechanisms are recorded rather than normalised away.", "required": false, "source_refs": [ "SRC-084", "SRC-022", "SRC-007", "SRC-008" ] }, { "target": "NIST FIPS 186-5 approved algorithm set and the adopting Dimension's algorithm allow-list", "relation": "ALIGN", "purpose": "Constrains which algorithm and parameter values may be pinned at preparation. The approved-suite definition and any national or sectoral restriction are owned externally; this model refuses values absent from the Dimension's registered allow-list but does not define, assess or certify algorithms.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "Selective-disclosure derived-proof model", "relation": "EXTEND", "purpose": "Specialises only this model's own request surface for derived proofs: the base-proof reference, mandatory and selective pointers, presentation header and feature option become pinned request parameters, and the returned derived proof passes the same admission gate. Generic proof identity, authority, lifecycle and conflict handling are not duplicated, and derivation itself remains an executor operation.", "required": false, "source_refs": [ "SRC-089" ] }, { "target": "WM-XCT-006 (parent proof and attestation host model)", "relation": "CHILD", "purpose": "Mount this mixin into the parent's proof surface so that the parent's records gain multi-party composition and append-only proof lifecycle context. The parent retains the host record's own identity, classification and lifecycle; this entry contributes only proof-scoped structure.", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "Host record and payload version model (adopting-Dimension registry entry)", "relation": "REFERENCE", "purpose": "Resolve the pinned payload version and its canonical byte form that every proof binds to. The host model owns payload versioning, serialization and physical deletion; this entry carries only the version reference, canonicalization method and digest.", "required": true, "source_refs": [ "SRC-019", "SRC-005" ] }, { "target": "Key and certificate lifecycle model (adopting-Dimension registry entry)", "relation": "REFERENCE", "purpose": "Resolve the verification-method or key reference declared by each signer, and carry references to key or certificate revocation events as supporting evidence. Key generation, rotation, revocation and trust-anchor management stay entirely with that model.", "required": true, "source_refs": [ "SRC-091", "SRC-052" ] }, { "target": "Cryptographic verification and validation service model", "relation": "REFERENCE", "purpose": "Carry the validation status indication and sub-indication returned for each proof, together with the validator reference, validation policy reference and observation time. The validation procedure, its constraints and its verdicts are owned there and are relayed here verbatim.", "required": true, "source_refs": [ "SRC-061" ] }, { "target": "Authorization and policy decision model", "relation": "REFERENCE", "purpose": "Carry the reference to the external decision result that may explicitly state threshold satisfaction, approval or signature-policy compliance. Policy evaluation and enforcement remain outside; absence of a result is reported here as indeterminate.", "required": true, "source_refs": [ "SRC-061", "SRC-092" ] }, { "target": "Transparency log and audit record model", "relation": "REFERENCE", "purpose": "Carry registration receipt references and audit-entry references as evidence that an append occurred. Append-only log operation, inclusion proofs, receipt issuance and audit-trail retention are owned there and are never reproduced here.", "required": false, "source_refs": [ "SRC-092" ] }, { "target": "Trusted time-stamp model", "relation": "REFERENCE", "purpose": "Carry references to time-stamp tokens used as proof of existence for proof bytes and for declarations. Token issuance and authority operation remain outside; this entry records only the token reference and what it covers.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Credential status and revocation list model", "relation": "REFERENCE", "purpose": "Carry a reference to any externally published status entry that concerns the same subject, so that consumers can distinguish a proof invalidation assertion from a credential revocation or suspension. Status publication and reversal remain outside.", "required": false, "source_refs": [ "SRC-052", "SRC-005" ] }, { "target": "W3C Verifiable Credential Data Integrity 1.0 proof sets and proof chains", "relation": "ALIGN", "purpose": "Map the independent co-signature set to a proof set and the dependency-ordered chain to a proof chain expressed through previous-proof pointers, recording that the alignment binds by identifier rather than by covered bytes.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "IETF countersignature constructs in COSE and CMS", "relation": "ALIGN", "purpose": "Map the dependency binding to constructs that cover the prior signature bytes, and map parallel signing to multiple independent signer entries over one content, preserving the distinction between the two topologies during projection.", "required": false, "source_refs": [ "SRC-015", "SRC-006" ] }, { "target": "W3C PROV-O invalidation and revision vocabulary", "relation": "ALIGN", "purpose": "Map the scoped invalidation assertion to invalidation-with-time semantics understood as cessation of usability rather than destruction, and map the supersession link to revision-style derivation. Alignment is recorded as a mapping, not as a conformance claim.", "required": false, "source_refs": [ "SRC-090" ] }, { "target": "WM-XCT-006", "relation": "CHILD", "purpose": "WM-XCT-034 is registered under WM-XCT-006 and specialises only the signature or proof subject. The generic integrity and evidence abstraction, and any vocabulary shared across proof kinds, stay in the parent; this entry does not restate them.", "required": true, "source_refs": [ "SRC-061", "SRC-066" ] }, { "target": "Certificate, trust anchor and revocation status model", "relation": "REFERENCE", "purpose": "Carry references to certificates, trust anchor sets and status responses together with the run-specific parameters that pinned them (snapshot selector, freshness limit). Path construction policy, trust anchor governance, revocation decisions and certificate lifecycle remain owned by the target.", "required": true, "source_refs": [ "SRC-043", "SRC-044" ] }, { "target": "Time-stamping and preservation trust service model", "relation": "REFERENCE", "purpose": "Carry references to time-stamping and preservation services, their policy or profile identifiers and the object identifiers they issue. Service operation, accuracy assertions, supervision status and preservation execution remain owned by the target.", "required": true, "source_refs": [ "SRC-009", "SRC-072", "SRC-098" ] }, { "target": "Signature and validation policy model", "relation": "REFERENCE", "purpose": "Carry the pinned policy identifier, version and the parameter values that applied to a run. Authoring, approving, publishing and enforcing validation or signature policies, and operating any runtime evaluator, remain owned by the target.", "required": true, "source_refs": [ "SRC-061", "SRC-013", "SRC-097" ] }, { "target": "Cryptographic algorithm and suite policy registry", "relation": "REFERENCE", "purpose": "Reference algorithm status and sunset dates used in run pinning and renewal assessment. Maintaining the registry, setting transition dates and distinguishing generation from verification policy remain owned by the target.", "required": true, "source_refs": [ "SRC-096", "SRC-097" ] }, { "target": "Records retention and disposition model", "relation": "REFERENCE", "purpose": "Reference retention rules, disposition freezes and holds as inputs to readiness reporting. Schedule authorship, disposition authority, hold administration and execution of disposal remain owned by the target.", "required": true, "source_refs": [ "SRC-078", "SRC-072" ] }, { "target": "Audit and event log model", "relation": "REFERENCE", "purpose": "Link run records, evidence registrations and export events to entries in an external audit trail. Construction, sealing, protection and retention of the audit trail remain owned by the target; this model records domain facts only.", "required": true, "source_refs": [ "SRC-095", "SRC-078" ] }, { "target": "Access authorisation and disclosure model", "relation": "REFERENCE", "purpose": "Obtain separately resolved payload-disclosure and identity-disclosure authorisations for export projections. Authorisation decision-making, policy evaluation and enforcement remain owned by the target.", "required": true, "source_refs": [ "SRC-004", "SRC-095" ] }, { "target": "Host document, credential or transaction model", "relation": "MIX-IN", "purpose": "Attach proof, verification and preservation context to any host entity through the payload binding reference, without redefining the host's identity, versions, states or business meaning.", "required": true, "source_refs": [ "SRC-007", "SRC-004" ] }, { "target": "Standardised signature validation report structure", "relation": "ALIGN", "purpose": "Alignment target for report projections of a run record. Field-level correspondence is declared per projection and conformance is claimed only where a documented test exists.", "required": false, "source_refs": [ "SRC-095", "SRC-013" ] }, { "target": "Evidence record syntaxes in ASN.1 and XML bindings", "relation": "ALIGN", "purpose": "Alignment target for preservation evidence units and chain or sequence semantics, including the distinction between time-stamp renewal and hash-tree renewal.", "required": false, "source_refs": [ "SRC-066", "SRC-067" ] }, { "target": "Data integrity proof model for linked-data credentials", "relation": "ALIGN", "purpose": "Alignment target for non-PKIX proof attributes and verification result vocabulary, including proof purpose, verification method, proof sets and proof chains, so the verdict dimensions remain expressible outside a certificate-based setting.", "required": false, "source_refs": [ "SRC-004" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name one accountable owner package and steward role for every WM-XCT-034 deployment, with an effective-from RFC 3339 timestamp and a documented succession path; an unowned deployment is treated as unresolved and read scopes are withheld.", "Publish a delegation table that binds every capability this model excludes — key custody, signing authorization, cryptographic execution, certificate and trust-list operation, trusted time, verification and enforcement, audit storage, legal qualification, retention enforcement and physical deletion — to a named external system with a resolvable reference, a review interval and a last-reviewed timestamp.", "Declare the algorithm and cryptosuite policy source, including which governed registry supplies approved identifiers, how deprecations and errata are absorbed, and the explicit acknowledgement that a syntactically valid signature may still be unacceptable under local algorithm policy.", "Declare the canonical form profile, the identity priority ladder in force, the projection inventory with known losses, and the exception-approval authority, so that no consumer must infer them from a container layout.", "Maintain the registry binding and the local namespace base, and record any term that later gains a governed IRI as deprecated in favour of that IRI rather than kept as a parallel local coinage." ], "namespace_guidance": "Vocabulary terms, proof-purpose values, status codes and identifiers are resolved in a fixed order: governed external IRIs from the aligned specifications and registries are used unchanged wherever one exists; only where none exists may a term be coined under the Dimension's declared namespace base, and such a term is marked Dimension-local, is never presented as a governed identifier, and is deprecated in favour of a governed IRI as soon as one is published. Namespaces are never derived from container paths, database names, collection names, interface routes or dates, because those are projection details that change without any change in meaning. Local extension terms must not shadow a governed term with different semantics, and any unrecognized term carried in a position marked critical causes fail-closed rejection rather than silent ignoring.", "registry_links": [ "Registry entry vr.wm-xct-034 on the world-model record plane, binding model WM-XCT-034 to its owner package and navigation path.", "Governed algorithm and cryptosuite identifier registries referenced for approved and deprecated signature algorithms.", "Proof vocabulary and verification-method term registries referenced for proof properties, proof purposes and verification relationships.", "Predicate-type and payload-type registries referenced for attestation statements and detached signing envelopes.", "Trust-list and validation-policy references maintained by the relevant public authority or validator configuration, referenced but never mirrored as authoritative." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form of a WM-XCT-034 context record is defined by one declared canonicalization profile identifier and version, recorded in the record itself; the profile, not the container, determines byte order and encoding.", "Canonicalization of the model's own record is strictly separate from the transformation that produced any signed bytes. Cryptosuite canonicalization, signature structures and pre-authentication encodings are referenced as opaque declared values and are never recomputed, substituted or normalized by this model.", "Deterministic serialization requirements are honoured for the chosen profile: for object-structured records, whitespace is removed, primitives are serialized under the profile's rules, members are ordered deterministically and the output is encoded as UTF-8; for graph-structured records, a standard dataset canonicalization algorithm with deterministic blank-node labelling is used.", "Canonicalization fails closed. Duplicate member names, numeric values outside the profile's representable precision, non-finite numeric values and invalid Unicode sequences terminate processing with an abort code; a repaired, coerced or best-effort output is never produced.", "Canonicalization is bounded. Inputs whose structure makes canonicalization disproportionately expensive are aborted early and treated as suspected denial-of-service inputs rather than processed to completion.", "Canonical form is necessary but not sufficient for reproducibility: every canonical output is accompanied by its digest algorithm identifier and digest value, and independent implementations are expected to reproduce both from the published test vectors.", "Opaque octets — proof and signature values, time-stamp tokens, status responses, inclusion proofs and credential chains — are excluded from canonical rewriting and stored verbatim; canonicalization applies to the describing record, never to the evidence it carries." ], "patch_rules": [ "Changes are expressed as ordered, atomic operation sequences using add, remove, replace, move, copy and test semantics, applied all or nothing so that a failed operation leaves the record byte-identical to its prior state.", "Every change set carries at least one precondition test asserting the expected prior value or the prior canonical digest, providing optimistic concurrency control between stewards; a failed precondition rejects the whole change set.", "No operation may target stored proof or signature octets, subject digests, integrity-protected parameters or pre-authentication inputs. Where such material must change, a new subject descriptor, a new attached proof or a superseding record version is created and linked, never an in-place edit.", "Ordered proof composition is preserved: predecessor references that establish a proof chain are never reordered, renumbered or collapsed by a change set, and adding a proof to an unordered set never implies an order.", "Later-arriving evidence — a time-stamp token, a status response, an inclusion proof, a raised augmentation level — is recorded as an addition with its own ingestion time, never as an update that overwrites an earlier recorded observation.", "Change sets are serially numbered per record, carry the prior and resulting canonical digests, the requesting role and an RFC 3339 application time with explicit offset, and are retained under the record's retention class." ], "compatibility_rules": [ "Adding an optional element, a new evidence reference or a new projection target is an additive change and does not break consumers.", "Changing the canonicalization profile, the identity priority ladder, the binding style between proof and subject, or the meaning of an existing element is a breaking change and requires a new specification version and consumer notification with an effective-from timestamp.", "Retired algorithm identifiers, cryptosuite names and vocabulary terms are marked deprecated with a superseding identifier and retained for interpretation of historical records; they are never deleted, because deleting them would make old records uninterpretable.", "Unknown elements marked critical cause fail-closed rejection; unknown elements not so marked may be preserved unchanged and passed through, but are never relied upon for any decision.", "Records carry the specification version under which they were authored, so a consumer can interpret them under the rules then in force rather than under current rules.", "Algorithm deprecation follows the governed registry rather than local judgement, and an errata or planning notice against a referenced standard is recorded as a compatibility signal on affected records." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record that owns the artifact — for example the identifier a signing or manifest-producing system assigns to a signature or manifest, or an authority-scoped serial number qualified by its issuing authority. This rung is used whenever it exists.", "Governed global identifier or IRI from a published registry or specification when no master-system identifier exists — for example a verification-method IRI, a cryptosuite identifier, a statement or predicate type URI, a payload type identifier or a trust-list entry reference.", "UUID or ULID minted by the adopting Dimension, used only when neither a master-system identifier nor a governed IRI exists; the minted value is marked Dimension-local, is recorded together with the reason the higher rungs were unavailable, and is never re-exported as authoritative.", "Dates, timestamps, version labels, sequence numbers, container paths and file names are never identifiers, in any rung or as a fallback.", "A content digest is a content address and an integrity binding to an immutable subject, not an identity; a key identifier or thumbprint is a hint for key selection, not an identity of a signer or a grant of authority." ], "timestamp_rule": "All times recorded by this model use RFC 3339 date-time with explicit seconds and an explicit numeric UTC offset or Z; date-only, local-time-only and implied-zone values are rejected rather than normalized. Event time — the signer-claimed signing time and any asserted proof creation or expiry — is recorded separately from observation or ingestion time, which is when the adopting Dimension captured the material or last re-checked it, and both remain distinct from trusted evidence time asserted by an external time-stamp authority under its own policy. A signer-claimed time carries no assurance on its own and is never merged into, replaced by or reconciled against authority-asserted time by this model. Where a source publishes an accuracy, granularity or ordering claim with a time value, that claim is preserved alongside the value rather than folded into it, and no derived authoritative time is computed locally.", "serial_naming_rule": "Serial artifacts — change set records, projection loss reports and evidence-capture snapshots — are named as artifact kind, then a zero-padded monotonic sequence number, then the parent record identity. The sequence is monotonic per parent record and per artifact kind, is never reused, never back-filled and never derived from a clock or a date, and gaps are preserved rather than closed. Creation and application times are fields inside the artifact, expressed under the timestamp rule; they never appear in the name. Renaming a serial artifact does not change its identity, because the name is a projection convenience and the identity comes from the identity priority ladder.", "integrity_rule": "Every stored or referenced artifact records the digest algorithm identifier and the digest value computed over the exact octet sequence held, together with either the canonicalization profile that produced those octets or an explicit marking that the octets are opaque and externally produced. Proof and signature values, time-stamp tokens, status responses, inclusion proofs and credential chains are stored verbatim and are never re-encoded, re-indented, re-ordered or re-serialized on read or on projection. The octets delivered to any consumer are the same octets whose digest was recorded, so that no consumer ever re-parses a different representation than the one that was checked. A digest mismatch, a missing digest algorithm identifier or an unmarked re-encoding fails the read closed with an integrity code rather than returning a repaired or reconstructed value." }, "policies": [ "Describe, never execute: this model records what a proof asserts and what evidence exists about it, and performs no key operation, no signing, no verification, no revocation check and no enforcement of an outcome.", "Reference over replication: evidence produced by an external authority is referenced with enough binding parameters to locate and check it, and is mirrored only as verbatim opaque octets under the integrity rule, never re-issued, re-signed or summarized into a local substitute.", "Fail closed: unresolved bootstrap references, unrecognized critical parameters, canonicalization aborts, digest mismatches and missing scope classifications withhold the affected scope rather than degrade to partial or default behaviour.", "Separate the trusted from the merely carried: integrity-protected parameters may inform interpretation, unprotected parameters may not inform any decision, and a syntactically valid signature is still subject to a separate acceptance decision made elsewhere.", "Preserve the three times: signer-claimed time, trusted evidence time and Dimension observation time are recorded distinctly and never reconciled into a single field by this model.", "Minimize identity exposure: identity attributes about a claimed signer and correlatable values such as stable key identifiers and unblinded nonces are minimized per disclosure scope, and residual linkability is stated rather than implied to be absent.", "No projection is canonical: every container, database, interface and embedded binding is a lossy view that must publish its losses and point back to the canonical form and its digest.", "Alignment is not conformance: alignment with an external specification is recorded as an alignment claim with its version, and conformance is asserted only where independent evidence of testing exists." ], "crud": { "read": [ "Reads are scope-resolved before any content is returned: the requester's role is mapped to bundle, layer, finding and artifact scopes and to the material categories of payload, proof octets, public credential material, identity attributes, status evidence and diagnostics.", "Every read returns the canonical digest of the material served, so the consumer can confirm that what it received is what was recorded; opaque octets are served byte-identically and are never re-encoded for the response format.", "A read that traverses to referenced external evidence returns the reference and its binding parameters, not a locally reconstructed copy, and states which system of record holds the target.", "Reads that cannot resolve a required bootstrap reference, or that encounter a digest mismatch, return a fail-closed code and withhold the affected scope rather than returning partial content.", "Reads of minimized scopes apply the declared redaction rule to identity attributes and correlatable values before returning, and state that minimization was applied." ], "create": [ "A record is creatable only once its owner package, canonical form profile, identity assignment and scope classification are present; a record missing any of these is not created in a partial state.", "Identity is assigned by walking the identity priority ladder and recording the rung used, together with the reason any higher rung was unavailable; minting a Dimension-local identifier is the last resort and is marked as such.", "Creation captures the ingestion time under the timestamp rule and keeps it distinct from any time asserted inside the material being described.", "Referenced evidence is created as a descriptor plus verbatim octets or a resolvable pointer; the model never creates a substitute for an authority-issued artifact.", "Creation of a projection is always accompanied by a projection loss report and a pointer back to the canonical form." ], "update": [ "All updates are expressed as atomic change sets with preconditions, applied all or nothing, and recorded serially with prior and resulting canonical digests.", "Updates may not mutate proof octets, subject digests, integrity-protected parameters or pre-authentication inputs; such changes require a superseding record or a new attached proof.", "Later-arriving evidence and re-checked status are appended as new observations with their own ingestion times; earlier observations are never overwritten, because the history of what was observed when is itself the evidence.", "Every update is classified against the compatibility ladder, and a breaking classification triggers consumer notification with an effective-from timestamp.", "Updates to delegation targets, namespace bases or canonicalization profiles are owner-package decisions and are recorded with the deciding role and decision time." ], "delete": [ "This model's own context records, change sets, projection loss reports and descriptors are assigned a retention class by the adopting Dimension's retention and disposition policy, which is named by resolvable reference in the owner package; that policy — not this model — owns retention periods, holds and the execution of disposition.", "Disposition of a record produces a tombstone retaining only its identity, its retention class, the disposition instruction reference and the disposition time under the timestamp rule, so that inbound references resolve to an explicit disposed state instead of dangling; the tombstone contains no payload, no identity attributes and no proof octets.", "Physical deletion is executed by the storage or container system that holds the bytes, and confirmation of deletion is recorded as a reference to that system's response; this model issues an instruction and never performs or attests deletion itself.", "Externally owned evidence — time-stamp tokens, revocation responses, transparency-log entries, certificates and host payloads — is never deleted by this model under any circumstances; only the local descriptor and any locally cached verbatim copy fall within the disposition instruction, and the external artifact's lifecycle stays with its owning authority.", "Where deletion would break the interpretability of a retained proof, the conflict is recorded and referred to the retention policy owner for decision rather than resolved locally, and no record is silently retained past its class on this model's own authority.", "Deprecated algorithm identifiers, vocabulary terms and superseded specification versions are retained as deprecated rather than deleted, because removing them would render historical records uninterpretable." ] }, "roles": [ { "name": "Model steward (owner package holder)", "responsibilities": [ "Maintains the owner package descriptor, the delegation table and the namespace and registry bindings, and keeps their review timestamps current.", "Approves canonicalization profile, identity priority and binding changes, which are classified as breaking, and issues consumer notifications.", "Withholds scopes when the deployment is unowned or its bootstrap references cannot be resolved." ] }, { "name": "Signature context curator", "responsibilities": [ "Captures and maintains proof descriptions, signer and binding context and subject descriptors without altering signed material.", "Submits atomic change sets with preconditions and records supersession where in-place editing would touch bound material.", "Keeps signer-claimed, trusted evidence and observation times distinct at capture." ] }, { "name": "Evidence registrar", "responsibilities": [ "Records references to externally issued evidence with their issuing authority, policy reference, granularity and accuracy claims, and stores any verbatim octets under the integrity rule.", "Appends re-check observations with their own ingestion times instead of overwriting earlier ones.", "Refuses to re-issue, re-sign or summarize an authority's artifact into a local substitute." ] }, { "name": "Cryptographic authority liaison", "responsibilities": [ "Maintains resolvable references to key management, certificate, trust-list and time-stamp authorities and tracks algorithm deprecations from the governed registries.", "Holds no key material, no signing capability and no ability to trigger cryptographic operations.", "Escalates algorithm-policy consequences to the model steward as compatibility signals on affected records." ] }, { "name": "Access custodian", "responsibilities": [ "Maintains the scope and material-category classification table and the protection markings on carried parameters.", "Prepares exception requests with explicit scope, purpose and expiry and routes them to the external issuing and enforcing system.", "Reviews minimization rules for identity attributes and correlatable values and states residual linkability." ] }, { "name": "Agent integrator", "responsibilities": [ "Maintains the AGENTS.md bootstrap descriptor and its resolution order, and verifies that every declared reference resolves under integrity protection.", "Maintains the projection inventory and ensures every projection emits a loss report with a round-trip digest comparison.", "Verifies that no projection, container, database or interface is presented as canonical." ] } ], "access": { "default_rule": "Deny by default at every scope. A requester receives only the bundle, layer, finding or artifact scopes explicitly classified as readable for its role, and only within the material categories granted to that role. Payload, proof octets, public credential material, identity attributes, status evidence and diagnostics are classified and granted separately, so that access to one never implies access to another: public credential material and algorithm identifiers may be broadly readable while the secured payload remains closed, identity attributes are minimized, status evidence and diagnostics are restricted because they expose verification behaviour and organizational structure, and unprotected parameters are readable but marked as unusable for any decision. Write access is narrower than read access and is limited to submitting precondition-bearing change sets. Any scope whose classification is missing, whose bootstrap reference is unresolved or whose integrity check fails is withheld rather than defaulted open.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Time-boxed incident exception widening status evidence and diagnostic scopes during investigation of a suspected proof or key compromise, carrying an explicit expiry timestamp with offset and a maximum permitted duration.", "Named-recipient disclosure exception releasing identity attributes about a claimed signer to a specific counterparty for a stated purpose, with minimization still applied to correlatable values.", "Payload access exception granting read of the secured content itself, requiring approval from the host record's owner as well as the model steward, since payload semantics belong to the host model.", "Verbatim evidence export exception permitting release of stored opaque octets to an external verifier, conditioned on byte-identical delivery and on the recipient acknowledging that acceptance remains its own decision.", "Break-glass steward exception for restoring a deployment whose bootstrap references cannot be resolved, limited to the owner package descriptor and bootstrap scopes and expiring on restoration.", "Every exception is explicit about scope and material category, carries an expiry that cannot be extended by renewal without a fresh approval, names its approving authority, and is revocable before expiry." ], "audit_requirements": [ "Every access decision, exception issuance, exception use and exception expiry is recorded by the adopting Dimension's access and audit system, which owns the audit trail; this model holds only a reference to the exception and its expiry and asserts no audit-trail semantics of its own.", "Change sets carry the requesting role and application time and are serially numbered per record, so the sequence of proposed modifications is reconstructable from this model's own records without duplicating the external audit trail.", "Fail-closed events — unresolved bootstrap references, canonicalization aborts, digest mismatches, unrecognized critical parameters and missing scope classifications — are surfaced to the owner package with their observation timestamps.", "Reads of minimized scopes record that minimization was applied and under which rule, so that a later disclosure dispute can distinguish redaction from absence.", "Retention of all such records is governed by the externally named retention policy, and neither their immutability nor their storage guarantees are claimed by this model." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registry ID", "Owner" ], "read_order": [ "Read AGENTS.md first and confirm that all eight required fields are present and non-empty; if any field is missing or empty, halt and withhold every scope.", "Resolve Registry ID and Owner to confirm that the deployment is catalogued and has an accountable owner package; an unowned or uncatalogued deployment halts the agent.", "Resolve the Specification URL to obtain the model semantics, the canonical form profile, the identity priority ladder and the timestamp rule in force; do not infer any of these from the container layout.", "Resolve the Storage type URL to learn which container holds the projection being read and which fidelity losses that container introduces, then obtain the projection loss report for the material to be read.", "Resolve the Interface URL to learn the access surface, its scope classifications and its protection markings, and confirm that the interface is treated as a projection rather than as the canonical source.", "Resolve the Processes URL to obtain the change-set, evidence-capture, exception and disposition procedures before proposing any change.", "Verify that each resolution was obtained under integrity protection and that returned material matches its recorded digest; on any unresolved reference, integrity failure or digest mismatch, halt with an unresolved-reference code, withhold all scopes, and never substitute a cached, inferred or default value.", "Only after all references resolve, request a scope classification for the intended operation and proceed within the granted scopes; treat unprotected parameters as non-authoritative throughout." ] } }, "coverage": { "claim": "This synthesis reflects the sole active provider, Claude, across 25 bundles, 54 layers, 112 findings, 504 questions, 72 artifacts and 90 functions grounded in 98 largely tier-1 sources, spanning proof identity/kind/state, method and value, payload binding, canonicalization, portable projections, trust-chain and revocation status, algorithm policy and verdicts, durable evidence, governance, service-layer bootstrap, preparation/attachment, multi-party composition and verification/preservation operations; it explicitly does not claim universal completeness given roughly ninety declared known-omissions, several unretrieved ETSI/ISO/EUR-Lex sources, an unverified parent-model linkage, and the total absence of independent second-provider review.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Proof identity, assigning system, identifier scheme and revision-versus-new-proof distinction are modelled; identity priority puts the authoritative master-system identifier first and explicitly bars timestamps, digests and file names from designating a record." }, { "dimension": "relationships", "status": "covered", "notes": "Host binding, verification-method reference, signer role references, previous and member proof references, and validation policy and report references are all modelled as references with named owning models." }, { "dimension": "classification", "status": "covered", "notes": "An explicit proof kind code with origination capability keeps signatures, MACs, digests, seals, time-stamp tokens, selective-disclosure proofs and zero-knowledge attestations distinct; a standing policy forbids normalisation into digital signature." }, { "dimension": "content binding", "status": "covered", "notes": "Binding mode, covered representation descriptor and the protected versus unprotected parameter sets are modelled at declaration level. Canonicalization algorithms, XML transforms and byte-range scoping rules are delegated to the host model and to container profiles." }, { "dimension": "legal effect", "status": "not-applicable", "notes": "Determination of legal effect, admissibility and evidential weight is out of boundary by design; only a forum reference and a per-property non-assertion are carried." }, { "dimension": "selection expression language", "status": "gap", "notes": "No single normative language spans byte ranges, container boxes, XML node sets and RDF subgraphs. The model records a selection language identifier but cannot guarantee cross-family reconstruction of a selection; adopters must pin a language per payload family." }, { "dimension": "legal signature-form equivalence", "status": "gap", "notes": "Whether a given binding satisfies a jurisdiction's advanced or qualified electronic signature requirements, including what-you-see-is-what-you-sign obligations, is not modelled and is not derivable from the cited sources." }, { "dimension": "canonicalization determinism", "status": "covered", "notes": "Ordered steps, three-valued presence, versioned identifiers, bound versus defaulted parameters, media types and implementation pins together make the protected bytes reproducible or demonstrably not." }, { "dimension": "domain separation and context binding", "status": "covered", "notes": "Domain separation tags with uniqueness and version construction, structure context labels, proof purpose, domain, challenge, explicit typing and external additional authenticated data are all declared inside the protected region, with empty distinguished from absent." }, { "dimension": "character encoding and Unicode", "status": "covered", "notes": "Input encoding, output octet encoding, normalization form including the explicit value none, Unicode version of record and unassigned-code-point handling are declared, with compatibility normalization flagged as irreversible." }, { "dimension": "threat and abuse coverage", "status": "covered", "notes": "Replay, substitution, wrapping and relocation, parser differentials, confused deputy and cross-protocol reuse are each declared with a mitigating mechanism and a residual risk note, plus complexity limits against poison inputs. Enforcement of every one of these is external by construction." }, { "dimension": "interoperability", "status": "covered", "notes": "Six projection templates with no canonical default, an enumerated loss ledger, identifier-space mapping across OIDs, URIs, string tokens and integer labels, media-type ambiguity handling, and conversion verdicts with cited blocking conditions." }, { "dimension": "constraint and criticality", "status": "covered", "notes": "Critical-parameter declaration and unsupported-parameter behaviour, post-signing mutability classes, serialization capacity limits and prohibited forms per projection are all modelled with citations." }, { "dimension": "revocation status semantics", "status": "covered", "notes": "CRL, delta CRL, online status protocol, credential status list and declared-unavailable regimes are all covered, with reason codes, reversibility, scope descriptors, responder authorization, nonce behaviour, stapling and freshness, and without selecting a universal hard-fail, soft-fail or unknown-handling policy." }, { "dimension": "trust anchor and path constraints", "status": "covered", "notes": "Candidate and selected paths, retrieval provenance, loop control, initial policy and control-flag inputs, basic, name and policy constraint outcomes, unrecognized critical extensions, anchor-carried path controls, and trust-store snapshot pinning with observed service status." }, { "dimension": "evidence freshness and measurement", "status": "covered", "notes": "This-update and next-update bounds, staleness measured against the declared instant, cache age, clock-skew tolerance and time source are all recorded as measurable quantities rather than as a binary fresh or stale flag." }, { "dimension": "validation", "status": "covered", "notes": "A closed outcome vocabulary with mandatory reason codes, parameter-completeness status, accepted-set comparison and reproducibility status define validation of the record itself; cryptographic execution stays external." }, { "dimension": "algorithm policy and agility", "status": "covered", "notes": "Approval state per authority with operation scope, security strength with its reference table, sunset date with time basis, verifier-side accepted set, and hybrid, composite and post-quantum migration state." }, { "dimension": "security", "status": "covered", "notes": "Downgrade, algorithm confusion, key-to-algorithm binding, unauthenticated algorithm values, weak or truncated digests and unattested randomness are all recordable conditions; enforcement is explicitly excluded." }, { "dimension": "measurement", "status": "covered", "notes": "Security strength is expressed in bits with the strength table reference, its version, and a claimed-versus-assessed flag so an unverified vendor claim is distinguishable." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence completeness, digest-algorithm deprecation, dereferenceability loss and reproducibility limits are first-class recorded states rather than silent failures." }, { "dimension": "temporal", "status": "covered", "notes": "Generation time, accuracy, ordering flag, revocation and production instants, validation instant, report production time, renewal instants and observation times are separated. Ordering is refused where accuracy intervals overlap, and best-signature-time is derived rather than asserted." }, { "dimension": "provenance", "status": "covered", "notes": "Every element records its source, its acquisition instant and whether it is held by value or by reference with digest; authority and list state are pointers with version and digest, never local copies." }, { "dimension": "trusted time", "status": "covered", "notes": "Treated as a first-class bundle with its own imprint binding, token identity, authority reference and ordering discipline, keeping signer-claimed time permanently demoted to a claim." }, { "dimension": "cryptographic agility", "status": "covered", "notes": "Algorithm policy with sunset instants, additive digest history, both renewal kinds, redundant chains, and an explicit collision-migration question with a residual-risk statement." }, { "dimension": "replay reproducibility", "status": "covered", "notes": "A named replay contract distinguishes invariant from variable inputs, flags network-dependent steps, and requires divergence to be recorded as a new verdict rather than an edit." }, { "dimension": "failure and exception handling", "status": "covered", "notes": "Unavailable and retracted responders, expired certificates, revocation and compromise after proof, compromised authorities, orphaned content, clock uncertainty, missed renewals and log failure each have a question and an anomaly class." }, { "dimension": "lifecycle", "status": "covered", "notes": "Governance state vocabulary with permitted transitions, append-only supersession, expiry, invalidation by compromise, bounded exception and forward-only rollback. In-place substantive mutation is prohibited; the state is kept separate from the reported cryptographic outcome." }, { "dimension": "ownership", "status": "covered", "notes": "Nine distinct roles with a hard prohibition on one party holding signing authorization, key custody, verification-policy authority and legal-effect assessment together, plus recorded conflict declaration and compensating control where separation is impossible." }, { "dimension": "access", "status": "covered", "notes": "Deny by default across bundle, layer, finding and artifact scopes, with six independent disclosure classes and an explicit non-implication rule between proof-bytes access and host-content or signer-attribute access. Four bounded exception types each carry a ground and, where relevant, an expiry." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention schedule and legal-hold binding by reference, preservation obligation stated by profile reference, and a tombstone containing only identifier, supersession links, reason, reported time and authority. Deletion execution, backup expiry, audit retention and host deletion are assigned to external models; no schedule resolving means retain and flag." }, { "dimension": "authority and separation of duty", "status": "covered", "notes": "Each state transition, change, exception and review names the authorised role and the roles barred from acting, with delegation recorded by reference and the requesting role excluded from sole approval." }, { "dimension": "security and compromise response", "status": "covered", "notes": "Referenced external compromise declarations, asserted invalidity time distinguished from revocation publication time, frozen blast radius with recorded exclusions, required actions mapped to owning models, and time-stamp or preserved-evidence mitigation determinations." }, { "dimension": "privacy", "status": "covered", "notes": "Signer identity attributes are held only as references; proof timing values and status endpoints are classified in their own right because they can reveal information about a controller; diagnostics are sensitive by default with a redaction rule." }, { "dimension": "exceptions", "status": "covered", "notes": "Every exception carries a ground code, purpose limitation, compensating condition, approving authority, mandatory expiry and rollback condition, and never modifies the reported cryptographic outcome or the pinned policy." }, { "dimension": "spatial and jurisdiction", "status": "covered", "notes": "Jurisdiction is modelled as a code plus regime reference plus effective interval, with an explicit prohibition on deriving a local legal-validity flag from a pinned regime." }, { "dimension": "authority", "status": "covered", "notes": "Authority is declared and delegated but never exercised: no key operation, no issuance, no revocation decision, no enforcement, no legal determination. The liaison role explicitly holds no key material and no ability to trigger cryptographic operations." }, { "dimension": "canonicalization", "status": "covered", "notes": "Separates the record's own canonical form from the cryptosuite or envelope transformation that produced signed bytes, mandates fail-closed behaviour on unrepresentable input, bounds canonicalization work against poisoning, and requires digest plus test vectors because canonical form alone is necessary but not sufficient." }, { "dimension": "replay and idempotency", "status": "covered", "notes": "Every mutation carries an idempotency key with a defined replay outcome, and a replay never creates a second operation or extends a validity window. A replay scope key composed of nonce, host record, proof purpose and audience blocks cross-context reuse of a genuine proof." }, { "dimension": "concurrency", "status": "covered", "notes": "Every mutation carries an expected-version or expected-revision precondition; a mismatch fails with an explicit precondition failure rather than merging. Read projections return a consistency token usable as the precondition for a subsequent write." }, { "dimension": "idempotency and concurrency", "status": "covered", "notes": "Every mutation requires an idempotency key with a request fingerprint and an expected-version token; replay semantics, fingerprint mismatch, version mismatch and concurrent co-sign serialization are each specified, with no partial writes or silent merges." }, { "dimension": "immutability", "status": "covered", "notes": "Original proof bytes, covered digests, bindings, dependency edges and ordinals are immutable; only fields outside signature coverage may be appended, and each append still produces a new version record." }, { "dimension": "authorization and threshold", "status": "gap", "notes": "The model deliberately declines to evaluate thresholds and relays an external decision result instead. No single authoritative standard was found that specifies a portable schema for declaring required participants and thresholds, so the participation declaration finding is supported by analogy to registration policy, proof purpose and validation policy rather than by a directly normative source, and is marked as a gap-supported node." }, { "dimension": "evidence and preservation", "status": "covered", "notes": "Evidence units are additive and byte-preserving, with the two renewal kinds distinguished by the risk each addresses, coverage sets recorded per unit, and chain discontinuities surfaced rather than smoothed over." }, { "dimension": "post-quantum and hybrid proof composition", "status": "gap", "notes": "No primary source is cited here for recording hybrid or composite signatures, dual-algorithm proof chains or migration evidence across a post-quantum transition. The algorithm-horizon fields would carry the dates but the composition semantics of a hybrid proof are unmodelled and must not be presented as canonical." }, { "dimension": "non-cryptographic and hardware-attested proof forms", "status": "gap", "notes": "Handwritten, biometric, notarial and hardware-attestation proof forms are within the plain reading of the registry purpose but no cited source grounds their verification or preservation semantics; the verdict dimensions may not transfer to them unchanged." } ], "known_omissions": [ "Selective-disclosure and zero-knowledge proof systems, including derived-proof and unlinkability semantics, are accommodated only by the generic outcome and dimension slots; their predicate and derivation semantics are not modelled.", "Remote-attestation evidence appraisal, where an appraisal policy rather than a signature check drives the verdict, is out of scope and would require a sibling model.", "National and regional algorithm catalogues such as SOG-IS agreed mechanisms, BSI TR-02102, ANSSI guidance and the SM2 and SM3 family are not enumerated; only the precedence and disagreement-recording mechanism is provided.", "Concrete algorithm object identifiers, parameter tables and curve definitions are deliberately not reproduced; they remain in the referenced registries and standards.", "Threshold, multi-party and aggregate signature schemes have no dedicated combination-rule vocabulary beyond the generic composite rule, and their partial-participation semantics are unmodelled.", "Long-term archival re-signing and evidence-record augmentation are reachable only through proof-of-existence references; the augmentation lifecycle itself is not modelled.", "Signature-creation-time policy - what a signer was permitted to sign and with which device - is out of scope; only the resulting declared parameters are recorded.", "The rationale for the registered parent relation to WM-XCT-006 is not published and the registry review state is boundary-review-required, so the division of signature identity, algorithm and evidence concerns between parent and this mixin is provisional.", "Certificate Transparency log inclusion and consistency proofs are not modelled as a trust-chain or status mechanism.", "Attribute certificates and authorization-only chains are not distinguished from public-key certificate chains.", "Delta CRL reconstruction state and CRL scope arithmetic are referenced through the scope descriptor but are not decomposed into their own finding.", "Non-X.509 chain models such as web-of-trust and simple public key infrastructure are outside the retrieved evidence base.", "Device and hardware attestation chains are reached only through the generic verification-method binding, without their own manufacturer-anchor semantics.", "Cross-certification and bridge trust topologies are acknowledged as producing multiple candidate paths but their policy-mapping arithmetic is not modelled in field-level detail.", "Short-lived certificate regimes that intentionally dispense with revocation are covered only through the declared-unavailable path, not as a distinct issuance strategy.", "ETSI deliverables were cited from their published deliverable URLs, whose served PDFs were not machine-readable through the research tooling at access time. Their clause-level detail here is corroborated through the European Commission's DSS reference documentation and through the IETF specifications rather than quoted directly, so ETSI-derived structure should be re-verified against the deliverable text before any conformance claim.", "Signature creation, signing-key generation and custody, signature-creation-device attestation and signer authentication are deliberately absent from this structure.", "Remote and server-side signing, including evidence of sole control over a remotely held key, is not modelled; it would need its own findings and probably its own model.", "Non-PKI proof systems — zero-knowledge proofs, threshold and multi-party signatures, post-quantum hybrid schemes and blockchain anchoring — are acknowledged as possible proof carriers but no structure is claimed for them.", "Preservation-service protocol operations, meaning the request and response surface of an external preservation service, are referenced but not modelled.", "Time-mark based proof of existence, permitted by CAdES, appears only as a classification value and has no dedicated finding; systems relying on provider-held audit records for proof of existence will need more structure than this provides.", "Countersignature, multi-signature and signature-ordering evidence within one container is only partly reachable through the ordering finding and would benefit from explicit treatment.", "No normative source specifies a portable declaration schema for required participants and thresholds. That finding is assembled from registration-policy preconditions, declared proof purpose and validation-policy references, and should be treated as a gap-supported node rather than as canonical structure.", "Container-specific countersignature encodings for XML, PDF and CMS advanced-signature profiles are not enumerated; only the generic binding distinction is modelled, with the projection register left to record encoding-specific loss.", "Long-term archival augmentation and evidence-record renewal are referenced as external processes; renewal scheduling, hash-algorithm migration for aged evidence and archival time-stamp chaining are not modelled here.", "Aggregate and blind signature schemes where per-member attribution is not recoverable are handled only by an aggregate-attribution marker; the model does not describe how such schemes map onto declared slots.", "Distributed-ledger and account-abstraction multi-signature wallets are not covered as a normative alignment, since no comparably authoritative specification was identified for their participation semantics.", "Retention windows for stored idempotency outcomes are left to the adopting Dimension; no authoritative source fixes a duration, and an unbounded window would itself become a data-protection liability.", "The ETSI deliverable cited for validation status indications and augmentation is served from a host that refuses automated retrieval, so its clauses were confirmed through indexed extracts of the official document rather than by direct fetch during this research.", "Long-term validation and preservation — evidence-record syntax, archive timestamps and hash renewal before algorithm obsolescence — is not modelled.", "Post-quantum migration, hybrid and composite signature composition are not modelled; the versioned algorithm allow-list is the only lever provided.", "Multi-signer countersignature workflows, threshold signing and multi-party computation signing are treated as single opaque executor operations, so intra-executor quorum state is invisible here.", "Human-facing 'what you see is what you sign' presentation assurance is reduced to a pinned immutable payload version; rendering, display fidelity and signer comprehension are not modelled.", "Batch preparation and batched executor calls are not separately modelled; each request is one correlated unit, which may be operationally costly for high-volume signing.", "Non-cryptographic proofs — witnessed, notarial, biometric or attestation-based — fall outside the modelled surface even where an adopting Dimension would call them proofs.", "Executor failure modes short of a returned proof (partial responses, silent drops, duplicate asynchronous deliveries beyond duplicate detection) are handled only by expiry and idempotency, not by a reconciliation protocol.", "Selective-disclosure and redactable-signature schemes, where parts of a protected payload can be withheld while the binding still verifies, are not modelled; the scope manifest expresses a fixed selection rather than a disclosure policy.", "Streaming and chunked payloads, where the protected input is produced incrementally and no single length or complete octet sequence exists at signing time, are not modelled beyond the byte-range scope mechanism.", "Multi-format equivalence - asserting that a payload rendered in two serializations is the same protected object - is deliberately excluded, because it depends on canonicalization semantics owned by the referenced algorithm provider.", "ETSI advanced signature profiles (CAdES, XAdES, JAdES, PAdES) and their signed data object properties, commitment types and signature policy identifiers were not retrieved as live sources; commitment-type semantics are approximated here by proof purpose alone.", "PDF and office-document incremental-update binding, where a later revision appends to a signed byte range, is not modelled and may not be expressible with the current scope manifest.", "Post-quantum and hybrid digest or signature composition, including dual-algorithm bindings over one payload, is only partially reachable through parallel digest evidence records.", "Hardware-attested or enclave-bound protected inputs, where the binding includes a platform measurement, are out of scope and would sit with the proof-method model.", "W3C Verifiable Credentials Data Model 2.0 Section 5.3 on integrity of related resources could not be retrieved in full during research; external-resource pinning is therefore grounded on C2PA hashed URIs and Subresource Integrity rather than on that section.", "Clause-level requirements of ETSI EN 319 122-1, EN 319 132-1, EN 319 142-1 and TS 119 182-1 and of ISO 32000-2:2020 were not machine-retrievable in this pass; versions and scope are cited from publisher listings and corroborated by the European Commission DSS documentation, and all attribute-level tables are recorded as unverified rather than paraphrased.", "ASiC container profiles and multi-file container topology are not modelled, so container-level attachment cases fall outside the current structure.", "Selective-disclosure bindings appear only as registered media types with a loss profile; disclosure construction, holder binding and unlinkability analysis are omitted by design.", "Post-quantum, hybrid and composite signature identifier mappings across the four identifier spaces are not enumerated.", "S/MIME variants, OpenPGP, SSH signatures, JWT-specific profiles, C2PA manifests and blockchain-native proof formats are not covered as projections.", "XML Signature 2.0 and its different transform model are not covered; only version 1.1 semantics are represented.", "Remote and cloud signing protocol bindings are not modelled; only the resulting binding is in scope.", "Human-readable signature appearance, visual representation and what a signer saw at signing time are not modelled.", "The registered parent WM-XCT-006 is asserted from the registry entry alone. Its identity and semantics could not be verified against any external source, so the CHILD link rests on the sourced mixin-attachment pattern rather than on evidence about the parent itself, and should be treated as a gap until the parent specification resolves.", "ETSI deliverables could not be retrieved directly through the fetch path used, which refused the ETSI document server. Their titles, versions and the specific definitions relied upon were corroborated from the ETSI deliverable listing and from European Commission DSS documentation. Any structure resting solely on ETSI text should be re-verified against the ETSI PDFs before adoption.", "No portable measure of proof strength, cryptographic assurance level or residual risk is modelled; none of the cited sources defines one that transfers across X.509, Data Integrity and COSE-based signature families.", "Selective-disclosure and unlinkable derived proofs are carried only as method identifiers. Their governance implications - in particular whether a derived proof supersedes, extends or is independent of its source proof - are not resolved here.", "Multi-signature quorum policy, counter-signature ordering beyond linear proof chains, and threshold or multi-party signing arrangements are left to the host or workflow model.", "Post-quantum migration dates are pinned by reference and not asserted, because the cited NIST transition documents were in draft status when accessed.", "Hardware attestation of the signing environment and remote signing service assurance are referenced as method parameters but not modelled as their own governance surface.", "Records management sources cited are US federal authority guidance; no equivalent non-US national records authority requirement was surveyed, so retention vocabulary may need regional substitution.", "The two most load-bearing normative texts for European signature validation semantics — ETSI EN 319 102-1 and Regulation (EU) No 910/2014 — could not be retrieved live: the ETSI deliverable returned HTTP 403 and the EUR-Lex pages returned empty content. Validation status indications, sub-indications and augmentation levels are therefore grounded on the European Commission's own Digital Signature Service documentation, which is a public-authority first-party source that implements those standards but is not the standard itself. Terms drawn from that route should be re-verified against the primary texts before any conformance claim.", "No ISO deliverable could be retrieved (iso.org returned HTTP 403), so PDF signature carriage under ISO 32000 and long-term preservation profiles under the ISO 14533 family are unrepresented. A deployment that carries PAdES-style signatures should expect container-specific projection losses not enumerated here.", "Post-quantum signature algorithms and hybrid or composite signature constructions are not treated as a distinct concern. They are absorbed as algorithm identifiers under the registry alignment, but migration-specific context — dual-signature carriage, algorithm-agility windows and re-signing obligations — is not modelled.", "Selective disclosure, unlinkable and zero-knowledge proof mechanisms are acknowledged only through the minimization and nonce provisions. Derived-proof lineage, predicate proofs and holder-binding context would require their own structure and are not covered here.", "Biometric, handwritten and scanned-image signature representations, and the human ceremony context around signing intent, are outside the modelled surface even where a jurisdiction treats them as signatures.", "Blockchain and distributed-ledger anchoring is referenced only through the transparency-log and inclusion-proof pattern; consensus, finality and chain-reorganization semantics are not modelled.", "Signature policy documents in the sense of formally published, machine-processable policy files are referenced as validation-policy pointers, but their internal structure is not modelled.", "Hybrid and composite post-quantum proofs: no structure for dual-algorithm proof composition, migration evidence or the interaction between a hybrid proof and an evidence chain built under a single-algorithm assumption.", "Distributed-ledger or transparency-log anchoring as an alternative proof-of-existence source; the proof-of-existence assertion structure would accept it, but no cited source grounds the trust and freshness parameters such an anchor would need.", "Signature creation-side context (device attestation, remote or server-side signing assurance, sole-control evidence) is referenced only as attribution asserted by the proof and is not modelled as an operating surface.", "Countersignature, multi-party and threshold verification orchestration: proof sets and chains are aligned to, but ordering obligations across parties and quorum semantics are not modelled.", "Content-level media provenance bindings, where a proof covers derived renditions rather than a fixed payload version, are excluded; the payload binding assumes an exactly identified version.", "Quantitative assurance or confidence scoring of a verdict; only categorical statuses and reason codes are modelled, deliberately, since no cited source defines a comparable scale.", "ETSI EN 319 102-1 and ETSI TS 119 172-1 could not be retrieved directly because the ETSI deliverable server returned HTTP 403. The European validation model is grounded here through European Commission first-party documentation of its own implementation, so no ETSI clause-level references or conformance claims are made.", "Augmentation and long-term preservation state — baseline level transitions and archive time-stamp series — is declared in the boundary and named in the serial naming rule, but is not elaborated into a local finding.", "Threshold and multi-party signing internals such as secret sharing, protocol roles, partial signature shares and aggregation are treated only as a composition pattern with participation counts; the protocol layer is not modelled.", "Container-specific content-binding mechanics, including XML Signature transforms and canonicalization algorithms and PDF byte-range scoping, are not enumerated.", "Post-quantum migration state, including hybrid and composite signature constructions, is representable only through the method identifier and parameter fields and is not modelled as a first-class concern.", "Ledger or blockchain anchoring as a proof-of-existence mechanism is referenced only generically through the proof-of-existence reference element.", "Signature policy documents and their machine-readable encodings are referenced but not structurally modelled, because policy authoring is owned by the validation model.", "Timestamping authorities, long-term validation, archival re-signing and countersignature chaining are not modelled; they belong to a signature lifecycle model.", "Selective disclosure and derived-proof canonicalization, including BBS-style cryptosuites, are only partially reachable through the chain-step record and are not modelled as a distinct surface.", "Perceptual or soft bindings, watermarking and other non-cryptographic content bindings are excluded; only byte-range, component and box exclusion patterns were examined.", "CMS and S/MIME signed-attribute canonicalization, PDF byte-range digests and PKCS#7 detached-content rules were not examined; conclusions are drawn from the XML, JSON, CBOR, RDF and HTTP families only.", "Post-quantum algorithm identifier registration practice and its effect on algorithm pinning and profile versioning were not reviewed.", "No cited source normatively requires recording an external implementation pin; that requirement is derived from documented divergence risk rather than from a mandate, and should be treated as proposed rather than canonical.", "Streaming and incremental derivation, where protected bytes are produced before the whole input is available, is not modelled.", "Countersignature and multiple-signature interaction, where distinct signatures cover overlapping component sets, is acknowledged only through the signature confusion risk note." ], "conflicts": [ "NIST FIPS 186-5 states that digital signatures support non-repudiation, while UNCITRAL model law and eIDAS make legal recognition a matter for applicable law and reliability criteria. This model resolves the tension by recording non-repudiation support as a conditional declared property with an explicit basis, never as an intrinsic outcome of verification.", "RFC 5652 permits a signing-time attribute inside SignedData while advising that recipients should not rely on originator-supplied values, and NIST SP 800-102 states plainly that signer-asserted time is not trustworthy. The model stores signing time as a claim and requires separate proof-of-existence evidence before reliance.", "Countersignature semantics are not uniform: RFC 5652 defines a countersignature over a SignerInfo signature value, whereas RFC 9052 removed COSE countersignature text citing inaccuracies in the described security properties. The model therefore records the dependency target and whether the previous proof's value is covered, rather than assuming a container-uniform meaning.", "The term validation differs across sources: W3C VC Data Model 2.0 uses it for business-requirement assessment after verification, while eIDAS Article 3 defines it as the process of verifying and confirming that a signature or seal is valid. This model uses verification for the technical and policy check it records and leaves business assessment to the host and validation models.", "Proof purpose vocabularies do not align one-to-one: W3C Data Integrity purposes such as authentication, assertionMethod, capabilityInvocation and capabilityDelegation do not map cleanly to AdES commitment types such as proof of origin, receipt, delivery or approval. Both are carried side by side and neither is normalised into the other.", "Identifier practice conflicts: CMS identifies a signer indirectly through issuer-and-serial or subject key identifier, while Data Integrity permits a proof-level id IRI. The identity priority resolves this by preferring the producing system's authoritative identifier and treating the container-native construct as scoped rather than global.", "Countersignature input differs materially across families: CMS binds the target signer information's signature value as an unsigned attribute and forbids the content-type attribute inside a countersignature, COSE places the target signature value in the countersignature structure's other_fields, and Data Integrity chains proofs by a previous-proof reference to a proof identifier. A record must state which construction applies; the three are not interchangeable.", "Expiry has no common home. Data Integrity defines an expiry property inside the proof, while CMS, JWS and COSE define no normative protected expiry - an expiry in a JWT is a payload claim, not a header parameter. Treating a payload-level expiry as a proof-level expiry is a category error this model records rather than resolves.", "Reference binding is two-layered in XML Signature, where reference validation over digests and signature validation over SignedInfo are separate mandatory steps, while JWS and COSE have a single protected input with no separate reference layer. A digest mismatch and a signature failure therefore mean different things in different families.", "Digest evidence encodings are not interoperable: CMS carries an object identifier plus raw octets, XML Signature an algorithm URI plus base64, Subresource Integrity a prefixed base64 expression, Data Integrity a multibase value, and C2PA an algorithm label plus binary hash inside a hashed URI. No single encoding can be assumed, which is why an explicit encoding label is mandatory here.", "XML Signature 2.0 diverges from the 1.1 Recommendation by removing the Reference URI attribute in favour of a selection element; this model aligns to 1.1 only and does not treat 2.0 as normative.", "Content type is a mandatory signed attribute that must match the encapsulated type in CMS, but is explicitly advisory and ignored by implementations in JWS unless the application acts on it. The same conceptual field therefore carries different normative weight, which is why the type protection flag is required.", "Subresource Integrity is a Working Draft whose details may change; it is used only as corroboration for the digest-pinning and agility pattern and is not a conformance target.", "Key ordering rules are mutually incompatible: RFC 8785 sorts by UTF-16 code units of unescaped property names, RFC 8949 deterministic CBOR sorts by bytewise order of the encoded keys, and Canonical XML sorts attributes by namespace URI then local name. No cross-syntax ordering rule exists and none is invented here.", "Duplicate key handling diverges: RFC 8259 makes uniqueness a SHOULD with explicitly unpredictable parser behaviour, RFC 8785 requires I-JSON and forbids duplicates outright, and RFC 8949 treats a duplicate CBOR map key as well-formed but not valid, leaving disposition to the protocol.", "Canonical XML 2.0 documents unresolved defects in Canonical XML 1.0 and 1.1 and in Exclusive C14N, including QName exposure relevant to wrapping, yet it was published as a Working Group Note rather than a Recommendation. The versions with documented defects therefore remain the deployed normative ones.", "Unicode normalization is applied by neither Canonical XML nor RFC 8785, while wider web guidance recommends NFC. Applying any normalization inside a chain is therefore a local decision, and NFKC or NFKD are irreversible and must not be applied blindly.", "Timestamp representations disagree: RFC 9421 uses integer UNIX seconds, Data Integrity uses an XMLSchema dateTime, and neither guarantees an explicit offset by construction. This model's own RFC 3339 rule therefore differs from both, and every conversion must retain the original lexical value.", "RFC 7515 places unprotected headers outside integrity protection while noting that changing them causes validation failure where key selection depends on them; RFC 9052 states more strictly that an attribute must be taken from the protected bucket where present. This model adopts the stricter reading and records the divergence.", "RFC 9052 states that COSE single-signer and multi-signer structures cannot be converted because the structure identity is part of the signing input, while implementation practice commonly speaks of converting between them. The model treats any such move as re-signing, not re-encoding, and records it as a blocking condition.", "RFC 7797 permits unencoded payloads yet forbids them in JWTs and forbids a '.' character in unencoded compact payloads, so a valid JWS can be inexpressible to a JWT-shaped consumer. The model records this as a forbidden fallback rather than a tolerated degradation.", "W3C Data Integrity recommends date-based cryptosuite version strings, which sits against the identity rule that a date is never an identifier. The model resolves this by treating the cryptosuite token as an opaque governed string carried verbatim, never parsed as a date.", "RFC 9052 removed countersignatures and RFC 9338 redefined them with different coverage of the target's cryptographic material, so similarly named countersignatures from different specification generations are not equivalent; the model requires a version marker on countersignature coverage descriptors.", "A PDF signature is a detached CMS object over a byte range while being enveloped at document level, so a single binding form label is ambiguous unless the level of assertion is stated; the model therefore requires the level alongside the form code.", "The European Commission DSS implementation restricts PAdES packaging to enveloped, while ETSI and ISO material describes the byte-range mechanism without using that packaging vocabulary; the model records the packaging term as implementation-descriptive and the byte-range binding as the structural fact.", "RFC 5019 was obsoleted by RFC 9919, which changes hash-algorithm guidance and restates nonce handling; lightweight-profile behaviour must therefore be recorded together with the profile version rather than assumed, and older records must retain the profile they were made under.", "RFC 6960 treats unknown as a first-class status distinct from good and revoked, while RFC 9608 directs relying parties to skip revocation checking entirely when a no-revocation-available declaration is present. The model records both without collapsing declared-unavailable into unknown.", "CRL certificateHold expresses a reversible suspension with no direct equivalent in the online status protocol's three values, while Bitstring Status List models suspension as a separate reversible status purpose. Mechanism-specific vocabularies are retained rather than normalized into one enumeration.", "RFC 7633 makes hard-fail well-founded only where the certificate itself declares the required feature, whereas CA/Browser Forum operational practice for publicly trusted TLS reflects a different stance. Neither is treated as the model's default.", "ETSI EN 319 102-1, TS 119 612 and TS 119 615 normative texts could not be retrieved directly — etsi.org returned HTTP 403 for its published deliverables — so the indication and sub-indication vocabulary and trusted-list field semantics are grounded in European Commission first-party documentation and the live EU List of Trusted Lists. That alignment is provisional and is flagged as such rather than presented as verified.", "DID Resolution v1.0 is a Candidate Recommendation Draft and DIDs v1.1 is a Candidate Recommendation; resolution metadata and version-parameter details may still change, so those fields are recorded as alignment targets at a stated draft date rather than as stable structure.", "The live EU List of Trusted Lists retrieved for this model exposed sequence and version identifiers but the list issue date-time and next-update elements were not observable in the retrieved excerpt, so the trust-store pin treats issue date-time as required by the pin contract while noting that its presence was not directly confirmed in that observation.", "The IANA JOSE registry marks the EdDSA algorithm name Deprecated in favour of separate Ed25519 and Ed448 entries, while other profiles and the COSE registry continue to carry EdDSA-labelled entries; a bare algorithm name is therefore not portable across registries and must always be namespace-qualified.", "NIST SP 800-131A Rev. 3 remains an initial public draft dated 21 October 2024 proposing retirement of DSA signature generation and of SHA-1 and 224-bit hash functions, while Rev. 2 of March 2019 is the final publication in force; a policy pin must state which one it cites.", "NIST IR 8547 is an initial public draft dated 12 November 2024 with indicative deprecation around 2030 and disallowance by 2035, whereas ETSI and national catalogues publish different sunset dates; no universal transition date is asserted by this model.", "FIPS 186-5 retains DSA for verification of existing signatures only, while some deployed ecosystems still generate DSA signatures, so approval state differs by operation and must be recorded separately for generation and verification.", "The ETSI three-valued indication of TOTAL-PASSED, INDETERMINATE and TOTAL-FAILED has no lossless mapping onto the W3C Data Integrity boolean verification result; indeterminate collapses to false unless the mapping is explicitly marked lossy.", "The COSE registry expresses identifier state as Recommended Yes, No or Deprecated, while the JOSE registry uses Required, Recommended, Optional, Deprecated and Prohibited; the two state vocabularies are not interchangeable and must be mapped, not merged.", "Composite ML-DSA constructions achieve EUF-CMA rather than the SUF-CMA property of pure ML-DSA, so a hybrid is not automatically stronger than its strongest component on every security property.", "RFC 3161 makes the ordering field optional and false by default, so two tokens from one authority are strictly orderable only when their accuracy intervals do not overlap. Implementations that treat generation time as a total order will disagree with a conformant reading; this model follows the conformant reading and refuses the assertion.", "RFC 6960 permits pre-produced OCSP responses and acknowledges the resulting replay exposure. A freshness rule expressed purely as next-update can therefore accept a response produced before a revocation, so the model records nonce presence and the caveat rather than treating next-update as sufficient.", "RFC 4998 recommends redundant evidence records under different algorithms and different authorities, whereas common container practice maintains a single archive time-stamp chain. A single chain is widespread practice, not a normative sufficiency claim, and the model records the single-point-of-failure note instead of endorsing it.", "ETSI EN 319 142-1 advises against relying on the PDF VRI dictionary because the same material is already referenced from the document security store, yet widely deployed tooling still writes VRI entries. Both may be present and may disagree, so the packaging finding requires an explicit reconciliation rule.", "eIDAS Article 32 expresses validation obligations in legal terms tied to qualified signatures, while EN 319 102-1 expresses outcomes as indications and sub-indications. A passing indication is a technical result and is not by itself a legal determination; the model keeps them as separate recorded facts.", "NIST algorithm-transition practice and European algorithm-suite practice do not always deprecate the same parameters at the same time, so the constraint snapshot must record which policy applied rather than assume a single global schedule.", "Timestamp handling: Data Integrity permits proof timestamps without a timezone offset and treats them as UTC, whereas this model rejects offset-less values. The divergence is recorded as an alignment conflict; ingesting a Data Integrity proof requires the offset to be supplied or the value to be flagged as inferred.", "Validation vocabularies do not have a normative crosswalk. AdES indications and sub-indications, C2PA error, warning and informational status codes, and Data Integrity verification results are structurally different. Any mapping between them is a local assertion that must be evidenced, not a conformance claim.", "The X.509 superseded revocation reason applies to certificates, not to signatures or proofs. Reusing it as a supersession vocabulary for proof records is an analogy adopted for consistency, not conformance to RFC 5280 semantics.", "Minimum evidence sets differ. C2PA treats a time-stamped manifest as remaining valid after credential expiry, while the NARA e-signature guidance requires retaining the certificates, the CRL current at signing and the trust path. Both are accommodated, but an adopting Dimension must choose which minimum it holds itself to and record that choice.", "No cited standard defines revocation of a signature itself. Revocation attaches to certificates and keys. The model therefore records invalidation of the governance state plus references to external revocation evidence, and an implementer expecting a signature-revocation primitive will not find one.", "FIPS 186-5 carries a published errata notice, so a pinned algorithm identifier should record the errata state; treating the base publication as the sole reference could pin a superseded parameter set.", "Jurisdictional divergence is live: the UK-retained revised text of Regulation (EU) No 910/2014 has diverged from the EU consolidated text and carries further pending amendments, so a regime reference without a jurisdiction code and effective interval is ambiguous.", "NIST SP 800-102, the clearest primary statement that a purported signing time gives no assurance without trusted accuracy, was withdrawn on 1 July 2025. Its technical distinction between claimed and trusted time remains corroborated by the time-stamp protocol's proof-of-existence semantics and by long-term validation practice, but the claimed-versus-trusted separation should not be presented as resting on a current NIST recommendation.", "W3C Decentralized Identifiers v1.1 is a Candidate Recommendation Snapshot rather than a Recommendation, so verification-method and controller terms drawn from it carry a maturity caveat; the corresponding Data Integrity terms are at Recommendation status and should be preferred where both are available.", "Canonicalization requirements conflict in practice across bindings: object-level canonicalization restricts input to a constrained JSON subset with bounded numeric precision, graph-level canonicalization requires deterministic blank-node labelling and is vulnerable to deliberately expensive inputs, and envelope constructions avoid canonicalization entirely by authenticating a fixed pre-encoding. No single profile satisfies all three, which is why the profile is declared per deployment rather than fixed by the model.", "Multi-signature semantics conflict between families: an envelope treats multiple signatures as equivalent to separate envelopes with no ordering, an ordered proof chain makes predecessor order semantically significant, and the COSE single-signer and multi-signer structures are explicitly not interconvertible. A model that flattened these into one collection would silently destroy meaning, so ordering and structure are carried explicitly.", "Transparency-log evidence and revocation-status evidence answer different questions and are sometimes treated as interchangeable in practice; logs explicitly do not prevent or adjudicate misissuance, and the sufficiency of evidence is a client-policy matter. Recording either as a validity conclusion would overstate what the evidence supports.", "FIPS 186-5 carries a planning notice indicating that identified issues will be corrected in a future revision, so algorithm-identifier alignment must track errata rather than assume a stable text.", "Identifier style: W3C Data Integrity requires `verificationMethod` to be a URL, JOSE and COSE use an opaque `kid`, RFC 9421 uses `keyid`, and remote-signing APIs use an opaque `credentialID`. The model pins whichever form the executor requires and records the governing scheme rather than normalising them into one, because verifiers compare these values literally.", "Time representation: Data Integrity uses XML Schema dateTimeStamp for `created` and `expires`, RFC 9421 uses integer UNIX timestamps, and time-stamping uses generalised time. The model stores RFC 3339 internally and keeps the wire representation alongside; round-tripping is lossy for sub-second precision and leap-second values, which is recorded rather than hidden.", "Canonicalization: RFC 8785 JCS, JSON-LD and RDF canonicalization, the RFC 9421 signature base and the COSE Sig_structure are mutually incompatible transforms over superficially similar data. Choosing the wrong profile yields a proof that verifies nowhere, which is why unnamed or unversioned profiles are refused outright.", "Ordering: Data Integrity proof sets are explicitly unordered while proof chains are ordered by an explicit previous-proof reference, yet most storage imposes an array order that can be mistaken for chain order. The model keeps serial ordinal and chain position as separate attributes and forbids inferring one from the other.", "Digest-only handoff versus signer awareness: JOSE detached payloads and time-stamping message imprints mean the executor may never see the content, while some signature levels presuppose the signer saw the document. The model records the digest-only flag and makes no claim of signer awareness in that case.", "Protected coverage varies by mechanism: COSE and JOSE can cover the algorithm and key reference in a protected bucket, whereas some deployments carry them unprotected. The model records a protected-coverage flag per pinned field rather than assuming coverage, because an unprotected field cannot be relied on for the admission comparison it appears to support.", "Set semantics differ across families. Data Integrity requires that every proof referenced by a previous-proof pointer must also verify for the current proof to be considered verified, and a combined verification result fails as a whole, whereas CMS states that successful validation of one signer's signature is usually treated as success for that signer while other environments must define their own rules. The model therefore records the topology and the governing application rule explicitly instead of assuming either convention.", "Binding strength differs between chain mechanisms. A COSE countersignature covers the prior signature bytes, while a Data Integrity proof chain points at a prior proof identifier. An identifier-based dependency is not cryptographically bound to the prior bytes and depends on the resolver's integrity, so the model records a dependency binding kind rather than treating the two as equivalent.", "The word revocation is overloaded. OpenPGP revocation signatures act on keys, subkeys and certifications, and status-list revocation acts on a credential, while this model's invalidation acts on a proof, a binding or a policy use. The model uses invalidation exclusively and records external revocations only as referenced supporting evidence.", "Threshold cryptography and M-of-N participation are frequently conflated. A threshold-produced signature must verify under the conventional verification algorithm and is therefore indistinguishable from a single-party signature to a verifier, so it cannot evidence multiple satisfied slots; the model states this explicitly as a reporting rule.", "Correction models diverge. The transparency architecture corrects by registering a new statement under the same issuer and subject, with no explicit replacement pointer and with relying parties evaluating the statement history, whereas provenance vocabularies use an explicit revision link. The model keeps the explicit link locally and records the loss when projecting into the weaker form.", "There is no ratified standard for idempotency keys. The relevant Internet-Draft is expired, so the normative anchor is method idempotency and conditional preconditions from HTTP semantics, with the key-and-fingerprint pattern recorded as common practice rather than as a standards requirement.", "Verdict shape conflicts across communities: certificate-based validation procedures report an indication with a sub-indication and treat indeterminate as a first-class outcome, while the linked-data proof model returns a boolean verified flag with warning and error lists. This model keeps dimensions separate and refuses boolean requests, which will not round-trip cleanly into a boolean-only consumer.", "Algorithm status conflicts between regimes: transition guidance permits legacy verification with an algorithm that is disallowed for generation, while a signature validation policy may treat the same algorithm as failing after its sunset date. The pinned policy decides, and the run record must show which regime was applied.", "Revocation freshness expectations conflict with real signature profiles: a zero freshness interval is specified in some referenced material while implementations default to ignoring freshness to accommodate baseline signatures without timestamps. The freshness limit is therefore a required explicit pin, including an explicit unconstrained value.", "Preservation obligations and records disposal schedules can conflict: a preservation arrangement may require retention beyond the host record's schedule. This model reports both as blocking conditions and does not resolve the conflict, which remains an authority question for the records model.", "Detached-payload exports satisfy disclosure minimisation but reduce later verifiability; refusing an export to preserve verifiability can conflict with a lawful disclosure limit. The loss register records the tension rather than resolving it." ], "regional_assumptions": [ "FIPS approval states and NIST transition dates are United States federal policy and are not globally binding; they are recorded as one policy authority among several with an explicit precedence order.", "Signature qualification, trusted-list membership and legal effect are European Union constructs; outside that jurisdiction those dimension slots remain not assessed unless a local instrument is referenced.", "Draft post-quantum transition dates are treated as indicative only; an adopting Dimension in another jurisdiction pins its own national roadmap as the governing policy.", "The model assumes offset-bearing timestamps are available; where local civil time is required by regulation it is a derived presentation, never the stored value.", "Where a Dimension operates under a national cryptographic catalogue not enumerated here, the precedence mechanism applies but the catalogue itself must be registered before adoption.", "Trust-list semantics are grounded in the EU List of Trusted Lists and its ETSI profile. Other jurisdictions operate different trust-list, root-programme or bridge models, and the snapshot pin fields must be re-bound to whatever series identifier and issue metadata those schemes publish.", "CA/Browser Forum requirements apply to publicly trusted TLS server certificates and are not normative for enterprise, government, device or closed-community infrastructures; treating their operational stance as a default would be a category error.", "Retention horizons for revocation evidence and replay packages are jurisdiction- and sector-specific. The model records the horizon reference and leaves its determination to the adopting Dimension's records-management policy.", "Explicit UTC offsets are required rather than assumed because validation instants, evidence windows and proofs of existence are routinely compared across jurisdictions and across systems with different local clocks.", "Privacy expectations around status queries differ materially by jurisdiction; the model records the delivery channel so that a Dimension can apply its own local rule rather than inheriting one.", "The eIDAS articles were read from the retained-EU-law text published by legislation.gov.uk. The quoted wording of Articles 32, 34 and 42 matches the EU original in the parts relied on, but the retained version omits paragraphs; the EUR-Lex text governs in EU contexts and should be used for any binding interpretation.", "Trusted-list mechanics assume a supervision-list arrangement of the European kind. Other jurisdictions govern trust stores differently, so the model carries a versioned pointer and state digest rather than assuming any particular list.", "NIST guidance on signature timeliness and algorithm transitions is United States federal policy; adopting Dimensions elsewhere must bind their own algorithm policy and cannot inherit these schedules by default.", "Nothing here presumes any particular legal effect for a signature in any jurisdiction, nor that a qualified status in one framework transfers to another.", "Validation status indication terminology follows a European trust-services standard. Adopting it is an alignment for reporting vocabulary and is not a claim of qualified electronic signature conformance, which would require conformity assessment evidence this model does not hold.", "The legal effect of a countersignature, of a witness or notarial role and of a party's entitlement to invalidate varies by jurisdiction. The model records evidence and declarations only and makes no claim about enforceability or non-repudiation in any forum.", "Data-protection regimes differ on whether participant identity and reason text may be retained in an append-only history. The access exceptions and the crypto-erasure route exist so that the adopting Dimension can meet a local obligation without breaking ordinal continuity or integrity checks.", "Where an adopting Dimension operates under a regime that mandates erasure of personal data on request, the tension with append-only retention must be resolved by that Dimension's retention policy and by the owning storage model, not by weakening the immutability invariant here.", "The remote-signing request and response shape — credential identifier, activation data, hash array with algorithm OID, operation mode, validity period and response URI — is drawn from the European remote-signing ecosystem. Other jurisdictions use different remote-signing protocols with different field names, so the executor registry, not the model, carries the mapping.", "No assumption is made that an attached proof meets any jurisdiction's legal threshold for an electronic signature. Legal effect, qualified status, evidentiary weight and admissibility are determined by the adopting Dimension's jurisdiction and are never asserted by this model.", "Clock authority, time source accreditation and permitted skew are jurisdiction- and operator-specific; the model requires them to be declared explicitly rather than assuming UTC-synchronised infrastructure or a trusted time source.", "Data-protection and data-residency constraints on transmitting host content to an external executor vary by region. The model defaults to digest-only disclosure precisely so it does not depend on a permissive regime.", "National algorithm restrictions may be narrower or broader than the NIST-approved set; the allow-list is therefore a Dimension-owned registry rather than a value fixed by this model.", "The model assumes no jurisdiction-specific signature form. EU eIDAS advanced and qualified electronic signature requirements, and the ETSI profiles implementing them, impose additional obligations on what must be presented to and bound for the signer; those are not represented here.", "United States ESIGN and UETA intent-to-sign and record-retention requirements are not modelled; the proof purpose field is a technical binding, not a legal intent declaration.", "Data-protection regimes creating erasure obligations over protected content conflict with the obligation to keep binding evidence checkable. The model resolves this only by tombstoning and marking the payload unresolvable; which obligation prevails is a Dimension and jurisdiction decision.", "Algorithm acceptability is regional and time-bound. National cryptographic guidance differs on which digest algorithms remain acceptable, so algorithm strength status is advisory and locally sourced rather than universal.", "The baseline level vocabulary B-B, B-T, B-LT and B-LTA and the CAdES, XAdES, PAdES and JAdES families are European constructs published by ETSI in support of EU electronic signature regulation. They are treated as alignments, not as universal requirements, and the model works unchanged where they do not apply.", "The European Commission DSS documentation reflects one implementation's packaging vocabulary and is used as descriptive evidence of practice, never as a normative source.", "Trusted list membership, qualified status and any legal presumption attached to a signature are jurisdiction-specific and are deliberately left outside the model boundary.", "IANA, W3C and IETF material is treated as globally applicable, but registry contents change over time, so every profile pins a registry snapshot rather than assuming a stable global state.", "Qualified electronic signature, seal, validation and preservation regimes derive from EU law and its retained national variants. They are pinned as references with jurisdiction and effective interval and are never treated as universal facts about a proof.", "The UK-retained text of Regulation (EU) No 910/2014 was used as the accessible authoritative rendering of the article structure. It is not identical to the current EU consolidated text and must not be substituted for it in an EU context.", "NARA guidance binds US federal agencies. It is used here for its enumeration of the evidence needed to revalidate a signature over time and for retention and disposition separation, not as a globally applicable obligation.", "CA/Browser Forum requirements bind publicly trusted code-signing certification authorities. They evidence industry-normative separation of key protection from CA operation and bounded revocation response; they are not general signature law and do not apply to private or enterprise trust domains.", "NIST publications express US federal cryptographic transition policy. Other jurisdictions publish differing algorithm transition schedules, so transition status must always carry its source regime.", "No assumption is made that a proof accepted in one jurisdiction carries legal effect in another; cross-border recognition is an external legal determination.", "Validation status vocabulary, augmentation levels and trusted-list mechanics are drawn from a European public-authority implementation. Other jurisdictions use different level names, different trust-anchor distribution and different validation-report structures, so these are recorded as referenced outcomes with their producing policy rather than as a universal vocabulary.", "Legal effect, qualification of a signature or seal, and the evidentiary weight of a proof are jurisdiction-specific and are excluded from this model entirely; a deployment must reference its own regulatory model rather than infer effect from any recorded technical status.", "Identity attributes about a claimed signer are personal data under several regional regimes with differing minimization, disclosure and retention obligations. The access layer supplies scope separation and minimization hooks, but the applicable regime and its retention periods are supplied by the adopting Dimension.", "Approved algorithm sets and their deprecation timelines differ between national and regional authorities; the model binds to a declared registry rather than asserting a globally approved set.", "Time-zone handling assumes explicit offsets throughout; deployments operating in jurisdictions that mandate local civil time in official records must record the offset explicitly and treat any local rendering as a projection.", "The indication and sub-indication vocabulary, validation constraint groups and preservation profile concepts derive from the European trust services framework; the semantics are reusable but the specific code values and any qualified-status notion are region-bound and must not be assumed elsewhere.", "Algorithm transition categories (acceptable, deprecated, disallowed, legacy use) reflect United States federal guidance; other jurisdictions publish different horizons for the same algorithms, so an algorithm horizon is only meaningful with its policy reference attached.", "Disposition, freeze and transfer requirement structure reflects United States federal records management practice; national archives and sector regulators elsewhere define different disposal categories and hold mechanics.", "Legal hold semantics are assumed to originate outside the model in every jurisdiction, but which party may issue and release a hold varies; the readiness report therefore records the issuing authority rather than assuming one.", "Time zone and offset handling assumes the recording system can obtain the original offset; where a source system stores only local wall-clock time, values are rejected rather than coerced, which may reduce coverage in some legacy estates.", "eIDAS definitions were verified from the text of Regulation (EU) No 910/2014 published on legislation.gov.uk as retained UK law, revised with amendments to 5 February 2026. The current EU consolidated text, as amended in 2024, may differ in wording and numbering, so no conformance to the EU text is claimed and any regulated categorisation must be re-verified against the text in force in the relevant jurisdiction.", "The distinction between a natural-person electronic signature and a legal-person electronic seal is a European regulatory construct. Other jurisdictions may not recognise seals as a separate category, so the signer party type and proof kind codes must be interpreted against local law.", "Qualification claims such as qualified signature, qualified seal and qualified time stamp are meaningful only within a regime that maintains trusted lists. Outside such a regime the qualification field is left unset rather than approximated.", "The UNCITRAL reliability, non-discrimination and functional-equivalence criteria are model-law guidance requiring national enactment; enactment status and local variation differ by state.", "Approved-algorithm status is regime-specific. NIST approval does not imply approval under other national cryptographic regimes, so the claimed security category is always recorded together with the authority whose scheme it references.", "Retention periods, legal-hold triggers and evidential-preservation duties vary by jurisdiction and sector; this model defers all of them to the adopting Dimension's retention policy and to referenced obligation models.", "No jurisdiction-specific electronic signature regime was used to derive structure. Regional advanced or qualified signature schemes may mandate specific canonicalization algorithms, signature policy identifiers or archival fields that are absent here.", "All cited sources are English-language publications of international standards bodies and one industry consortium. National or sector profiles that mandate particular algorithms, key lengths or transform restrictions are not represented.", "Retention periods, legal hold and destruction obligations are assumed to be set by the adopting Dimension's jurisdiction rather than by this model, and no default period is proposed.", "Registry availability is assumed: the model relies on governed algorithm and media-type identifiers remaining resolvable, which may not hold in air-gapped or sovereign deployments." ], "adversarial_checks": [ "Counterexample test - a signature whose primitive check succeeds but whose verification method is not authorised for the declared proof purpose must not be recordable as overall valid; the mandatory dimension set forces a purpose-mismatch outcome with its own reason code.", "Downgrade test - a container asserting none, or an HMAC algorithm presented against an RSA public key, must be recorded as policy-rejected with a key-to-algorithm binding reason, because the accepted set is verifier-side and never taken from the container.", "Time test - a signature claiming a signing time inside the certificate validity window but carrying no proof-of-existence reference cannot resolve sunset or revocation questions; the correct outcome is indeterminate or evidence-incomplete, never valid.", "Observability test - the model must not permit deterministic to be recorded as a verified fact inferred from the signature value alone, since deterministic and randomized signatures of the same suite are indistinguishable to a verifier.", "Composite test - a proof whose post-quantum component verifies while its classical component fails must be recorded as invalid; no partial or degraded pass state exists in the outcome vocabulary.", "Staleness test - reusing a verdict recorded under an earlier policy pin after the suite's sunset date must surface as policy-pin drift on a superseding record, not as a fresh valid result.", "Boundary test - no bundle, layer, finding or function of this model executes verification, enforces acceptance, evaluates a trust path, or writes the verifying system's audit trail; every such capability resolves to a REFERENCE link with the target named.", "Ambiguity test - a suite declaration missing a required parameter must yield an explicit incomplete status with a reason code; it must never be completed by applying an implementation default and then reported as valid.", "Checked that no finding or function claims ownership of path-validation execution. The constraint finding records inputs supplied and outcomes reported with the reporting validator's identity and version; no function performs the RFC 5280 algorithm, and the cryptographic verification outcome is carried as a separate attributed field.", "Checked that OCSP responder operation and certificate authority revocation execution are not modelled locally. Delegated signing and the delegated signing purpose appear only as a recorded authorization basis for evidence already produced elsewhere, never as a capability this model exercises.", "Rejected an attractive standalone revocation-lifecycle layer. The transition from valid to revoked, held or superseded is decided and published by the issuing authority, so only observed transitions with published effective dates and separate observation times are carried, and prior determinations are superseded rather than rewritten.", "Tested the counterexample of a certificate carrying a no-revocation-available declaration, where absent status evidence is normatively correct rather than a gap. The determinacy classification therefore distinguishes declared-unavailable from expected-but-missing, and a policy that treated the two identically would misread the record.", "Tested the counterexample of an expired or later-revoked certificate whose signature remains sound at best-signature time given a proof of existence. Current-time framing, best-signature-time framing and historical replay are held as separate records over the same evidence rather than collapsed into a single verdict field.", "Rejected asserting any universal hard-fail, soft-fail or treat-as-unknown rule. RFC 7633 makes hard-fail well-founded only where declared in the certificate, while publicly trusted TLS practice reflects a different stance, so the stance is carried as an attributed external reference and the decision stays with the policy model.", "Checked that no bundle or artifact absorbs audit-trail semantics. The replay package is an evidence container assembled from this model's own captures; audit entries for captures and exports are located by reference and are structured and retained by the Dimension's audit model.", "Checked the exclusive representation rule across all nine findings: the three findings declaring artifacts hold retrieved bytes this model genuinely custodies, and the six inline findings are reference, scalar or outcome data whose underlying bytes are either externally owned or already retained by an artifact in the same layer.", "Checked that the trust-store pin does not become a local copy of a trust list. The pin is location, sequence number, issue date-time, digest and observed status; a consumer needing the bytes fetches the pinned issue from its operator and verifies the digest, which keeps list issuance and status determination with the scheme operator.", "Does any node claim ownership of a neighbour's operational semantics? Verdict recording is defined as recording an external application's output with explicit no-evaluation wording; the time-authority finding is deliberately inline-reference-only; corroboration is pointer-based; audit events are emitted, not stored. Each is restated in boundary notes and in the composition ledger.", "Could a transparency-log inclusion proof be read as proof of signer identity? A dedicated definitional question, a mandatory scope-statement data element carried with every reference, and a standing policy all make the negative explicit, matching the RFC 9162 position that logs enable detection of misissuance rather than establish legitimacy.", "Can a verdict or a proof be silently changed or removed? Update rules forbid mutation, correction is by supersession assertion, deletion is tombstone-only with mandatory non-replayable flagging, and rejected mutations are emitted as events. An agent following the interface rules cannot produce a clean-looking history.", "Would evidence still be interpretable after the digest algorithm protecting it is broken? The integrity rule keeps digest history additive, both renewal kinds are modelled, redundant chains are asked about, and the collision-migration question forces a residual-risk statement covering the pre-migration interval.", "Is a date ever load-bearing as an identifier? Identity priority rejects generation times, validation instants and file names, and the serial naming rule forbids substituting a local counter for an issuer sequence or closing a gap by renumbering.", "Can an evidence gap be misread as a negative finding? Read rules require gaps and negative findings to be distinguished, the gap-reporting function separates them explicitly, and the completeness policy forces an indeterminate result rather than a valid or invalid one where evidence is short.", "Does the model quietly duplicate the trust-service registry? The only trust-service data held locally are identifiers, versioned pointers, a state digest and an observed status with its observation instant — enough to reproduce one validation, not enough to act as a second register.", "Chain-collapse check: take a recorded co-signature set and confirm that removing any one member leaves every remaining member verifiable on its own against the pinned payload version. If a member's outcome depends on a sibling, the topology marker is wrong and the set is actually a chain.", "Threshold-inflation check: attempt to reach a conclusion of approved or authorised from any combination of fields available in this model without an external decision result. Every completion projection must yield indeterminate, and a threshold-produced signature must contribute exactly one slot.", "Byte-drift check: re-serialize a pinned payload with a different serializer and confirm that the recorded canonicalization method and digest surface a mismatch rather than the record silently re-binding to the new bytes.", "Ownership check: walk every function's effects and confirm that none revokes a key or certificate, evaluates or enforces policy, writes or attests an audit trail, operates a log, issues a time-stamp or deletes content. Each such capability must appear only as a composition reference with a named external owner.", "Replay-and-conflict check: submit the same co-sign request twice with an identical idempotency key but a differing body, and confirm rejection as a fingerprint conflict rather than the appending of a second proof; then submit with a stale expected-version token and confirm a precondition failure with no partial write.", "Order-rewrite check: attempt to renumber, reorder or delete a countersignature ordinal after an invalidation assertion has been appended, and confirm rejection with the requirement to create a superseding chain instead.", "Silent-inference check: remove all recorded validation outcomes from a set and confirm that reads report indeterminate for each member rather than defaulting to collected-and-therefore-valid, and that absent invalidation is not reported as positive evidence of validity.", "Scope-creep check: confirm that an invalidation assertion naming the signer or key binding leaves sibling co-signatures, the payload binding and any credential status entry untouched, and that no local record was written to a key, status, log or audit store.", "Algorithm substitution: a returned proof declares an algorithm or parameter set other than the one pinned. Refused, because admission compares the returned algorithm and parameters field-by-field against the pinned configuration, and because unprotected metadata is never accepted as evidence for that comparison — a protected-coverage flag records whether the field was actually covered.", "Time-of-check-to-time-of-use drift: the host payload changes between preparation and attachment, so the proof commits to content no longer there. Detected, because the protected input is recomputed from the pinned immutable payload version and must be byte-identical to the manifest, and because attachment carries an expected-host-version precondition that fails on drift.", "Unsolicited proof injection: a well-formed, cryptographically genuine proof arrives with no matching open request. Refused, because admission requires a dispatched, unexpired request record for the claimed correlation identifier and treats a missing or already-closed correlation as terminal.", "Cross-context replay: a genuine proof is replayed against a different host version, audience or purpose. Refused, because domain or audience, challenge or nonce, presentation header and proof purpose are pinned and compared, and because the replay scope key composed of nonce, host record, purpose and audience is checked for prior use.", "Validity by presence: a consumer treats an attached proof, or a stored successful verification observation, as current validity. Blocked at the read surface, which marks every observation as bound to its observation instant and pinned inputs, enumerates what a proof does not assert, and states that verification does not imply evaluation of the truth of the claims.", "Mutable reference leakage: a request payload includes a reference whose content can change after dispatch, letting an attacker choose what the executor actually operates on. Refused at dispatch, because every outgoing reference must resolve to digest-pinned immutable content and an unpinned reference fails the dispatch precondition.", "Retry amplification: a client retries a dispatch after a timeout and obtains two signatures, or extends its own validity window by re-dispatching. Blocked, because dispatch is idempotent under its key, a replay returns the existing dispatch, and the expiry instant is fixed at preparation and never extended by a retry.", "Boundary creep: an implementer adds local key unwrapping, a local verification engine, a local approval step or a local audit log to make the flow feel complete. Rejected, because those capabilities are named as externally owned in the boundary notes and composition links, no function's effects include them, and attachment explicitly enumerates the effects it does not have.", "Silent partial read: a caller with restricted scope receives a filtered proof set and treats it as complete, concluding a record is unsigned. Blocked, because every projection returns a completeness flag, an applied-filter identifier and a withheld count, and an as-of projection is withheld in full rather than silently reduced.", "Reference substitution: a locator resolves to a different representation than the one protected. Checked by requiring digest evidence for every indirect binding, an immutability flag on the representation, and an explicit statement that the binding guarantees only digest equality of what was retrieved - never that the right object was retrieved.", "Unprotected-parameter injection: an attacker adds or relocates a parameter into the unprotected position to change interpretation. Checked by the protected-before-unprotected precedence rule, the requirement that critical parameters appear only in a protected position, and recording duplicates as conflicts.", "Exclusion-range abuse: data hidden inside an excluded region changes how the protected region is interpreted. Checked by requiring every excluded region to carry a constraint on permitted content and by the explicit exclusion-safety question, following the C2PA security requirement.", "Cross-context replay: a valid proof is reused for a different audience or purpose. Checked by binding proof purpose, audience or domain and a challenge into the protected input, and by requiring a challenge whenever an audience is bound.", "Digest downgrade: several digests are recorded and a consumer selects the weakest. Checked by requiring a recorded selection rule, a governing digest reference and an advisory algorithm strength status that never rewrites historical evidence.", "Encoding ambiguity: the same payload signed with a different payload encoding flag produces different protected bytes while appearing identical. Checked by making the carriage and encoding flag a mandatory recorded element and treating it as a protected, must-be-understood parameter.", "Premature countersignature: a dependent proof is taken over a target not yet finalized, so the preserved input does not match what verifiers later see. Checked by requiring a finality assertion and the target digest at the time of dependence before a preserved-input record may be created.", "Empty-value substitution: a resolution failure is silently rendered as an empty or default payload, producing a proof that appears to cover nothing. Checked by the no-silent-substitution policy, the classified failure vocabulary and the append-only failure record.", "Searched for a hidden canonical projection: no bundle, layer, finding, function or service rule assumes JWS, CMS, PAdES or Data Integrity when a profile is absent. Absence is modelled as an incomplete record and an explicit policy forbids defaulting.", "Searched for ownership creep into execution: no function canonicalizes, computes a digest, dereferences a locator, encodes, parses or verifies. Every such operation is delegated to the referenced runtime, and outputs are stored only by reference with their producing component.", "Checked audit-trail capture: the access layer writes to the adopting Dimension's audit facility and states explicitly that this model neither defines nor interprets audit-trail semantics and never treats a referenced audit record as its own validation evidence.", "Checked PKI capture: certificate issuance, path building, trust anchor selection and revocation determination were kept in the referenced PKI model even though the carriage parameters are defined in the same specifications this model cites.", "Counterexample search against the claim that every projection supports detached binding: PAdES packaging is enveloped-only in the DSS implementation and binds by byte range; JWS Compact Serialization carries neither an unprotected header nor multiple signatures; COSE detached payload requires an application guarantee of unchanged transport. All three are recorded as constraints or blocking conditions rather than smoothed into a uniform capability claim.", "Checked identifier hygiene: every local identifier is lower-kebab-case with the sig-proj- prefix and no date-like component, digests are recorded as integrity metadata only, and serial report names carry a monotonic sequence rather than an issue date.", "Checked that conformance is not asserted: every external standard appears as an ALIGN or REFERENCE link, the conformance report explicitly aggregates external results and states alignment findings, and clauses that could not be retrieved are flagged unverified rather than restated.", "Checked artifact discipline: five findings whose content is descriptive or reference-only carry empty artifact arrays with substantive rationales, and the three findings that genuinely produce documents carry artifacts with a null rationale; no finding populates both.", "Tested whether any finding grants this model ownership of cryptographic verification. The state finding records only reported indications with attribution and time, no function performs validation, and the integrity rule explicitly forbids treating a locally computed digest as equivalent to an external validator's result.", "Tested whether the retention finding implies deletion execution. The delete rules assign erasure, backup expiry, audit retention and host deletion to external models, and this model writes only a tombstone after disposition is reported to it; an unresolvable schedule causes retention and flagging rather than default disposal.", "Tested whether role separation can silently collapse. The register requires distinct references for signing authorization, key custody, verification-policy authority and legal-effect assessment, and a single-party assignment must record an explicit conflict declaration, a compensating control, an approving role and a re-evaluation point.", "Tested whether public verifiability leaks payload. Disclosure classes are independent and the access default rule states that a grant on proof bytes never implies a grant on host content, signer identity attributes or diagnostics; proof timing values and status endpoints are classified separately because they can themselves disclose controller information.", "Rejected an attractive but unsupported signature-revocation primitive. No cited standard defines revocation of a signature; revocation attaches to certificates and keys, so the model records governance-state invalidation plus references to external revocation evidence, and this limitation is recorded as a conflict rather than papered over.", "Rejected a local legal-validity flag. Legal effect under a qualified regime is jurisdictional and assessed externally, so only a pinned regime reference with jurisdiction code and effective interval is held, and a dedicated policy forbids deriving a validity conclusion from it.", "Checked that no bundle reproduces an audit trail. Review and approval records hold decision evidence and an audit entry reference only; audit capture, storage, tamper-evidence and audit retention are assigned to the audit model, and the access requirements state that nothing here extends or asserts audit retention.", "Checked that the compromise finding does not annex incident response. Declarations are issued externally, revocation and key destruction are executed by the key and PKI models, and this model records the reference, the frozen scope, the required actions with their owning models and the outcomes those models reported.", "Checked that the change-control layer does not annex key rotation or policy authoring. The change function records an approved decision and its obligations, with policy authoring assigned to the signature-policy authority and key rotation to the cryptographic custodian in the key model.", "Does any part of this delivery claim ownership of a target model's execution? Every bundle, layer, finding and function was reviewed against each relation rationale. The time-discipline finding was made inline-only precisely to avoid minting a local copy of an authority's time assertion; the access finding was made inline-only to avoid creating a grant or usage record and thereby acquiring evaluation, enforcement or audit-trail semantics; the disposition function issues an instruction and explicitly forbids deleting externally owned evidence; and the canonicalization function is scoped to this model's own record with an explicit prohibition on recomputing cryptosuite or envelope transformations.", "Could a reader mistake this for a verification service? The functions were deliberately named and scoped so that none verifies a signature, checks a certificate, evaluates a policy or accepts a proof. The strongest counterexample considered was digest computation, which is retained only for the model's own record integrity and byte-fidelity checking, never as a step in proof verification, and the acceptance decision is repeatedly assigned outward on the authority of the primary sources that state algorithm acceptability is an application decision.", "Is any structural node presented as canonical without primary support? Every bundle, layer, finding, function and composition link cites at least one live primary source. The two structures that would have been most attractive to assert — a normative validation status vocabulary and a legal qualification framework — were deliberately not built, because their primary texts could not be retrieved; they are recorded as evidence gaps and referenced outward instead.", "Would the identity ladder survive a hostile reading? It was tested against the values most often misused as identifiers in this domain: a key identifier is a hint by specification, a digest binds immutable content rather than naming a thing, an authority serial number is unique only within its issuer and is therefore qualified, and file names and timestamps are excluded outright. A Dimension-minted identifier is admitted only at the last rung and is marked local so it cannot leak back as authoritative.", "Does the model assume any storage or interface? It was stress-tested against version-controlled files, plain files, a document database, a tool interface and embedded signature carriage. Each is required to publish a loss report and to point back to the canonical form, and the bootstrap contract itself is defined as a record whose file name is a projection convention rather than its identity, so the contract holds where no file system exists.", "Are the failure paths actually closed? Unresolved bootstrap references, canonicalization aborts, digest mismatches, unrecognized critical parameters, failed change-set preconditions and missing scope classifications were each traced. Each halts or withholds rather than degrading, and substitution of cached, inferred or default values is prohibited explicitly rather than left to implementer discretion.", "Does any bundle, layer, finding or function claim ownership of a referenced target's semantics? Checked against every composition rationale: verification consumes an external evaluator's reported outcomes rather than executing cryptography; policy is pinned by reference rather than authored or enforced; holds and retention schedules are mirrored read-only; audit emission requirements are stated but the audit trail is not constructed or retained; deletion is reported as readiness and executed elsewhere. The evidence-registration function was the closest call and is constrained to recording an externally produced unit with byte-level additivity checks.", "Could a consumer derive a bare pass or fail from this structure and circulate it without its inputs? Blocked at three points: dimension results are inline on the run record rather than a standalone artifact, report projections must carry the pinned inputs and the run identifier to be self-describing, and a boolean request is refused with the dimension set. The residual risk is a downstream system that flattens the projection anyway, which the model can detect only through the input digest.", "Does adding preservation evidence or running a later verification ever mutate history? No operation updates a stored verdict, a pinned input set or received bytes; corrections are superseding records; comparison records add interpretation and explicitly do not retract the earlier verdict; renewal assessments are recomputed rather than patched. Fixity is re-checked before every read that feeds an operation.", "Is any date, digest or verdict value used as an identifier? Identity priority names the master-system identifier first and explicitly demotes digests to fixity and excludes dates; serial naming forbids dates, verdict values and status words; sequence numbers are declared to convey order only. No local identifier in this model contains a date-like component.", "Does export leak by default? Payload and identity disclosure are separately authorised, deny-by-default applies per facet, unsupported critical semantics cause refusal rather than silent downgrade, and every export carries a fixed statement that presence implies nothing about verification. The known weakness is that a recipient may still present the export as validated, which is why any verdict must travel as a referenced run record.", "Is the structure falsifiable? Two dimensions are recorded as genuine gaps (post-quantum hybrid composition, non-cryptographic and hardware-attested proof forms), two ETSI preservation specifications could not be machine-retrieved and are therefore treated as alignment targets rather than clause-level support, and five standing conflicts between source regimes are recorded rather than reconciled.", "Does any element assert that a successful cryptographic check establishes authorization, approval or legal effect? Checked: the asserted-property finding requires a per-property basis and an explicit non-asserted list, and a standing policy forbids such inference. No function outputs an acceptance decision.", "Does any function perform verification, evaluate policy, enforce an outcome or constitute an audit trail? Checked: the outcome-recording function states that it performs no cryptographic operation, applies no policy and makes no acceptance decision, and audit requirements route records to a referenced audit model that owns audit-trail semantics.", "Is private key or activation material reachable anywhere in the model? Checked: no data element accepts secret material, creation rejects such inputs, and an explicit policy plus a security-event audit requirement cover attempted submissions.", "Is any timestamp used as an identifier, a sort key implying evidential order, or a component of a serial name? Checked: the identity priority bars dates and digests from designating records, the serial naming rule forbids date components, and order evidence is asked for separately from any signer-supplied time.", "Are MACs, unkeyed digests, seals, time-stamp tokens and selective-disclosure proofs silently treated as digital signatures? Checked: an explicit kind code with an origination-capability field is mandatory, boundary notes distinguish each neighbour, and a policy forbids normalisation.", "Could a consumer read a proof record and infer validity by default? Checked: read rules force return of the status with its evaluation instant and reliance limit, absent status means not verified, and unverifiable material is returned with a reliance block.", "Does the structure duplicate credential, certificate, trust-list or validation-report content? Checked: the verification-method finding and the status finding both carry references only and state inline-only rationales explaining why no artifact is materialised; the only two artifacts are the serialized proof itself and a composition manifest, both of which are proof-owned.", "Does any bundle, layer or finding reproduce a referenced model's lifecycle or operational functions? Checked against every composition link: key rotation and revocation, credential issuance and status, trust-anchor management, policy evaluation, enforcement, audit retention and legal determination all appear only as out-of-scope entries, boundary notes or reference links, never as local findings or functions.", "Attempted to make one syntax canonical for all subjects: rejected. The primary sources define mutually incompatible ordering, escaping and duplicate-key rules, so each declaration names the rule set it selects and the incompatibilities are recorded as conflicts rather than reconciled.", "Attempted to model signature computation, key resolution and trust evaluation: rejected and relocated to boundary notes and composition references, because protected-bytes derivation completes before any signature is computed or checked.", "Attempted to own enforcement of fail-closed handling for unknown critical transforms: rejected. The model declares criticality and the required disposition; refusal, evaluation, complexity-limit application and audit-trail storage are executed by referenced models, and every function's effects were rewritten to say so.", "Attempted to use a digest value as the record identifier: rejected, because content addressing collapses distinct derivations that happen to produce identical bytes and destroys the supersession chain. The digest is retained as a secondary content address only.", "Searched for a counterexample to treating an absent step as equivalent to an identity step: found one in XML Signature reference processing, where an octet stream with no Transforms is digested directly while a declared canonicalization step converts a node-set to octets. The two are therefore modelled as distinct enumerated values in both directions.", "Tested whether a chain manifest alone guarantees reproducibility: it does not. Canonical XML 2.0 shows one algorithm URI governing four parameters with documented defaults, and RDFC-1.0 requires the internal hash algorithm to be expressed unequivocally, so an implementation pin and an independent recomputation are required as separate evidence.", "Checked whether recording the pre-transform representation duplicates payload ownership: it would. Only a reference and digest are held here, custody stays with the payload model, and its destruction is recorded as an annotation that invalidates the coverage claim rather than as a deletion this model performs.", "Checked whether an inclusion-list formulation of coverage would be simpler: rejected, because the exclusion-list pattern was adopted specifically to prevent content being added to an asset without altering the binding, and the simpler formulation reintroduces that attack.", "Reviewed whether declaring a threat-posture artifact would create a shadow policy surface: it would, so the threat-posture finding is inline-only and is consumed by the models that own evaluation and enforcement." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Record_plane='world-model' and entry_kind='mixin' are already correctly separated in the frozen registry entry -- no record-plane label such as 'standalone-mm' is being mistaken for the subject-model kind here. Testing entry_kind against the alternatives: 'entity' fails because the record is explicitly and repeatedly defined as bound to exactly one host it disclaims owning (sig-core-find-proof-record-identity: 'a proof is an identified value bound to exactly one host representation'); 'aggregate' fails for the same reason, since aggregates are self-standing consistency boundaries and this record cannot exist or be created independent of its host; 'relationship' fails because the structure is far richer than a thin edge-type record, carrying its own governance, verdict semantics, and durable-evidence lifecycle. 'Mixin' matches the purpose statement's own language ('a reusable, format-neutral mixin for attaching digital signatures ... to any host record') and the out-of-scope exclusion of host content, party records and credentials. No reclassification, split or merge is warranted; status is accepted." }, "decisions": [ { "concept": "Entry-kind classification", "disposition": "Accepted as mixin (no reclassification)", "rationale": "Tested against 'entity', 'aggregate' and 'relationship' alternatives; each fails because the record is explicitly and repeatedly bound to exactly one host it disclaims owning, matching mixin semantics rather than a standalone lifecycle object or a thin edge-type relationship." }, { "concept": "Aggregate root", "disposition": "Accepted -- no single root required", "rationale": "25 peer bundles orbit the proof record without a declared aggregate root; sig-core-find-proof-record-identity is the closest conceptual anchor, consistent with a mixin that attaches to an externally-owned host aggregate rather than constituting one itself." }, { "concept": "Parent relation to WM-XCT-006", "disposition": "Deferred, not accepted or severed", "rationale": "The registry record asserts parent_ids=WM-XCT-006 but the frozen relationship contract is empty and no WM-XCT-006 content was supplied; the model's own known_omissions already flags this as unverified, so the edge must stay unadjudicated until checked." }, { "concept": "Ownership boundary / out-of-scope list", "disposition": "Accepted as declared", "rationale": "Fourteen out-of-scope entries and nine boundary_notes distinguish MACs, digests, timestamps, seals, certificates/VCs, validation policy, SD-JWT and legal-effect determination from this proof mixin, each backed by a cited source and echoed by repeated adversarial ownership checks." }, { "concept": "Internal composition relations (co-sign, countersign, threshold)", "disposition": "Accepted", "rationale": "Independent co-signatures and dependency-bound countersignatures are kept structurally separate with distinct binding-strength semantics sourced to RFC 9338 and RFC 5652 versus Data Integrity chaining, and are stress-tested by dedicated chain-collapse and threshold-inflation adversarial checks." }, { "concept": "Source support for European trust-service claims", "disposition": "Accepted with mandatory re-verification hold", "rationale": "ETSI EN 319 102-1, TS 119 172-1, TS 119 612/615, EN 319 122/132/142-1, TS 119 182-1, ISO 32000-2 and the EUR-Lex consolidated eIDAS text all returned HTTP 403 or empty content during research and rest on secondary European Commission DSS corroboration only." }, { "concept": "Retention and disposition ownership", "disposition": "Accepted as declared", "rationale": "Retention schedules, legal holds and physical deletion are consistently delegated by reference to external retention and storage systems in both the dedicated finding and the crud.delete rule set, leaving only minimal tombstones locally, with no internal contradiction found." }, { "concept": "Access and disclosure model", "disposition": "Accepted as declared", "rationale": "The service-layer access section applies deny-by-default across bundle/layer/finding/artifact scopes with six independently granted disclosure classes and time-boxed exceptions, and the payload-versus-verifiability non-implication rule is directly adversarially tested." }, { "concept": "Artifact identity priority ladder", "disposition": "Accepted as declared", "rationale": "The master-system-id, governed-IRI, Dimension-minted-ULID ladder explicitly bars dates, digests, serials and filenames from serving as identity and is applied uniformly across roughly seventy artifacts, with multiple dedicated adversarial checks re-testing the exclusion." }, { "concept": "Verification/verdict execution boundary", "disposition": "Accepted as declared", "rationale": "Every verification-facing function states it performs no cryptographic operation, evaluation or enforcement and records only externally produced outcomes, matching the top-level 'describe, never execute' policy and its per-bundle ownership adversarial checks." }, { "concept": "Post-quantum / hybrid composition gap", "disposition": "Deferred to a future revision", "rationale": "Hybrid and composite post-quantum proof composition and non-cryptographic proof forms are explicitly excluded for lack of a stable primary source, which is an appropriate scope limit today but should be revisited once NIST IR 8547 and the LAMPS composite-signature draft finalize." }, { "concept": "Single-provider structural corroboration", "disposition": "Accepted with visible single-provider hold", "rationale": "The roughly one-hundred-entry self-authored adversarial_checks list is internally consistent but was produced by the same provider under audit, so it narrows but cannot close the gap left by the owner-authorized absence of independent second-provider review." } ], "publicationHolds": [ "Hold pending live re-verification of ETSI EN 319 102-1, TS 119 172-1, TS 119 612/615, EN 319 122/132/142-1, TS 119 182-1, ISO 32000-2 and the EUR-Lex consolidated eIDAS text, all of which could not be fetched live during research and rest only on secondary European Commission DSS documentation or UK-retained legislation text.", "Hold to disclose the owner-authorized absence of independent second-provider review: Grok was waived by the repository owner on 2026-08-29 after repeated structured-output failures, so this draft carries no cross-provider structural or factual corroboration.", "Hold on the unverified parent linkage to WM-XCT-006: the registry record asserts parent_ids=WM-XCT-006 while the frozen relationship contract is empty, so this composition edge must not be presented as adjudicated until WM-XCT-006 is resolved and cross-checked.", "Hold reflecting registry review_state 'boundary-review-required' and status 'candidate': this record must be labelled a reviewable draft, not a finalized model, until the registry-level boundary review this audit feeds into is formally closed.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Locate or draft the WM-XCT-006 specification, verify its semantics against WM-XCT-034's proof-mixin boundary, and add a formally adjudicated entry to the relationship contract instead of relying on the registry's unverified parent_ids field.", "Re-attempt live retrieval of the ETSI and ISO deliverables that returned HTTP 403 in this pass and reconcile any clause-level divergence from the European Commission DSS secondary documentation currently used as a substitute.", "Track NIST IR 8547 and the IETF LAMPS composite-signature draft to final status and extend the model with first-class post-quantum hybrid and composite proof-composition semantics once those sources leave draft state.", "Schedule an independent second-provider or human structural audit once the Grok waiver is lifted, to cross-check the large self-authored adversarial_checks list that currently supplies the only boundary corroboration available." ] }, "statistics": { "sources": 98, "bundles": 25, "layers": 54, "findings": 112, "questions": 504, "artifacts": 72, "functions": 90 } }