Conformance

Implementation and conformance status

Document 1.0-draft-1 publishes complete contracts for its declared v1 scope. No recipient service or conformance certification is claimed.

The conformance manifest has stable IDs, expected behaviours, capability dependencies and explicit pending runtime evidence. Each check records runtime_evidence (library where executable library tests cover the requirement as stated; integration where the reference implementation's integration tests, which run its provider against real storage, cover every duty the requirement places on a provider that one provider's own tests can show, while any part that falls to a verifier keeps its library tests or published test vectors and any part one provider cannot show is named below; otherwise pending) and pending_phase, the build phase that supplies its runtime evidence, or, for a check with integration evidence, the phase whose integration tests supplied it. Integration evidence shows that the reference provider meets those duties; it is not a suite another implementation can run against its own service. Library and integration evidence both come from the reference repository's own tests: neither is evidence gathered from a running service, which no check has yet (below). A check that the published test vectors evidence also lists their files in vectors. The SCOPE, ID and VOCAB-1.1 families are listed in the manifest with their library evidence; they belong to no capability profile. WILDCARD-01 checks a recommendation (A15.1) and belongs to no capability profile either. The optional features public-handles (HANDLE-01), encrypted-export (ENCRYPT-01) and pdpp-binding (BINDING-01) apply only to a provider that offers them, as advertising does (A17.1). Test names in the reference repository follow the convention below. SCOPE-01 to SCOPE-10 and ID-01 to ID-05 remain syntax/identifier checks, not grant or recipient certification.

The reference repository names each library or integration test by the check it evidences, and a suffix on the check ID says what kind of evidence the test gives:

• -SCHEMA: a test of a schema or a pure helper that covers only part of the check's requirement.
• -COMPILER: an example test of the pure compiler at the library boundary.
• -PROPERTY: a property checked across many inputs, either by fast-check with a fixed seed and run count, so that a failure replays exactly, or by an exhaustive pass over every published vocabulary key.
• -VERIFIER: a test of the verifier's side of a check whose remaining duties belong to a running provider, as for KEY-01.
• -SIGNER: a test of the signing side of a check at the library boundary: what the reference signer writes verifies with the reference verifier and has the published test vectors' exact header and payload bytes for the same key and type. It is not runtime evidence: key custody, rotation and signing inside a provider's transactions are shown by -STORE tests or a running provider.
• -STORE: an integration test of one of the reference provider's stores, such as its signing key store or its pairwise handle store, run against a real database, with real concurrency where the requirement concerns it. When such tests cover every duty a check's requirement places on a provider that one provider's tests can show, the check records integration evidence.
• -CHAIN: a test of the reference provider's owner log, either without a database or against a real database: appending each event's exact bytes in order, and verifying a partition's chain over its stored rows and over its exported form. A further word names what the test shows, such as -CHAIN-TAMPER (edits to the stored chain are reported at the first divergence), -CHAIN-CONCURRENCY, -CHAIN-VECTORS (the published receipt chain is reproduced) or -CHAIN-SCALE, a timing guard on verification that, like -BENCHMARK, is not conformance evidence. It is not runtime evidence: LOG-01 and LOG-02 also require the disclosure transaction and the owner's export.
• -BENCHMARK: a timing guard on the compiler against a median budget. It is not conformance evidence.

A test with no suffix, such as those named SIGN-01 or SCOPE-01, is named by its check alone; the tests of the published test vectors, for example, carry the bare check ID. A test may name more than one check. A suffix describes a test, not a check: whether library or integration tests cover a check's requirement is recorded only by the check's runtime_evidence. Some repository tests carry IDs that are not in the manifest: those that check the shape of the generated contracts, examples and entry validation, and those for the reference server's operational surface, its application shell, the contracts of its internal ports and those of its record store that no check names, whose names can look like a check ID with a suffix, listed above or not. They are implementation tests, not conformance checks, and evidence no check. A record store test named by a check ID with the -STORE suffix is a -STORE test of that check.

