Specification v0.1
A light, per-domain taxonomy on the base protocol, defining which content-authenticity data is shared and what it means.
Status: Draft, pending technical review Version: 0.1 Date: 2026-07-17 Relationship: a domain taxonomy on the base protocol (see Section 1) Initiator and first maintainer: the base-protocol working group (see Section 5, Governance). The initiator is not the owner. The overview page orients and links, and does not repeat this content.
Abstract
This is a light, per-domain taxonomy on the base protocol. It defines which content-authenticity data is shared and what it means. It references the base protocol normatively for every mechanism it uses: record envelope, addressing, encryption, anchoring, verification, identity, and the register. It restates none of them.
The taxonomy fixes five things for the content-authenticity domain, each mapping to one subsection of the normative core:
- A capture device signs content at the moment of capture (Section 3.2).
- The holder holds the signing key (Section 3.3).
- A content-authenticity claim is published as a verifiable claim in the base protocol's register (Section 3.4).
- Any receiver verifies that claim independently (Section 3.5).
- The claim aligns with the open content-provenance standard, C2PA, where an embedded provenance manifest is used (Section 3.6).
C2PA specifies the embedded manifest that travels with the file. This taxonomy adds independent anchoring, register publication, and discovery, so any receiver verifies provenance, signature and anchor without holding the file and without a central party.
Passport-photo authenticity is described as the first, illustrative application, framed as an exploration or pilot. This version defines no live service and names no branded instance.
1. Introduction and scope
1.1 What this taxonomy is
This is a domain taxonomy in the sense the base protocol reserves for one (base protocol, Section 1.2): a light, per-domain agreement that sits above the base layer and defines which data a field of work shares and what it means. The field here is content authenticity. The taxonomy defines a single domain object, the content-authenticity claim: what data it carries, what it asserts, and how it binds to the base protocol's mechanisms. It is deliberately thin. It fixes only the domain meaning that two independent implementations must agree on to exchange and verify content-authenticity claims, and nothing more.
1.2 What this taxonomy is not
This taxonomy adds no layer of its own. Mirroring the base protocol's own scope statement (base protocol, Section 1.2), the following are explicit non-goals:
- It is not a new base layer. It introduces no envelope, no addressing scheme, no encryption model, no anchoring mechanism, no register, and no key derivation of its own. Every one of those is the base protocol's, and is used by reference.
- It is not a restatement of the base protocol. It does not reproduce the record envelope bytes, the key-derivation construction, the anchoring mechanics, or the register rules. Where a mechanism is needed, this document points to the base-protocol section and stops.
- It is not a product, a live service, or a directory. It names no branded instance, no adopter, and no live lookup service.
- It is not a threat model or a security analysis. It carries no attack catalogue, no detection tuning, and no numeric scoring. It also carries no key-storage, camera-integration, or hardware-security-module detail: those are implementation and operator concerns and sit outside this document, exactly as the base protocol keeps operator-tier configuration outside its specification.
- It is not a certification of conformance to the content-provenance standard. It aligns with that standard and maps to it (Section 3.6); it never claims certified conformance on the strength of this taxonomy alone. As summarised in the Abstract, C2PA covers the embedded manifest while this taxonomy adds independent anchoring, register publication, and discovery (Section 3.6).
1.3 Relationship to the base protocol
Every mechanism this taxonomy relies on belongs to the base protocol. This taxonomy fixes only the domain meaning laid on top. The table below maps each mechanism to the base-protocol section it rests on. That section is the normative source; this document does not repeat it.
| This taxonomy relies on | Base-protocol section (/protocols/data-sharing/v0.1) |
|---|---|
| The record shape and canonical encoding of a claim | Section 3.1, Data envelope and wire format |
| Addressing and discovery of a published claim | Section 3.2, Addressing and discovery |
| Per-field encryption, field commitments, and placement of content off the audit layer | Section 3.3, Encryption principles |
| Anchoring a claim and its independently verifiable proof | Section 3.4, Anchoring to the public audit layer |
| Deterministic verification and replay by a receiver | Section 3.5, Verification and replay semantics |
| The capture device as a mandated actor, holder-held keys, and revocable delegation | Section 3.6, Identity and delegation |
| Publishing a claim and looking it up | Section 4, Register and discovery standard |
| Conformance machinery and the interoperability test | Section 6, Conformance |
| Governance, licence, hand-over, and the working group | Section 7, Governance |
A change to this taxonomy does not change the base layer, and a change to the base layer does not require this taxonomy to change its meaning. That separation is what lets one expensive-to-standardise base layer carry many light domain agreements above it.
1.4 First application
The first application explored for this taxonomy is passport-photo authenticity. It is described here functionally and as an exploration or pilot, never as a live operational service.
In that setting, a capture device signs a photograph at the moment of capture on behalf of a holder (for example a capture operator) who controls the signing key. The signed content-authenticity claim is published to the register. An identity-document issuer, and any other receiver, can then verify independently that the photograph was captured by that device on behalf of that holder at that time, and is unmodified since capture, without contacting the party that recorded it and without a central authority. Any public body exploring this kind of exchange would do so as a pilot. This taxonomy makes no claim that any such exchange is live or operational anywhere.
2. Terminology and conventions
2.1 Normative key words
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in capital letters.
2.2 Citation of open standards
This taxonomy inherits the base protocol's open-standard citations by reference and does not restate them. In particular, the identity standards it depends on (W3C DID, W3C Verifiable Credentials, SD-JWT, OpenID4VP, OpenID4VCI, and eIDAS) are the base protocol's and are used through its identity chapter (base protocol, Section 3.6), not redefined here.
This taxonomy adds one domain standard: the open content-provenance standard C2PA (Coalition for Content Provenance and Authenticity). It is cited neutrally, the way one cites an RFC, as the published standard on which the embedded-manifest mechanism rests and which any party may implement. The specification family is published at c2pa.org/specifications/. This document references the current 2.x family without pinning a normative version; the precise version mapping is deferred (see Section 7, PROV-CA-2).
2.3 Glossary
Only domain terms are defined here. Terms already defined by the base protocol (Party, actor, record, recorded action, envelope, field, placement, the public audit layer, anchor, proof, mandate, delegation, register, claim) keep their base-protocol meaning and are not redefined.
| Term | Definition |
|---|---|
| Content item | The captured content that a content-authenticity claim is about, for example a photograph. |
| Capture device | The device that signs a content item at the moment of capture. It is an actor in the sense of the base protocol, signing under a mandate from the holder (base protocol, Section 3.6). |
| Holder | The party on whose behalf the capture device signs, and who holds the signing key. A Holder is a Party in the sense of the base protocol. |
| Content-authenticity claim | A signed, anchored recorded action asserting the capture provenance and the integrity of a content item. It is a claim in the sense of the base protocol register (base protocol, Section 4), specialised for this domain. |
| Provenance manifest | An embedded set of signed provenance assertions that travels with the content item, aligned with C2PA. |
| Assurance signal | An independent verification input that a domain profile MAY require in addition to the mandatory checks. |
| Domain profile | A working-group-defined configuration of the assurance signals a receiver requires. Not fixed in this version (see Section 7, PROV-CA-1). |
| Receiver (verifier) | Any party that verifies a content-authenticity claim. A Receiver is a Party in the sense of the base protocol. |
3. Normative core
This section fixes the domain rules. Each subsection states the domain meaning, references the base-protocol section that supplies the mechanism, and ends with an explicit Rules list. No base-protocol mechanism is re-derived here. Where a rule touches an item that is provisional pending technical review, it is tagged inline as [PROV-n] and collected in Section 7.
3.1 The content-authenticity claim
A content-authenticity claim states that a given content item was captured by a given device, on behalf of a given holder, at a given time, and is unmodified since capture. The claim is a recorded action in the sense of the base protocol (base protocol, Section 3.1). Its arguments carry a cryptographic commitment to the content item, the capture time carried in the action itself, the identifier of the capturing actor, and, where one exists, a reference to a provenance manifest. The claim asserts provenance and integrity; it does not carry the content item in the clear (Section 3.4).
Rules.
- A content-authenticity claim MUST be a recorded action conforming to the base protocol (Section 3.1).
- The claim MUST carry a cryptographic commitment to the content item it is about.
- The claim MUST carry the capture time in the action itself, read from the action and not from a local clock, so that verification is deterministic (base protocol, Section 3.5).
- The claim MUST carry the identifier of the capturing actor.
- The claim SHOULD carry a reference to a provenance manifest where one exists (Section 3.6).
3.2 Signing at capture
The capture device signs the claim at the moment of capture. The signature binds the content commitment, the capturing actor, and the capture time into one signed recorded action. The device is a mandated actor in the sense of the base protocol: it holds a scoped, time-bounded, revocable mandate from the holder, and its signature verifies locally against the key pinned when the mandate was granted, with no network call at the moment of capture (base protocol, Section 3.6). Key storage, camera integration, and any hardware-security-module choice are implementation and operator concerns and are outside the scope of this taxonomy.
Rules.
- The capture device MUST sign the claim as an actor holding an active, in-scope mandate for the claim method (base protocol, Section 3.6).
- The signature MUST bind the content commitment and the capture time.
- Verification of the capture signature MUST be local, against the pinned actor key, with no network call required at the moment of capture (base protocol, Section 3.6).
- This taxonomy states no requirement on key-storage, camera-integration, or hardware-security-module architecture; those are implementation and operator concerns and are out of scope.
3.3 Holder-held keys
The holder holds the signing key. There is no custodial central signer. The base protocol derives keys on demand rather than storing them, and binds an actor to a scoped, revocable mandate whose delegation and revocation are themselves recorded actions (base protocol, Sections 3.3 and 3.6). This taxonomy adopts that model unchanged: the authority to sign a capture claim flows from the holder to the capture device as a base-protocol mandate, and can be revoked in its own scope without affecting the holder's other keys. Where the identity of a capturer is asserted alongside the claim, it MAY be carried as a portable credential the holder controls.
Rules.
- The holder MUST control the signing key used for its capture claims.
- This taxonomy MUST NOT require a custodial central signer.
- A mandate from a holder to a capture device MUST be revocable, and its delegation and revocation MUST each be recorded actions (base protocol, Section 3.6).
- A capturer identity, where asserted, MAY be carried as a portable, selectively disclosable credential per the base protocol's identity chapter (base protocol, Section 3.6), for example using W3C Verifiable Credentials or SD-JWT.
- Where the holder is a natural person, the base protocol's separable-identity pattern applies for erasability
[PROV-4](base protocol, Section 3.6); this taxonomy adds no new erasure mechanism.
3.4 Publication to the register
A content-authenticity claim is published as a claim in the base protocol's register (base protocol, Section 4) and anchored to the public audit layer (base protocol, Section 3.4). The content item itself is not placed on the public audit layer. Only the cryptographic commitment to it is anchored, and the content item sits in external storage under the base protocol's placement descriptor (base protocol, Section 3.3). This is the privacy-preserving default for personal content: a receiver can verify that a content item exists and is unchanged from the commitment without the content item ever being written to the shared audit layer [PROV-1] [PROV-3].
Rules.
- The claim MUST be published as a signed, anchored claim conforming to the base protocol (Section 4).
- The claim MUST carry its issuer binding, so that any party can verify the claim's origin against the issuer's pinned key (base protocol, Section 4).
- The content item MUST NOT be anchored on the public audit layer. Only its commitment MUST be anchored (base protocol, Section 3.4), with the content item placed under the base protocol's placement descriptor (base protocol, Section 3.3).
- Where the content item concerns a natural person, erasability MUST follow the base protocol's separable-identity pattern
[PROV-4](base protocol, Section 3.6); this taxonomy adds no new erasure mechanism.
3.5 Verification by any receiver
Any receiver verifies a content-authenticity claim independently, with no central authority and no access to the store that originated the content item. Verification reuses the base protocol's verification and replay semantics (base protocol, Section 3.5) and its anchoring proofs (base protocol, Section 3.4). A receiver checks the capture signature against the pinned actor key, checks the anchor proof, and recomputes the content commitment from the content item it legitimately holds. A domain profile MAY require additional assurance signals beyond these mandatory checks. The set, weighting, and thresholds of any such signals are not fixed in this version and are working-group taxonomy work [PROV-CA-1].
Rules.
- A receiver MUST be able to verify a content-authenticity claim without trusting any central party and without access to the originating store.
- Verification MUST check the capture signature against the pinned actor key (base protocol, Section 3.6), the anchor proof (base protocol, Section 3.4), and the content commitment (base protocol, Section 3.3).
- A cross-domain reference to a claim MUST carry its own proof, so a receiver in another domain verifies it without access to the originating domain's storage (base protocol, Section 3.4).
- A domain profile MAY require additional assurance signals; their set, weighting, and thresholds are NOT fixed in this version
[PROV-CA-1].
3.6 Alignment with the content-provenance standard
Where a content item travels with an embedded provenance manifest, the claim aligns with the open content-provenance standard, C2PA. The relationship is complementary. C2PA specifies the embedded manifest that travels with the media: a set of signed provenance assertions carried with the file. The base protocol adds what C2PA does not itself specify: independent anchoring to the public audit layer, publication of the claim to the register, and discovery of that claim. The two fit together, the embedded manifest for content that carries its own provenance, and the anchored, published claim for independent verification by any receiver [PROV-CA-2].
Rules.
- Where a content item carries an embedded provenance manifest, an implementation SHOULD align that manifest with C2PA.
- An implementation MAY map the capture signature and the provenance assertions to C2PA manifest assertions.
- An implementation MUST NOT claim certified C2PA conformance on the strength of this taxonomy alone
[PROV-CA-2]. The precise version mapping and any formal conformance claim are deferred to technical review and working-group work.
4. Conformance
A content-authenticity implementation is conformant when both of the following hold:
- It is conformant to the base protocol (base protocol, Section 6) for every mechanism this taxonomy references, and
- It demonstrates the domain rules of Section 3.
The table below maps each domain requirement to its rule in Section 3 and to the base-protocol section it inherits. This taxonomy names no test-vector suites of its own: the byte-level machinery is the base protocol's, and its published test-vector suites and port contracts (base protocol, Section 6) apply unchanged. Any domain-specific vectors are deferred to working-group work.
| # | An implementation MUST demonstrate | Maps to | Inherits from base protocol |
|---|---|---|---|
| 1 | A content-authenticity claim as a well-formed recorded action carrying the content commitment, capture time, and capturing actor | 3.1 | Section 3.1 |
| 2 | Signing at capture by a mandated actor, verified locally against a pinned key | 3.2 | Section 3.6 |
| 3 | Holder-held, non-custodial keys with a revocable mandate to the capture device | 3.3 | Sections 3.3, 3.6 |
| 4 | Publication of the claim to the register with the content item off the audit layer and only its commitment anchored | 3.4 | Sections 3.3, 3.4, 4 |
| 5 | Independent verification by any receiver: capture signature, anchor proof, and content commitment | 3.5 | Sections 3.4, 3.5 |
| 6 | Alignment of an embedded provenance manifest with C2PA, without a certified-conformance claim | 3.6 | Sections 2.2, 3.4, 4 |
How a third party connects. To connect a content-authenticity implementation, a party implements the base protocol's port contracts and passes its conformance requirements (base protocol, Sections 5 and 6), then produces and verifies content-authenticity claims per Section 3 of this document: it signs a claim at capture as a mandated actor, publishes it to the register with only a commitment anchored, and verifies an incoming claim by checking the capture signature, the anchor proof, and the content commitment. Read together with the referenced base-protocol sections, this taxonomy is self-contained enough to build against.
Conformance levels. A MUST rule is required for interoperability in this domain. A SHOULD rule is recommended, and its absence must be justified. A MAY rule is optional. An implementation states which SHOULD and MAY provisions it supports.
Working group. Implementers and domain experts are invited to the working group to develop domain profiles and future versions of this taxonomy. The full model is at /governance.
5. Governance
No single party owns this taxonomy. Domain taxonomies belong to the working-group members who propose and ratify them, not to one party; a group can join an existing taxonomy effort or start a new one where a field needs its own shared meaning. The initiator is not the owner: the maintainer role is temporary and transferable, and stewardship passes to the working group under the base protocol's hand-over clause once at least three parties are actively implementing and participating. The open, royalty-free licence that lets anyone implement, fork, and run this taxonomy is being finalised, in step with the base protocol's. Versions are explicit and forkable, and a fork carries exactly as far as others choose to adopt it, with the public audit layer as the one natural fork boundary. This version does not claim an independent foundation. The full governance model, the licence, and the hand-over conditions are documented at /governance rather than restated here.
6. Versioning and changelog
This is version 0.1, status Draft, pending technical review. Future versions are proposed and ratified through the public working group. Versions remain explicit, so adopters choose when to move.
Changelog
- v0.1 (2026-07-17) Initial content-authenticity taxonomy. Defines the content-authenticity claim, signing at capture, holder-held keys, publication to the register, verification by any receiver, and alignment with the open content-provenance standard. Establishes the normative-reference mapping to the base protocol (Section 1.3) and marks the provisional items in Section 7.
7. Provisional-items register
This taxonomy inherits some of the base protocol's provisional items where it uses the mechanisms they cover, and it adds two of its own. Each provisional item is tagged inline at its point of use in Section 3 and collected here. Content from any internal threat model or client-specific security analysis is excluded from this version, not deferred: no attack catalogue, no detection tuning, no numeric weights or thresholds, and no key-storage, camera-integration, or hardware-security-module architecture appears here in any form.
| Item | Topic | Provisional because | Handling in this version |
|---|---|---|---|
| PROV-1 (inherited) | Settlement-layer naming and anchoring mechanics (Section 3.4) | The naming of the settlement layer and its standards-citation framing are a strategy and technical-review call at the base-protocol gate | This taxonomy names the layer only "the public audit layer" and defers the mechanics to the base protocol (Section 3.4) |
| PROV-3 (inherited) | Placement-channel ownership (Section 3.4) | The ownership and operator boundary of the store holding a content item is operator-tier configuration | The placement of a content item off the audit layer is stated as a domain rule; the store's ownership defers to the base protocol (Section 3.3) |
| PROV-4 (inherited) | Erasable-identity pattern for natural-person content (Sections 3.3, 3.4) | The concrete operator-owned identity-link mechanism is proprietary | This taxonomy adds no new erasure mechanism and defers to the base protocol's separable-identity pattern (Section 3.6) |
| PROV-CA-1 (taxonomy-specific) | The assurance-signal model (Section 3.5) | The framing is subject to technical review; the concrete signals are working-group domain-profile work | Additional assurance signals are permitted; their set, weighting, and thresholds are not fixed in this version and defer to domain-profile work |
| PROV-CA-2 (taxonomy-specific) | Content-provenance version mapping and conformance (Sections 2.2, 3.6) | The precise version mapping and any formal conformance claim are subject to technical review | This version claims alignment with C2PA, not certified conformance, and pins no normative version |
The base protocol's forward-secrecy trade-off (its PROV-2) and the consortium-membership half of its placement provisions (its PROV-3) are inherited wherever this taxonomy uses per-field encryption and placement, and are handled entirely by the base protocol; this taxonomy adds nothing to them.