Technical Specifications for PCF Data Exchange, Version 2.2.0 (WBCSD/PACT, April 2024)

Source: sources/standards/2026-10-29-pact-data-exchange-protocol-v2.2.md — native Markdown, 2,421 lines, no PDF original and no conversion step. Supplied by Martin Pompéry on 2026-10-29 as source 3 of 3 in the PACT bundle, alongside the Vision Paper (2022) and the Pathfinder Framework v2.0 (2023). Full title: “Technical Specifications for PCF Data Exchange”, also referred to in the text as the Pathfinder Network data exchange protocol.

Dating. The document is Version 2.2.0, released 10 April 2024 (Appendix B, Changelog). This is not the current state of the protocol: the body announces a version 3 repeatedly and by name, listing properties that “will become OPTIONAL in version 3 of the Technical Specifications”. Read it as the exchange layer belonging to Framework v2.0 — the hinge between the Vision Paper’s intentions and what Methodology v3 (2025) later inherited.

What kind of document this is: an interoperability profile

⟨Per Martin Pompéry, 2026-11-06, correcting the first reading of this source during ingest.⟩ The Tech Specs are an interoperability profile, and that is the frame every other finding on this page sits under. The document invents almost nothing. It selects from existing standards, constrains them to a subset, and specifies tolerant behaviour around them:

Layer	What is profiled
Transport	HTTPS only (MUST), HTTP/1.1 request syntax
Authentication	OAuth2 Client Credentials ([RFC6749] §4.4), Bearer tokens ([RFC6750]), OpenID Connect discovery for the token endpoint
Query	a named subset of the OData v4 $filter grammar — operators eq, lt, le, gt, ge, and, lambda any, over six scalar and two collection properties, and nothing else
Pagination	Link header per [RFC8288], rel=next, absolute target IRI, valid ≥ 180 s
Events	CloudEvents in Structured Content Mode, JSON encoding
Identity of things	URN syntax, with namespaces for GTIN, CAS Registry Numbers, IUPAC InChI, and buyer-/vendor-assigned custom codes
Vocabularies	UN CPC 2.1, ISO 3166 alpha-2 and -2 subdivisions, UN geographic regions/subregions, SI units, IPCC AR versions, UUIDv4, ISO 8601 (UTC only)

⟨Inference: this is why “the Tech Specs don’t define X” is almost never a finding on its own. A profile’s substance is which existing pieces it picks, how tightly it constrains them, and what it leaves to the layer below. The one place where that reading does bite is §7.2.1 and the security inventory below — because there the available standards existed and were not picked.⟩

Scope, stated by the document itself

“The scope of this document is to reach interoperability for product-level GHG emission data exchange through the definition of a data model […] and the definition of a HTTP REST API.” (§1.2.) And of the API: “The scope of the HTTP API is minimal by design.” (§7.1.)

Intended audience (§1.3): software developers; “auditors and sustainability experts who want to understand the data semantics of product footprints”; and anyone wanting to understand the technical foundations.

Postel’s law as the design principle

⟨Per Martin Pompéry, 2026-11-06: Postel’s law — be conservative in what you send, liberal in what you accept — is a basic design principle of the Tech Specs generally. The term does not occur in the document; the behaviour it names is written throughout.⟩

Where it is visible in the text:

• §4.1.1, the general principles of event processing: “A host system should strive to accept an event unless” it does not support event processing at all or the syntax is unsupported.
• Filtering is optional and best-effort (§7.6.1). A host that does not implement filtering “MUST process the request as if no Filter was provided”; a host that does implement it “CAN process the filter statement on a best-effort basis”, may ignore parts of it, or may refuse with NotImplemented.
• Partial results are legal (§7.6.4). HTTP 202 means “the returned list is an incomplete result of the given query”; the recipient may retry with exponential backoff until it receives a 200.
• Senders must not rely on the receiver (§4.1.1). “The requested host system will attempt to always send a response event […] but the requesting host system should not rely on this behavior and retry after an appropriate amount of time.”
• Retries are specified, with limits (§7.8.4). Exponential backoff; “SHOULD NOT retry sending a response event for more than 3 days”.
• Request events are deliberately under-specified (§7.8.4.1). “This specification does not yet specify the processing requirements of a host system upon receiving such an event. This means the host system can e.g. ignore 1 or more properties, it might not accept specific patterns of requests.”