Every sentence of the normative pages (core/, bindings/ and the vocabulary page) that carries MUST, MUST NOT, SHOULD or SHOULD NOT, every requirement they state in the imperative, and every sentence that uses a lower-case must or should, has an entry in statements.json: the checks that test it, or the reason no suite can, such as an organisational obligation or a sentence that only restates another. The items of a list introduced by an imperative ending in a colon, such as the A5.4 rejection list, count as imperatives. Some requirements stated without a modal, such as the A5.4 key, key-set and instant rules, the A9 canonical request and the A10 acknowledgement bytes, also have hand-chosen entries of kind declarative. No such sentence needs one, so the audit does not show that every requirement without a modal is covered; but a declarative entry must still quote its sentence, and a sentence the audit extracts takes the extracted kind. pnpm check:statements fails when a sentence has no entry, an entry no longer matches the text, or an entry names a check that is not in the manifest or not cited by its page. Runtime checks are pending because no recipient endpoint exists; this is not an exception permitting weaker behaviour. A release must supply real authentication, storage, concurrency, cryptographic and cross-surface evidence, with failures reported as expected versus observed. No logo or badge substitutes for that evidence.

The test vectors are fixed bytes an implementation can check offline: synthetic keys, canonical JSON, a signed disclosure, a receipt chain across a key rotation, a purge instruction and acknowledgement, and the signed objects a verifier must reject. They evidence a verifier's side of SIGN-01, KEY-01, LOG-01, LOG-02 and PURGE-01: rejecting the failures A5.4 lists for the objects they cover, verifying a receipt signed before a rotation from the published key set alone, recomputing the receipt hash chain and checking an acknowledgement's signed bytes. They are not runtime evidence. KEY-01's verifier rejections have published vectors, but never reusing a key ID, never sharing a key with another provider, signing nothing at or after a key's exp, and keeping a retired key published with an unchanged exp are a provider's duties, shown by a running key store: the reference implementation shows them with -STORE tests of its key store against a real database, its integration evidence, which also covers a provider whose issuer changes: its earlier issuer's retired keys stay in the key set it publishes, with their exp. That evidence does not cover the rest of KEY-01's statements: a verifier's rejections, evidenced by the -VERIFIER tests and the vectors; a key set served at a discovery jwks_uri, and keys a recipient registers, which need a running service; and the keys of any other provider. One provider's tests cannot show that no other provider holds the same key. They show that its keys are generated by the provider itself from a cryptographically secure random source, are never imported, and differ between independent installations; the rest depends on every provider keeping its private keys to itself and on verifiers trusting only the key set configured for each issuer (A5.4).

VOCAB-1.1-01 to VOCAB-1.1-09 exercise the approved pilot additions, version metadata, explicit grant/recipient vocabulary intersection, text/enum validation, renderings, inference restrictions, grant isolation, temporal overlays and unavailable-key deadline isolation. Library checks do not establish runtime negotiation or stored consent evidence. The original 27 keys remain available under vocabulary 1.0; all 30 are tested under 1.1.

The conformance manifest

Every capability, optional feature and check in the conformance manifest of edition 1.0-draft-1, generated from that file. Nothing is certified, and no implementation is claimed to pass any check. The statement audit maps every sentence of the normative pages that carries MUST or SHOULD, states a requirement in the imperative or uses a lower-case must or should to the checks below, or to the reason no suite can test it.

Provider capabilities

Recipient capabilities

Optional features

An optional feature applies only to a provider that offers it (A17.1).

Every check

60 checks. Library tests means executable library tests cover the requirement as stated. Integration tests means the reference implementation's integration tests, which run its provider against real storage, cover every duty the requirement places on a provider that one provider's own tests can show, while any part that falls to a verifier keeps its library tests or test vectors; they show the reference provider meets those duties and are not a suite another implementation can run. Pending means neither yet. Library and integration tests are the reference repository's own tests, not evidence gathered from a running service, which no check has yet. Test vectors are the published vector files that evidence a verifier's side of a check. They are not runtime evidence, so a check with vectors can still be pending. The keys in keys.json are synthetic and published with their private parts; never trust them, or anything they sign, anywhere else.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.