OCPP-AI v1.0 Open Cryptographic Provenance Protocol for AI System Outputs

Recitals (informative)

Article 1 — Scope and conformance

1.1 This specification defines a machine-readable cryptographic receipt format and verification procedure addressing the transparency obligations of Article 50 of Regulation (EU) 2024/1689. The specification covers sub-obligations 50(1), 50(2), 50(4), and 50(6). Sub-obligation 50(3) is deferred to a subsequent revision pending stakeholder consultation on biometric notification handling under joint AI Act and GDPR constraints.

1.2 An implementation is OCPP-AI v1.0 conformant if it produces receipts conforming to Articles 3 and 4, anchors batched Merkle roots to a substrate satisfying the Anchor Interface (Article 5), and supports the verification procedure of Article 8.

1.3 Conformance is implementation-language-neutral. Reference implementations exist in Python, TypeScript, and Rust under Apache License 2.0; conforming implementations in any language are explicitly admitted.

Article 2 — Definitions

For the purposes of this specification, the following definitions apply:

• Receipt — a machine-readable cryptographic record conforming to Article 3 that attests to the provenance of a single AI system output for the purpose of Article 50 transparency.
• Receipt batch — an ordered collection of receipts whose Merkle root is anchored as a single anchor record per the Anchor Interface.
• Anchor substrate — a publicly verifiable, immutable data structure satisfying the Anchor Interface, used to publish Merkle roots of receipt batches.
• Deployer — a natural or legal person using an AI system under its authority within the meaning of Article 3(4) of the AI Act.
• Verifier — any natural or legal person, including supervisory authorities and natural persons, exercising the verification procedure of Article 8.
• Maintainer — the LedgerProof Foundation, the entity responsible for the reference implementation and for the revision procedure of Article 10.

Article 3 — Receipt structure and canonical encoding

3.1 Structural layers. A receipt comprises three structural layers:

1. An envelope establishing chain identity (sequence, prev_hash, entry_hash, signature, publisher_id, key_id);
2. A content body conforming to one of the Article 50 sub-obligation profiles defined in Article 4;
3. An anchor reference resolving to a substrate-level anchor record per the Anchor Interface.

3.2 Canonical encoding. Receipts are encoded using the Concise Binary Object Representation (CBOR; RFC 8949) deterministic encoding subset. The CBOR encoding is canonical and reproducible: byte-identical input data produces byte-identical CBOR encoding across all conforming implementations.

3.3 Signature scheme. Receipts are signed using Ed25519 (RFC 8032). The signature covers the canonical CBOR encoding of the envelope and content body.

3.4 Hash function. All hash references within receipts and the Anchor Interface use SHA-256 (RFC 6234).

3.5 Merkle aggregation. Receipt batches are aggregated into a Merkle tree per the construction described in RFC 6962 (Certificate Transparency). The root of this tree is the value published as the anchor payload per the Anchor Interface, Section 2.7.

Article 4 — Article 50 sub-obligation profiles

OCPP-AI v1.0 defines three content body profiles, each mapping to specified sub-obligations of Article 50.

4.1 — ChatbotSession profile (Article 50(1))

Used to record that a natural person was disclosed to be interacting with an AI system. Fields: ai_system_id, deployer_id, deployer_country, disclosure_text_hash, session_start_timestamp, session_identifier. Schema validation MUST reject disclosure_text values that contain personally identifiable information patterns.

4.2 — GeneratedContent profile (Article 50(2))

Used to record that a piece of synthetic media was generated or manipulated by an AI system. Fields: ai_system_id, deployer_id, deployer_country, content_hash, perceptual_hash, generation_type (AI_GENERATED, AI_MANIPULATED, AI_ASSISTED), source_content_hash (required for AI_MANIPULATED), is_public_interest, transparency_marker.

4.3 — HumanReview profile (Article 50(4))

Used to record that AI-generated text was subject to human editorial review prior to publication, evidencing the Article 50(4) exemption. Fields: content_hash, reviewer_role, reviewer_organization, review_rationale, review_timestamp. The reviewer_role and review_rationale fields draw from a bounded vocabulary; schema validation MUST reject values containing email addresses, telephone numbers, or free-text patterns matching common PII regular expressions.