Against this stands a small mandatory floor (§7.4): every host system MUST implement Authenticate, ListFootprints, GetFootprint and Events; MUST offer them over HTTPS only; MUST implement pagination server-side; and since 2.2.0-20240312 the Events endpoint is mandatory rather than optional.

⟨Inference: floor plus tolerance is what lets a network of independently built host systems interoperate without lockstep upgrades, and it is also what lets the 2.2.0 authentication flow reach hosts that never implemented OpenID Connect — the document says so in as many words: “the authentication flow is defined such that a Version 2.2.0 data recipient can authenticate against host versions irrespective of their support for OpenID-Connect” (§7.3). The known cost of the principle — tolerant receivers let divergent sender behaviour become de-facto permanent — is ⟨Background⟩, not something this document discusses.⟩

SINE is inside the specification

Not inferred from a credits page: the protocol’s own contact and example infrastructure is SINE’s.

• Comments on the document go to public-dev@pathfinder.sine.dev (§1.1).
• Every API example in §7.10 is issued against host api.pathfinder.sine.dev — ListFootprints, GetFootprint, the pagination Link header, the error response, and both event examples.
• Example responses carry the header server: Pathfinder.

⟨Inference: the Framework’s front matter calls SINE “our tech collaborator” and “Technology partner” (see Pathfinder Framework v2.0). This is the harder evidence of what that meant in practice: the reference deployment that the normative examples are written against runs on a SINE domain. It does not by itself establish who authored the specification text.⟩

§7.2.1: what the protocol declares out of scope

The single most consequential section for the wiki’s open questions. “Within the PACT Project, conforming host systems are called solutions”, and solutions “add further functionality on top of this standard”. Named as beyond the scope of the document:

1. Footprint calculation according to the Pathfinder Framework
2. Authentication and access management — “the act of deciding and setting which product footprint may be accessed by each data recipient”
3. Credentials management — “the overall functionality to generate access credentials for data recipients, to exchange these credentials with data recipients, to rotate or revoke such credentials, etc.”
4. Logging — “creation and storage of access logs and audit trails related to data exchange, authentication processes, etc.”

This answers the Vision Paper’s open questions — by exclusion

The Vision Paper (June 2022) named five trust pillars beyond data exchange — identity management, authentication, plausibility and error-checking, auditing, security and fraud prevention — and its own Figure 4 marked one of the six mechanisms as already specified: the data exchange mechanism. That page closed by asking what the Tech Specs would do with the other five.

The answer, in writing, nearly two years later: authentication-as-access- decision, credentials and audit trails are solution concerns, not network concerns. Plausibility and error-checking appear nowhere. What the protocol does specify is the transport-level half of authentication — how a recipient obtains a token — and nothing about what that token entitles anyone to.

⟨Inference: this is not drift from the vision, it is the vision’s own division of labour made explicit and then frozen. The consequence is that two conforming host systems can differ completely in who may see what, on what evidence, with what audit trail — and both remain conformant. The ICC Review’s charge that PACT “exchanges data rather than accountable quantities” is, at the protocol level, a description rather than an accusation.⟩

The security inventory, in full

Everything the protocol provides, exhaustively: TLS (HTTPS mandatory), OAuth2 client credentials, Bearer tokens with expiry and a TokenExpired error, optional OpenID Connect discovery, and validation by the data owner’s host system of the source field of an incoming request event before replying to it (§7.8.4).

Everything it does not provide: no signature on a product footprint, no integrity protection of the payload, no cryptographic binding of a PCF to its issuer, no proof of any property of the data, no confidentiality mechanism beyond access control at the host, and no verifiable audit record. The words cryptography, encryption, signature, proof, zero-knowledge and multi-party computation do not occur in 2,421 lines.

