A17. Conformance and change process
Status: normative. Document version 1.0-draft-1.
A17.1 Provider and recipient roles
The conformance manifest defines exact required check groups and dependencies. Shared security, data-minimisation and A16 deployment requirements apply to every claimed capability. PRIVACY-01 to PRIVACY-06 require operational evidence for the deployment's stated jurisdictions and uses; passing them is not a legal compliance certificate.
| Role | Capability | Required behaviour |
|---|---|---|
| Provider | Core | Pairwise identity, typed record, temporal compiler, consent, one or both public surfaces, receipts, revocation and purge |
| Provider | Write | Core plus separate contributions, protected confirmation and correction/replay handling |
| Provider | Portable | Core plus export and import, preservation/unsupported reporting and migration without authority transfer |
| Provider | Delegated | Core plus bounded standing rules and one-use target-bound grant offers |
| Recipient | Read | Correct grant use, signature/binding/expiry verification, permitted retention and purge |
| Recipient | Contribute | Separate contribution authority, provenance, retries and own-event correction/withdrawal |
| Recipient | Reciprocal | Read and Contribute plus inbound/outbound transfer for the same stated categories |
Advertising is optional and additionally requires ADS-01 and ADS-02. In the same way, a provider that offers public handles additionally requires HANDLE-01, one that offers the A11.2 encrypted export requires ENCRYPT-01, and one that offers the B1 binding requires BINDING-01. WILDCARD-01 checks the A15.1 recommendation; no capability requires it. Verified credential presentations, Trust registries and emergency cards are reserved, unclaimable v1 extensions. “Read” does not mean Portable. An export-only implementation cannot claim Portable or Reciprocal.
A17.2 Claims and evidence
Use capability-claim.json: role, wire/document version, capabilities, exact domain/key categories, directions, limitations, evidence URLs/timestamps and assurance:self-declared. Provider capability names and recipient capability names cannot be interchanged. Directions must match actual behaviour and the declared capabilities. A Read-only claim cannot advertise contribution or transfer. Every claimed direction has at least one supported category; categories may differ for reading and contribution. Portable/Reciprocal covers both export and import for every category named in that claim. Evidence identifies a reproducible test suite version, tested build and result for every required check.
The draft establishes no certification authority and issues no badges. Independent certification requires a separately published governance and assessment process. A self-declared implementation can accurately publish its evidence and limitations, but cannot say “certified” because its JSON parsed or because a provider supports a similar capability.
Contract checks in the reference repository validate schemas, vocabulary examples, scope syntax and selected pure policy invariants, and run example and property tests of the pure compiler. A library verifier in the same repository checks A5.4 detached signatures on disclosures, receipts, purge acknowledgements and exports. The published test vectors for disclosures, receipts and purge are checked by the repository's tests, which use that verifier for every detached signature among them, and independently by a second verifier written from the specification text alone with other libraries. A statement audit maps every normative sentence it extracts from the core, the bindings and the vocabulary page to the checks that test it, or to the reason no suite can. These checks do not exercise a running recipient service. Where a check's manifest entry records integration evidence, the reference implementation's integration tests, which run its provider against real storage, cover every duty the check's requirement places on a provider that one provider's own tests can show; a verifier's part of the requirement keeps the evidence of its own tests and vectors, and that shows the reference provider meets those duties, not that another implementation does. Full runtime checks in the manifest remain pending and must pass before a conforming implementation is claimed. Failure reports must identify check ID, expected behaviour and observed behaviour without exposing personal values.
A17.3 Changes
Document version 1.0-draft-1 is distinct from proposed wire version 1.0. After wire release, breaking changes require a new version/URL prefix, an ADR, migration guidance and explicit approval. Additive core keys require full value/rendering definitions, sensitivity review, examples and conformance coverage. Unknown keys stay rejected until the new vocabulary version is negotiated.
A17.4 describes review, compatibility and published editions.
A17.4 Versioning and editions
The current document version is 1.0-draft-1; the proposed wire version is 1.0. Document versions identify editions of the specification. Wire versions identify the protocol used by compatible implementations.
Draft status
The draft is open to review and interoperability testing. Published requirements and implementation status are separate: the implementation and conformance status records which contracts have executable checks and which service capabilities remain in development.
Reviewing changes
Changes are reviewed with their effects on privacy, consent, security and compatibility. A protocol change includes the corresponding normative text, schemas, examples and conformance requirements. Implementations follow the requirements for the version they claim.
New vocabulary keys need a complete value definition, supported disclosure levels, rendering rules, sensitivity review, examples and conformance coverage. Keys remain unavailable until their vocabulary version is supported and negotiated.
Compatibility
After the wire protocol is released, breaking changes require a new wire version and URL prefix, an approved architecture decision record and migration guidance. Additive changes retain existing consent and disclosure limits. Reserved extensions need their own complete contracts and evidence before implementations can claim support.
Published editions
Each edition includes the specification text, machine-readable contracts, examples and conformance requirements. Downloadable bundles include a source revision and checksums so implementations can identify the exact edition they use.
A17.5 Capability claims and acceptance
A17 defines provider Core/Write/Portable/Delegated separately from recipient Read/Contribute/Reciprocal. Discovery identifies role, version, exact categories, directions, evidence and limitations. Version 1 assurance is self-declared; there is no issued certification or badge. No export means no full portability claim.
Checks for A17.5 and the requirements first published as A18: CONSENT-01, ADS-01/02, TEMP-01/02/03, CONTRIB-01/02/03, PORT-01 and CLAIM-01 in the conformance manifest. SCOPE-10 and structural/pure policy tests execute now; service authorisation, temporal selection, cryptography, transactions and integrations remain implementation gates.
A17.6 Self-declaration and reserved capabilities
For v1, capability discovery uses capability-claim.json and explicitly states assurance:self-declared, role, protocol/document version, data categories, directions, limitations and test evidence. A provider must not turn self-declaration into a verified/certified badge or trusted client class. No v1 tier can be purchased or inferred from passing a structural schema check. Registry tiers, signed registry attestations, registry-mediated governance and emergency cards are reserved for a later version; see the placeholders for A12 and A13.
An implementation offering a separate experimental emergency card must clearly distinguish it from v1 conformance. Offline scans cannot reliably be logged or remotely revoked, and the person must be told before creating one. Never label an offline disclosure as a logged Autonym read or make an emergency-care reliability claim from this protocol.
Checks: CLAIM-01 and all checks required by the declared capabilities.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.