4.4 — Manner-of-disclosure (Article 50(6))

The transparency_marker field (default: "LPR-EU-AI-ACT-50") present in ChatbotSession and GeneratedContent profiles satisfies the Article 50(6) requirement that disclosure be made in a clear and distinguishable manner. The field admits localized values for Member State use.

Article 5 — Anchor Interface integration (normative reference)

The Anchor Interface is specified separately at https://spec.ledgerproofhq.io/anchor-interface-v1.html and is incorporated into this specification by normative reference. Conforming implementations MUST publish receipt-batch Merkle roots to a substrate satisfying that interface. Two conforming substrates are described in the Anchor Interface specification: the Bitcoin OP_RETURN reference implementation and the European Blockchain Services Infrastructure (EBSI) alternative implementation. Dual-anchor deployment is RECOMMENDED for deployers operating under EU jurisdictional reach.

Article 6 — Architectural compatibility with eIDAS 2.0

6.1 Scope of compatibility. OCPP-AI v1.0 is architecturally compatible with the verifiable attestation patterns of Regulation (EU) 2024/1183 (eIDAS 2.0). This document does NOT claim that OCPP-AI signatures constitute Qualified Electronic Signatures (QES) per eIDAS Article 25, nor that the LedgerProof Foundation is a Qualified Trust Service Provider (QTSP). Such qualifications, where required by a specific use case, are obtained through arrangement with an established QTSP, as described in Section 6.3.

6.2 Wrapping pattern. An OCPP-AI receipt MAY be wrapped as a W3C Verifiable Credential 2.0 (see Article 7) and, in that form, presented through an eIDAS-compliant Trust Service Provider for use cases requiring qualified evidence. The receipt content remains unaltered; the eIDAS qualification attaches at the wrapping layer.

6.3 Complementarity. OCPP-AI provides the cryptographic provenance evidence layer specifically for Article 50 transparency. eIDAS 2.0 provides the broader trust-service framework for qualified evidence. The two frameworks are complementary: OCPP-AI does not duplicate, compete with, or replace eIDAS infrastructure. Deployers requiring qualified evidence under Article 50 may obtain it by combining OCPP-AI receipts with an eIDAS-qualified TSP wrapping arrangement.

Article 7 — Architectural compatibility with W3C Verifiable Credentials 2.0

7.1 JSON-LD context. A JSON-LD context for wrapping OCPP-AI receipts as W3C VC 2.0 Verifiable Credentials is published at https://spec.ledgerproofhq.io/contexts/lpr-v1.jsonld and is incorporated into this specification by reference.

7.2 credentialSubject mapping. The OCPP-AI content body fields (deployer_id, reviewer_role, content_hash, disclosure_text_hash, and the remaining fields enumerated in Article 4) are mapped to credentialSubject properties in the published JSON-LD context. The mapping is one-to-one and is reversible; an OCPP-AI receipt may be losslessly serialized as a W3C VC 2.0 Verifiable Credential and recovered from that form.

7.3 Issuer. When an OCPP-AI receipt is wrapped as a W3C VC, the issuer property identifies the publishing deployer (not the LedgerProof Foundation). The Foundation does not claim issuer authority over receipts issued by deployers; the Foundation is the maintainer of the reference implementation.

Article 8 — Verification procedure

An OCPP-AI receipt is verified by performing the following steps in order:

1. Parse the receipt as canonical CBOR per Article 3.2. Reject if parsing fails.
2. Verify the Ed25519 signature over the envelope and content body per Article 3.3, using the publisher's published public key. Reject on signature failure.
3. Verify that the content body conforms to one of the Article 4 profiles. Reject on schema validation failure.
4. Resolve the anchor reference per Anchor Interface Section 2.5. Reject if the anchor record is not retrievable.
5. Verify the OCPP-AI Anchor Payload Format (Anchor Interface Section 2.7) of the resolved anchor record, including the "LPR1" magic prefix.
6. Reconstruct the Merkle proof from the receipt to the anchor's published Merkle root per RFC 6962. Reject on Merkle proof failure.
7. Where dual anchoring is in use and the verifier's policy requires it, repeat steps 4 through 6 against the secondary anchor and assert Merkle root identity per Anchor Interface Section 7.2.