A ProductFootprint travels as plain JSON. companyName is a free-text string, companyIds a set of URNs the data owner asserts about itself. The assurance object is a set of claims about an audit — provider name, level, boundary, completion date — with nothing attached that the recipient could check.

Confidentiality is access control, and even that is advisory: “Host systems SHOULD implement an access management system and only return the product footprints for which the data owner granted access to the requesting data recipient” (§7.6, §7.7). The error code for the failure case is AccessDenied (HTTP 403); footprints a recipient may not see are simply omitted from list responses.

⟨Inference, the sharpest version of open task 19 available anywhere in this wiki: this is a document that profiles other people’s standards for a living. JSON Web Signature, and by 2024 Verifiable Credentials, were available to be profiled on exactly the same terms as OData and CloudEvents were. They were not selected. That is a datable design decision by a named body, not an absence explicable by unfamiliarity — and SINE, whose domain the examples run on, had built secure multi-party computation for carbon benchmarking three years earlier. See the confidentiality gap.⟩

Access is discretionary by design

The business-case chapter (§4.1.2, non-normative) spells out what a data owner does when a recipient asks for a footprint it cannot already see:

• “the data owner needs to decide whether to calculate the PCF(s) or not […] the decision making and decision making protocol for this case is up to the discretion of each data owner”;
• if the PCF exists but the recipient has no access, “the data owner decides on making the PCF available or not”, and if not, the host replies with AccessDenied.

⟨Inference: a supplier’s refusal to disclose is a first-class, specified outcome of the protocol, and it is invisible in aggregate — nothing records how often data was withheld or why. The confidentiality problem this wiki tracks is not an edge case the protocol fails to handle; it is handled, by being left to each party’s discretion.⟩

The lifecycle: provenance that is asserted, not proven

§6 is the most substantive piece of original design in the document. A ProductFootprint has an immutable id (UUIDv4), an integer version, created/updated timestamps, a status of Active or Deprecated with an optional statusComment, and precedingPfIds — the set of footprints a new one supersedes.

• Minor change (corrections, updated upstream PCFs, updated secondary data sources): new version, version incremented, updated set; the id and the scope must not change. The enumerated list of properties a minor change may touch is explicit.
• Major change (anything else, e.g. moving from global to sub-regional geographic granularity): a new footprint with a new id, precedingPfIds pointing back, and the predecessors re-issued as a new version with status: Deprecated.
• A deprecated footprint “MUST NOT be changed”.
• Default validity: three years from referencePeriodEnd, unless an explicit validity period is given — which may not start before referencePeriodEnd and may not end more than three years after it.

⟨Inference: this is a provenance graph — lineage, supersession, validity windows — built entirely out of assertions by the data owner. Nothing binds a version to its predecessor cryptographically, so a recipient reconstructing a chain is trusting each hop’s self-report. It is the clearest place in the PACT stack where SINE’s instruments would attach without changing the data model: the fields that would carry proofs already exist as fields that carry claims.⟩

Identifiers: plural by necessity, profiled by the spec

The document declines to name a canonical product identifier, and says why: “What constitutes a suitable product identifier depends on the product, the conventions, contracts, and agreements between the Data Owner and a Data Recipient and is out of the scope of this specification” (§5.1, productIds). What it provides instead is URN namespacing for the systems that exist — GTIN (used in the examples), CAS Registry Numbers, IUPAC InChI codes, and the two custom-code forms urn:pathfinder:product:customcode:buyer-assigned:… and …:vendor-assigned:…, with the mirror-image pair for company identifiers.

⟨Per Martin Pompéry, 2026-11-06: there are no canonical product IDs — there are only several, and profiling them is precisely what the Tech Specs are for. Treating the absence of one as a gap misreads the document and the world; every DPP faces the same condition.⟩

Data model extensions: the slot for everything that is not carbon

ProductFootprint.extensions carries zero or more DataModelExtension objects, each a specVersion, a dataSchema URL and a free data object (§5.5). The example points at catalog.carbon-transparency.com; the mechanism is governed by two separate PACT documents ([DATA-MODEL-EXTENSIONS], [EXTENSIONS-GUIDANCE]).

