Implementation Profiles Registry
ACDP implementation profile identifiers used in capabilities.profiles. Identifiers are lowercase ASCII matching ^acdp-[a-z][a-z0-9-]*$.
The schema vocabulary is open. Profiles are normatively defined in RFC-ACDP-0001 §9.1.
Registered values
| Identifier | Status | Reference | Prerequisite |
|---|---|---|---|
acdp-registry-core | Mandatory for any registry | RFC-ACDP-0001 §9.1 | — |
acdp-registry-discovery | Optional | RFC-ACDP-0001 §9.1 | acdp-registry-core |
acdp-registry-federated | Optional | RFC-ACDP-0001 §9.1 | acdp-registry-core |
acdp-registry-receipts | Optional (0.2.0, Final) | RFC-ACDP-0010 §11, RFC-ACDP-0001 §9.1 | acdp-registry-core, acdp_version ≥ 0.2.0 |
acdp-registry-head-receipts | Optional (0.3.0, Final) | RFC-ACDP-0011 §9, RFC-ACDP-0001 §9.1 | acdp-registry-receipts, acdp_version ≥ 0.3.0 |
acdp-registry-transparency-log | Optional (0.3.0, Final) | RFC-ACDP-0012 §11, RFC-ACDP-0001 §9.1 | acdp-registry-receipts, acdp_version ≥ 0.3.0 |
acdp-registry-lifecycle | Optional (0.3.0, Final) | RFC-ACDP-0013 §10, RFC-ACDP-0001 §9.1 | acdp-registry-core, acdp_version ≥ 0.3.0 |
acdp-log-witness | Optional (0.4.0, Draft) | RFC-ACDP-0015 §10, RFC-ACDP-0001 §9.1 | — (a witness is not a registry), acdp_version ≥ 0.4.0 |
acdp-consumer | For consumer deployments | RFC-ACDP-0001 §9.1 | — |
(RFC-ACDP-0014, the producer key-revocation signal, deliberately defines no profile: a revocation is an ordinary context carried by existing surfaces; its registry-side validation binds to acdp_version ≥ 0.3.0 and its consumer semantics to acdp-consumer — RFC-ACDP-0014 §10.)
Conformance manifests
Each profile pins a concrete set of HTTP endpoints and conformance fixtures. The columns below are normative for v0.1.0 implementers — passing the listed fixtures is necessary (but not sufficient) for claiming conformance with the corresponding profile.
A machine-readable form of the same manifest is published as profiles.json. Conformance runners and language implementations SHOULD prefer the JSON form for fixture selection; the table here is the human-readable index. When the two diverge, the table here is authoritative — implementers SHOULD open an issue against the JSON document.
acdp-registry-core
| Required | |
|---|---|
| HTTP endpoints | POST /contexts (RFC-ACDP-0003 §2), GET /contexts/{ctx_id} (RFC-ACDP-0004 §2.1), GET /contexts/{ctx_id}/body (RFC-ACDP-0004 §2.2), GET /lineages/{lineage_id} (RFC-ACDP-0004 §5.1), GET /lineages/{lineage_id}/current (RFC-ACDP-0004 §5.2), GET /.well-known/acdp.json (RFC-ACDP-0007 §3) |
| Conformance fixtures | can-001..can-012 (canonicalization, including registry-side timestamp emission per RFC-ACDP-0001 §5.3, forward-compat hash verification per §5.7, DataRef-level openness in can-010 per RFC-ACDP-0002 §6.7, RFC 8785 §3.2.2.3 numeric-serialization vectors in can-011 per RFC-ACDP-0001 §5.2, and the 0.2.0 divergence-corpus vectors in can-012 — acdp_version omitted/explicit, microsecond timestamps, null-vs-absent-vs-empty — per RFC-ACDP-0001 §6 and Appendix A), lin-001 (lineage_id derivation golden vector per RFC-ACDP-0001 §5.6), sig-001 (Ed25519 golden), sig-002 (ECDSA-P256 golden, REQUIRED only if registry advertises ecdsa-p256 in supported_signature_algorithms), sig-003 + dk-001/dk-002/dk-004 (did:key golden + rejection scenarios, REQUIRED only if the registry advertises did:key in supported_did_methods — RFC-ACDP-0001 §5.11.1, 0.2.0), dk-003 (key_resolution_failed rejection of did:key publishes, REQUIRED for 0.2.0 registries that do NOT advertise did:key — RFC-ACDP-0007 §3.1), pub-001..pub-014 (publish flow, including DID method scope per RFC-ACDP-0001 §5.4, persist-only-after-signature-verify atomicity per RFC-ACDP-0003 §2.1 in pub-011, and closed-schema rejections per RFC-ACDP-0003 §2.1 step 1 in pub-012..014), data-ref-001..data-ref-007 (DataRef validation, including the DataRef-level data_ref_hash_mismatch code in data-ref-007 per RFC-ACDP-0007 §5), did-ssrf-001..did-ssrf-005 (producer DID resolution SSRF refusal at publish-time signature verification per RFC-ACDP-0008 §4.8 — loopback, IMDS, private-range, mixed-answer, and same-host-different-port redirect refusal), meta-001..meta-003 (metadata limits), body-001..body-002 (origin_registry hostname-vs-DID per RFC-ACDP-0002 §3.1), ret-001, ret-002 (retrieval, including GET /lineages/{id}/current all-superseded / expired-head semantics per RFC-ACDP-0004 §5.2), vis-001 (restricted retrieval), vis-004, vis-005 (private + audience search-vs-retrieval asymmetry per RFC-ACDP-0008 §4.5), vis-008 (lineage endpoint visibility per RFC-ACDP-0004 §5.4), err-001 (error envelope), caps-001..caps-007 (capabilities validation per RFC-ACDP-0007 §3.5; (0.3.0) caps-007 pins the OPTIONAL limits.max_publish_per_minute field — integer ≥ 1, advisory pacing ceiling per RFC-ACDP-0008 §4.3, never a relaxation of the rate-limiting MUSTs), status-001..status-004 (registry-state status pattern), schema-002, schema-003, schema-008..schema-012, schema-014 (closed-schema rejections — publish/embedded/signature/data_period/capabilities-limits — plus the absent-vs-null rejections for DataRef.format / DataRef.location per RFC-ACDP-0002 §6.8 and capabilities.limits.idempotency_key_ttl_seconds; schema-001, schema-004..schema-007, and schema-013 are profile-scoped — see discovery and consumer rows), rate-001 (rate-limit response shape; see note below). When supports_idempotency_key: true is advertised in capabilities, idem-001..idem-005 are additionally REQUIRED (idem-006 describes a tolerated race outcome — see fixture). (0.3.0) A registry advertising acdp_version ≥ 0.3.0 MUST support Idempotency-Key (RFC-ACDP-0003 §6.4): supports_idempotency_key MUST be advertised true (so idem-001..idem-005 are unconditionally REQUIRED for it), the §6.2.2 atomic storage contract (UNIQUE(agent_id, idempotency_key) with transactional insert) MUST be implemented, and the §6 TTL bounds MUST be enforced; idem-007 pins the capabilities-level rejection of a 0.3.0-advertising document with supports_idempotency_key absent or false. Registries advertising 0.1.0/0.2.0 are unchanged. |
not_implemented permitted on | GET /contexts/search (registry MAY return 501 if acdp-registry-discovery is not advertised); cross-registry resolution endpoints are not part of v0.1.0 protocol surface and are NOT addressable by not_implemented |
Rate-limit conformance note (rate-001). The fixture pins the wire shape (HTTP 429, application/acdp+json body with error.code = "rate_limited", and a mandatory Retry-After header per RFC-ACDP-0008 §4.3 — a limiter without an exact refill horizon emits a conservative estimate rather than omitting it). It is informative for cross-impl wire compatibility, but black-box conformance testing cannot deterministically trigger a per-agent rate limit without registry-side cooperation. Implementers MUST self-test by configuring a known per-agent rate and verifying the response shape per the recipe in schemas/conformance/rate-001-rate-limited-response-shape.json.
acdp-registry-discovery
Adds keyword search.
Required (in addition to acdp-registry-core) | |
|---|---|
| HTTP endpoints | GET /contexts/search (RFC-ACDP-0005 §2) |
| Conformance fixtures | vis-002 (search visibility scoping), vis-003 (response field name matches), vis-005 (private + audience search exclusion per RFC-ACDP-0008 §4.5 / RFC-ACDP-0005 §2.5.5), vis-006 (visibility disclosure on public matches) and vis-007 (visibility absence on unauthorized restricted matches) per RFC-ACDP-0005 §2.2, vis-009 (anonymous_public_reads scoping of keyword search per RFC-ACDP-0005 §2.5.5), schema-001 (closed search-response, no results synonym), schema-005..schema-007 (absent-vs-null wire convention for next_cursor / summary / domain per RFC-ACDP-0005 §2.2.1), cur-001 (cursor_expired) and cur-002 (invalid_cursor) per RFC-ACDP-0005 §2.5.4 |
not_implemented permitted on | None — every endpoint listed above is mandatory once this profile is advertised |
acdp-registry-federated
Adds cross-registry resolution.
Required (in addition to acdp-registry-core) | |
|---|---|
| HTTP endpoints | None added — federation is not exposed as a new endpoint; the registry resolves acdp:// references in derived_from chains transparently while serving existing endpoints (RFC-ACDP-0006 §4) |
| Conformance fixtures | fed-001 (HTTPS-only refusal), fed-002 (RFC 1918 private-IP refusal), fed-003 (loopback refusal), fed-004 (link-local + IMDS refusal), fed-005 (cross-authority redirect refusal), fed-006 (registry_did ↔ authority binding), fed-007 (mixed-answer rejection — a DNS answer set mixing a public and a forbidden address MUST be rejected entirely; filter-and-proceed is non-conformant), fed-008 (same-host-different-port redirect refusal — authority is scheme + host + effective port), fed-010 (partial-walk reporting per RFC-ACDP-0006 §4.1 — a derived_from walk truncated by a traversal control (depth / total nodes / fanout / timeout) MUST carry an explicit truncation marker, e.g. complete: false, when surfaced as a partial result, and MUST NOT be presented as exhaustive; aborting with cross_registry_resolution_failed remains conformant) — covering RFC-ACDP-0006 §7.1, §7.2, §7.5, §4.1 step 3, and the §4.1 traversal controls. (0.2.0) fed-009 (upstream-receipt verification against the remote authority, invalid_receipt on failure — RFC-ACDP-0010 §11), REQUIRED when the registry also advertises acdp-registry-receipts or resolves from receipts-advertising upstreams. Response-size caps (§7.3), timeouts (§7.4), and DNS-rebinding pinning (§7.6) are operational requirements that registry implementers MUST self-test; they are not exposed as standalone fixtures because the protocol surface alone does not allow a black-box assertion (an external observer cannot distinguish "the registry pinned the IP for the connection lifetime" from "the second DNS lookup happened to return the same IP"). |
not_implemented permitted on | None |
acdp-registry-receipts (0.2.0)
Adds registry receipts (RFC-ACDP-0010).
Required (in addition to acdp-registry-core) | |
|---|---|
| HTTP endpoints | None added — receipts ride existing responses: the publish response (RFC-ACDP-0003 §4) and the full-retrieval envelope (RFC-ACDP-0004 §2.1) gain the registry_receipt member; the body-only endpoint stays receipt-free (RFC-ACDP-0010 §7) |
| Conformance fixtures | rcpt-001 (receipt golden vector — preimage canonical bytes, receipt hash, Ed25519 signature, producer key fingerprint; executed by scripts/conformance-runner.py), rcpt-002 (tampered created_at → verification fails), rcpt-003 (key_fingerprint ≠ resolved producer key), rcpt-004 (registry_did ≠ serving authority), fp-001 (RFC-ACDP-0010 §6 fingerprint encoding vectors, Ed25519 + P-256; executed), rot-001 (historically-authorized-with-receipt vs fail-closed-without-receipt — RFC-ACDP-0010 §10). When acdp-registry-federated is also advertised: fed-009. |
not_implemented permitted on | None |
Profile commitment. Advertising this profile is the RFC-ACDP-0010 §7 contract: mint atomically with persistence, always return the receipt (publish response + full retrieval), never on the body-only endpoint, no degraded mode, no receipt_unavailable. Requires acdp_version ≥ 0.2.0. The receipt-key lifecycle (retired keys stay in verificationMethod indefinitely; rotation removes from assertionMethod only — RFC-ACDP-0010 §9) is a self-test obligation: the protocol surface does not allow a black-box assertion over time.
acdp-registry-head-receipts (0.3.0)
Adds lineage-head receipts (RFC-ACDP-0011) — registry-signed serve-time attestations of the current lineage head.
Required (in addition to acdp-registry-receipts) | |
|---|---|
| HTTP endpoints | None added — head receipts ride the existing GET /lineages/{lineage_id}/current response (RFC-ACDP-0004 §5.2), which gains the REQUIRED top-level lineage_head_receipt member; full retrieval MAY carry one; the body-only endpoint stays receipt-free of every kind (RFC-ACDP-0011 §6) |
| Conformance fixtures | lhr-001 (head-receipt golden vector — preimage canonical bytes, receipt hash, Ed25519 signature under the shared registry receipt key; executed by scripts/conformance-runner.py), lhr-002 (receipt's head ≠ served response → reject), lhr-003 (registry_did ≠ serving authority), lhr-004 (future as_of beyond skew allowance → reject) |
not_implemented permitted on | None |
Profile commitment. Advertising this profile is the RFC-ACDP-0011 §6 contract: mint a fresh head receipt (registry response-time as_of, millisecond-truncated RFC 3339 UTC) on every GET /lineages/{lineage_id}/current response, under the same signing key, DID plumbing, and key lifecycle as acdp-registry-receipts (the prerequisite is load-bearing — there is no new key role). No degraded mode and no receipt_unavailable; no new wire error code (invalid_receipt is reused, RFC-ACDP-0011 §9). Requires acdp_version ≥ 0.3.0. The requester-relative visibility rule (the attested head is the newest non-superseded version the requester may retrieve — RFC-ACDP-0011 §4, RFC-ACDP-0004 §5.4) is a self-test obligation alongside vis-008.
acdp-registry-transparency-log (0.3.0)
Adds the registry transparency log (RFC-ACDP-0012) — a per-registry append-only Merkle tree over publish events, with signed checkpoints, inclusion proofs, and consistency proofs. Promotes the profile name reserved by RFC-ACDP-0009 §2.11.
Required (in addition to acdp-registry-receipts) | |
|---|---|
| HTTP endpoints | GET /log/checkpoint (current signed tree head), GET /log/proof (inclusion mode by ctx_id or leaf_index; consistency mode by first+second — both modes REQUIRED on the one reserved path, RFC-ACDP-0012 §8.2), GET /log/entries (leaf-hash enumeration for auditors; leaf bodies only where the requester is retrieval-authorized — RFC-ACDP-0012 §8.3). Full retrieval MAY additionally carry the top-level log_inclusion member (RFC-ACDP-0012 §10); the body-only endpoint and the publish response stay untouched |
| Conformance fixtures | log-001 (leaf-and-root golden vector — JCS leaf encodings, 0x00/0x01 domain-separated leaf and node hashes, five-leaf Merkle root, checkpoint signed with the shared registry receipt key, inclusion proof for leaf 0; executed by scripts/conformance-runner.py), log-002 (tampered inclusion_path → §9.1 fold ≠ root_hash → reject), log-003 (consistency proof between tree sizes 3 and 5, both checkpoints signed; executed), log-004 (checkpoint whose signature does not verify over the recomputed preimage → reject) |
not_implemented permitted on | None — all three /log/* endpoints are mandatory once this profile is advertised |
Profile commitment. Advertising this profile is the RFC-ACDP-0012 §7 contract: append the leaf atomically with publish persistence (body + receipt + leaf commit together), serve all three endpoints, no degraded mode and no log_unavailable. Checkpoints sign with the SAME registry receipt signing key, construction, and RFC-ACDP-0010 §9 key lifecycle as acdp-registry-receipts (the prerequisite is load-bearing twice: leaves bind receipt hashes, checkpoints reuse the receipt key). New wire error code invalid_log_proof (RFC-ACDP-0012 §11; registries/error-codes.md) for failing proofs/checkpoints — deliberately distinct from invalid_receipt. Requires acdp_version ≥ 0.3.0. log-001 and log-003 are executed arithmetically by the runner; log-002 and log-004 are behavioral. Append-only discipline over time and the log-instantiation reset rule (log_id change on catastrophic loss — RFC-ACDP-0012 §7.4) are self-test obligations: the protocol surface does not allow a black-box assertion over time.
acdp-registry-lifecycle (0.3.0)
Adds lifecycle events and retraction (RFC-ACDP-0013) — signed, append-only producer/registry withdrawal events; mark-not-delete.
Required (in addition to acdp-registry-core) | |
|---|---|
| HTTP endpoints | POST /contexts/{ctx_id}/retract and POST /contexts/{ctx_id}/republish (RFC-ACDP-0013 §6): visibility-first resolution, producer-signed event authentication (same agent_id rule as supersession), strict retracted/republished transition alternation |
| Conformance fixtures | lc-001 (retraction flow — retract → status: retracted, signed event appended, body still retrievable, default-search exclusion, status=retracted search inclusion, double-retract → invalid_lifecycle_transition 409, republish reversal with append-only history), lc-002 (body-mutation attempt via a lifecycle endpoint → immutable_field 400, distinct from schema_violation; actor/authentication failures), lc-003 (/current head semantics — a retracted version is never a head; all-superseded-or-retracted → not_found; recovery via supersession or republication; head-receipt interaction where advertised) |
not_implemented permitted on | None once advertised. Registries NOT advertising this profile MUST return not_implemented (501) on both endpoints and MUST NOT emit lifecycle_events, the retracted status, or the 0.3.0 lifecycle error codes |
Profile commitment. Advertising this profile is the RFC-ACDP-0013 contract: append-only lifecycle_events (never removed, reordered, or mutated — a self-test obligation, as the protocol surface allows no black-box assertion over time), the §7.2 status precedence (retracted > superseded > expired), retracted bodies retrievable forever (mark-not-delete — the body-only endpoint and its cache story are untouched), default-search exclusion of retracted contexts (with acdp-registry-discovery), head exclusion on /current (and, with acdp-registry-head-receipts, never minting a head receipt naming a retracted head). Requires acdp_version ≥ 0.3.0. Registry-initiated (policy/legal) events are recorded directly with actor = the registry DID; registries advertising acdp-registry-receipts MUST sign them (SHOULD with the receipt signing key — no new key role).
acdp-log-witness (0.4.0)
A witness for the RFC-ACDP-0012 transparency log (RFC-ACDP-0015) — an independent party that observes a registry's checkpoints, verifies consistency, and cosigns the ones it verifies. Promotes the profile name reserved by RFC-ACDP-0009 §2.12. A witness is not a registry: no publish surface, no receipts, no registry prerequisite; the profile is advertised in the witness capabilities document (RFC-ACDP-0015 §9).
| Required | |
|---|---|
| HTTP endpoints | SHOULD serve GET /log/witness (the witness's own cosignature history, OPTIONALLY filtered by ?log_id= — RFC-ACDP-0015 §6.2), and SHOULD serve /.well-known/acdp-witness.json (witness capabilities — RFC-ACDP-0015 §9). A witness has no publish endpoints |
| Behavioral requirements | Before cosigning: verify the RFC-ACDP-0012 §9.3 checkpoint signature AND a §9.2 consistency proof against the witness's retained head; MUST NOT cosign a checkpoint that fails consistency (RFC-ACDP-0015 §7); on failure, persist both checkpoints and the failing proof as evidence and SHOULD surface a non-cosigning status. Produce cosignatures per RFC-ACDP-0015 §4–§5: the closed acdp-log-cosignature object signed with the RFC-ACDP-0010 §5 construction, keyed by the witness's own assertionMethod key under the witness's DID, RFC-ACDP-0010 §9 key lifecycle |
| Conformance fixtures | wit-001 (cosignature golden vector under a distinct witness test keypair — seed 0x33, NOT the registry receipt key — over the log-001 checkpoint; executed by scripts/conformance-runner.py), wit-002 (consistency refusal — a witness MUST NOT cosign a size-5 root-rewrite against its retained log-003 size-3 head), wit-003 (two distinct witnesses cosign one checkpoint → 2-witnessed, RFC-ACDP-0015 §8; executed), wit-004 (cosignature signed by the wrong witness key → invalid_witness_cosignature) |
not_implemented permitted on | Not applicable — a witness runs no registry endpoints |
Profile commitment. Requires acdp_version ≥ 0.4.0. The witness signs cosignatures with its own key — the one construction in the trust arc that does not reuse the registry receipt key (RFC-ACDP-0015 §5). New wire error code invalid_witness_cosignature (RFC-ACDP-0015 §10; HTTP 502; registries/error-codes.md) for cosignatures failing the §8 verification procedure — deliberately distinct from invalid_log_proof (it indicts a witness's attestation, not the registry's log). wit-001 and wit-003 are executed arithmetically by the runner; wit-002 and wit-004 are behavioral. Retained-head consistency over time and evidence-on-failure are self-test obligations. Registries MAY aggregate cosignatures as the top-level witness_signatures member under acdp-registry-transparency-log (RFC-ACDP-0015 §6.1) without advertising this profile.
acdp-consumer
For consumer deployments (libraries, agents). Does not run a registry.
| Required | |
|---|---|
| Behavioral requirements | End-to-end signature verification (RFC-ACDP-0001 §5.11) on every retrieved context, including pure did:key resolution (§5.11.1) for did:key producers (0.2.0); registry-receipt verification per RFC-ACDP-0010 §8 whenever a registry_receipt is present, with the receipt verdict reported separately from the body verdict (0.2.0); lineage-head-receipt verification per RFC-ACDP-0011 §7 whenever a lineage_head_receipt is relied upon, with the head-receipt verdict (and as_of freshness policy) reported separately from the body and context-receipt verdicts (0.3.0); key-revocation semantics per RFC-ACDP-0014 §7 whenever a verified key-revocation context is encountered — receipt-attested publish time strictly before compromised_since → historically authorized (pre-compromise, receipt-attested); at/after, or with no verifiable publish time → fail closed under the strict profile; producer-signed vs registry-attested trust classes reported distinguishably (0.3.0); treatment of status: retracted as a formal-withdrawal non-reliance signal (RFC-ACDP-0013 §7, RFC-ACDP-0001 §9) (0.3.0); witness-cosignature verification per RFC-ACDP-0015 §8 whenever witness_signatures cosignatures are relied upon — closed parse, signature under the witness's own DID key, witness+checkpoint binding, witnessed_at skew; N-witnessed over distinct trusted witness DIDs; the witness verdict and local quorum/freshness policy (RFC-ACDP-0015 §8.1) reported separately from the body, context-receipt, head-receipt, and log verdicts (0.4.0); acdp:// cross-registry resolution per RFC-ACDP-0006 if followed (with SSRF protections of §7 if performed server-side); local visibility re-verification per RFC-ACDP-0008 §4.5; tolerance of unknown body / registry-state fields (RFC-ACDP-0001 §6, RFC-ACDP-0004 §4.1, RFC-ACDP-0007 §3.3) |
| Conformance fixtures | All can-* (including can-008, can-009, can-010 for forward-compat hash verification at the body and DataRef levels, can-011 for the RFC 8785 §3.2.2.3 numeric-serialization vectors per RFC-ACDP-0001 §5.2, and can-012 for the 0.2.0 divergence-corpus vectors per RFC-ACDP-0001 Appendix A), lin-001 (lineage_id derivation), sig-001, sig-003 + dk-001/dk-002/dk-004 (pure did:key verification — required for 0.2.0 consumers, which cannot choose which DID methods the bodies they encounter use; 0.1.0-pinned consumers unaffected), fp-001 (fingerprint encoding), rcpt-001..rcpt-004 and rot-001 (receipt verification per RFC-ACDP-0010 §8 and the §10 historical-key rule), caps-001..007 (capabilities validation; (0.3.0) caps-007 — limits.max_publish_per_minute accept + zero/negative/non-integer rejection per RFC-ACDP-0007 §3.5 item 11), idem-007 ((0.3.0) reject a capabilities document advertising acdp_version ≥ 0.3.0 with supports_idempotency_key absent or false — RFC-ACDP-0003 §6.4, RFC-ACDP-0007 §3.5 item 10), status-001..004 (registry-state status pattern tolerance), schema-001..014 (schema openness, the absent-vs-null wire convention — extended in schema-011..014 to DataRef.format / DataRef.location per RFC-ACDP-0002 §6.8, error.details, and capabilities.limits.idempotency_key_ttl_seconds — and the closed nested schemas), data-ref-008 (consumer-side external-DataRef hash mismatch → data_ref_hash_mismatch, body still valid — RFC-ACDP-0007 §5.3), data-ref-ssrf-001..005 (consumer-side DataRef-location SSRF refusal at fetch time — IP-literal, DNS-rebinding, cross-authority-redirect, mixed-answer, and same-host-different-port-redirect refusal per RFC-ACDP-0008 §4.9), did-ssrf-001..005 (producer DID resolution SSRF protection — every consumer resolves producer DIDs to verify signatures, RFC-ACDP-0008 §4.8 — including mixed-answer and same-host-different-port-redirect refusal), body-001..002 (consumer MUST reject a retrieved body whose origin_registry is a DID rather than a hostname — RFC-ACDP-0002 §3.1), the consumer side of vis-003, pub-007 and schema-002 (publish-response shape), pub-010 (non-did:web contributor tolerance), fed-010 (partial-walk reporting per RFC-ACDP-0006 §4.1 — required for any consumer that walks derived_from: a walk truncated by a traversal cap MUST be distinguishable from a complete one, e.g. complete: false; silent truncation misleads evidence assembly), plus the remaining fed-* vectors if the consumer performs server-side cross-registry resolution. (0.3.0, conditional) lhr-001..lhr-004 (lineage-head-receipt verification per RFC-ACDP-0011 §7) are REQUIRED for any consumer that relies on lineage_head_receipt members — i.e. consumes /current from registries advertising acdp-registry-head-receipts; a consumer that ignores the member entirely (tolerating it as an unknown field per RFC-ACDP-0001 §6) is unaffected. (0.3.0, conditional) log-001..log-004 (transparency-log verification per RFC-ACDP-0012 §9 — leaf reconstruction and hashing, checkpoint signature, inclusion-proof folding, consistency-proof verification) are REQUIRED for any consumer that relies on log_inclusion members or the /log/* endpoints of registries advertising acdp-registry-transparency-log; a consumer that ignores them entirely is unaffected. (0.3.0) rev-001 (key-revocation context golden vector — executed; canonical form, content_hash, signature by the current key K2, §4 shape, not-self-signed rule) and rev-002 (compromise-boundary semantics per RFC-ACDP-0014 §7 — pre-T receipt-attested → historically authorized (pre-compromise); at/after-T or receipt-less → fail closed; trust classes distinguishable) are REQUIRED for 0.3.0 consumers (0.1.0/0.2.0-pinned consumers unaffected). (0.3.0, conditional) lc-001/lc-003 are REQUIRED (in their consumer-observable aspects: retracted handling, lifecycle_events tolerance/preservation, /current 404 handling) for consumers of registries advertising acdp-registry-lifecycle. (0.4.0, conditional) wit-001..wit-004 (witness-cosignature verification per RFC-ACDP-0015 §8 — closed parse, witness-keyed signature, witness+checkpoint binding, witnessed_at skew, and the N-witnessed quorum count) are REQUIRED for any consumer that relies on witness_signatures — aggregated by registries advertising acdp-registry-transparency-log (RFC-ACDP-0015 §6.1) or fetched direct from witnesses advertising acdp-log-witness (RFC-ACDP-0015 §6.2); a consumer that ignores witness_signatures entirely (unknown-field tolerance) is unaffected. wit-001/wit-003 are executed arithmetically; wit-002/wit-004 are behavioral |
Adding a profile
Open a PR adding a row above and amending RFC-ACDP-0001 §9.1 with the profile's MUST list. Profiles MUST:
- Be a strict superset of any prerequisite.
- Carry conformance fixtures sufficient to validate the additional MUSTs.
- Have a stable name; renames are forbidden.
Reserved future identifiers: acdp-registry-push (RFC-ACDP-0009 §2.4), acdp-registry-walks (RFC-ACDP-0009 §2.5). (acdp-registry-receipts was promoted out of reserved space by RFC-ACDP-0010 in acdp/0.2.0; acdp-registry-transparency-log by RFC-ACDP-0012 in acdp/0.3.0; acdp-log-witness by RFC-ACDP-0015 in acdp/0.4.0.)