A receipt that passes all steps is verified. No step requires authentication to or cooperation by any party. The verifier requires only public substrate access and the publisher's published public key.

Article 9 — GDPR compatibility and personal-data exclusion

9.1 Structural exclusion. The OCPP-AI receipt schema is constructed to preclude the inclusion of personal data within receipts. Fields that could otherwise carry personal data (deployer_id, reviewer_role, review_rationale) are bounded to specific identifier formats (Legal Entity Identifier, VAT identifier, bounded role vocabulary) and schema validation MUST reject email addresses, telephone numbers, government identifiers, and free-text PII patterns.

9.2 Anchor exclusion. The Anchor Interface Section 2.8 prohibits inclusion of personal data at the anchor layer. The 32-byte SHA-256 Merkle root carries cryptographically no recoverable information about underlying receipt content.

9.3 Erasure mechanics. Receipt-level erasure under GDPR Article 17 is performed at the receipt store. Erasure invalidates the Merkle proof for the erased receipt without invalidating proofs for other receipts in the same batch. The anchor is unaffected by erasure.

Article 10 — Governance, maintainer accountability, and revision procedure

10.1 Maintainer. The LedgerProof Foundation maintains the reference implementation and operates the specification revision procedure. The Foundation is established as a Delaware 501(c)(3) public charity under Adler & Colvin counsel and a Dutch Stichting EU subsidiary under NautaDutilh counsel. The Foundation's governance structure, board composition, and conflict-of-interest disclosures are published at https://docs.ledgerproofhq.io/foundation/.

10.2 Revision procedure. Material revisions to this specification are issued under the Foundation's Bitcoin-anchored governance procedure. Each revision is published with a corresponding foundation_governance_event/v1 record anchored per the Anchor Interface, providing tamper-evident evidence of the revision date and content.

10.3 Standardization participation. The Foundation contributes to standardization activities at CEN-CENELEC JTC 21 (through national mirror committees including DIN Germany and AFNOR France), at the IETF SCITT Working Group, and at W3C. The Foundation does not assert ownership of intellectual property necessary to implement this specification; the specification is published under CC BY 4.0.

10.4 Foundation undertaking. The Foundation undertakes that this specification will not be made subject to commercial licensing, that no person will be required to obtain Foundation consent to implement, deploy, or extend the specification, and that the Foundation will support the adoption of this specification or its successors by other standards bodies including ISO, CEN-CENELEC, IETF, and W3C if requested.

Annex A — Article 50 sub-obligation conformity matrix

Annex B — Reference implementation inventory

The Foundation publishes reference implementations under Apache License 2.0 at github.com/vsdawkins-creator/ledgerproof-eu. As of the date of this specification, reference implementations exist for the following languages and frameworks:

• Core libraries: Python (CPython 3.10+), TypeScript (Node.js 20+, Deno 1.40+), Rust (stable channel)
• Framework adapters (Python): LangChain, LlamaIndex, OpenAI SDK, Anthropic SDK, Google AI SDK, Vertex AI, AWS Bedrock, Azure OpenAI, Mistral, Cohere, Together AI, Groq, Hugging Face Transformers, AI21, Replicate, xAI, DeepSeek, Qwen, Reka, Voyage AI, Cerebras, IBM watsonx, Snowflake Cortex, Perplexity, Fireworks, Mistral Codestral, Aleph Alpha, Haystack, Semantic Kernel
• Verifier tooling: command-line verifier, browser-based verifier (no SaaS dependency), JSON-LD verifier compatible with W3C VC 2.0

Annex C — Test vectors

Conformance test vectors are published at https://spec.ledgerproofhq.io/test-vectors-v1/ and include sample receipts for each Article 4 profile, sample anchor records, sample Merkle proofs, and sample W3C VC 2.0 wrappings. Implementers MUST pass all test vectors to claim conformance.