⟨Inference: this is the extension point through which non-carbon environmental data — circularity, material composition, biodiversity — reaches the same rails and the same installed base of host systems, without reopening the core data model. iLEAP is the worked precedent for logistics. It is also the mechanism by which the network’s governance thins out: an extension is schema plus catalogue entry, with no equivalent of the Framework’s methodological review behind it.⟩

Four discrepancies with the rest of the PACT stack

Recorded, not resolved.

1. DQR shape. The data model carries five indicators — technological, temporal, geographical, completeness, reliability — each “a decimal between 1 and 3 including” (§5.3), matching Framework v2.0. Methodology v3 moves to three indicators on a 1–5 scale (see PACT Data Quality & Verification). Any v2.2 host and any v3 methodology therefore disagree about what a data quality rating is.
2. The exemption threshold moves in two directions. exemptedEmissionsPercent is bounded at 5 % here, with the advisement that “the upper boundary of this property (currently 5) will be removed in version 3 of the Technical Specifications” — while the methodology side tightened the rule to <3 % aggregate. ⟨Inference: these are reconcilable — removing a cap from the data model leaves the constraint to the methodology rather than hard-coding it in the schema — but only if read together, and nothing in either document says so.⟩
3. “Reasonable assurance” survives in the schema. Assurance.level takes limited or reasonable (§5.4), and the §7.10 examples ship "level": "reasonable". The wiki records that the phrase appears nowhere in Methodology v3. The field that would express it is still there.
4. An admitted publication error. Assurance.providerName is mandatory because it “was incorrectly and unintentionally published in V2 of the Technical Specifications as Mandatory”, and “will be reverted to Optional in version 3”.

Also noted: characterizationFactors is deprecated in favour of ipccCharacterizationFactorsSources (2.2.0-20240312) but kept mandatory for backwards compatibility — two mandatory properties carrying the same fact.

The licence is not an open-source licence

Appendix A: licensor is the World Business Council for Sustainable Development; governing law is the State of New York. Users may reproduce the material and create derivatives, but may Share a Reproduction only non-commercially, with attribution and the full licence text. A “Separate Derivative” — explicitly including “a software program […] that uses or implements the information included in the Licensed Material” — may be shared commercially. Termination is automatic on breach, with a 30-day cure period.

⟨Inference: implementations are free; the document is not. Set against the Vision Paper’s stated development approach — “Open-source: all knowledge and technical specifications will be publicly available” — the delivered artefact is publicly readable and commercially implementable, but not openly licensed in the sense that word usually carries. A third instance of the promised-versus-built pattern already recorded for assurance and for the trust mechanisms.⟩

Cross-references

• Pathfinder Network — the entity whose technical layer this document is
• Interoperability profile — the document type, generalised from this one ⟨2026-11-06⟩
• Pathfinder Network Vision Paper (2022) — the five unbuilt pillars this document answers by scoping them out
• Pathfinder Framework v2.0 (2023) — the methodological foundation this protocol encodes
• PACT Methodology v3.0 (2025) — the successor the protocol text keeps forward-referencing
• PACT Data Quality & Verification — DQR and assurance as they appear in the wire format
• The confidentiality gap — the security inventory above is its sharpest instance
• Decision-grade carbon data criteria — criterion B measured against an actual protocol
• ICC Carbon Accounting Landscape Review (2026) — “exchanges data rather than accountable quantities”
• iLEAP — the worked example of a data model extension
• Digital Product Passport — identifier pluralism as a shared condition
• SINE Foundation — pathfinder.sine.dev
• WBCSD — licensor and host

Sources

• sources/standards/2026-10-29-pact-data-exchange-protocol-v2.2.md — this document
• Normative references it profiles: RFC 6749, RFC 6750, RFC 8288, RFC 4122, RFC 2119/8174, OpenID Connect Core §4, CloudEvents (JSON, Structured Content Mode), OData v4