org.ptpge.print.identity
PTPGE Product Identity

Adds the PTPGE configuration fingerprint — the open, computable identity of a print product configuration — to UCP checkout line items. Working draft 0.1 · 2026-08-05

1 · Purpose

Agentic commerce needs one thing the base protocol deliberately leaves open: an exact, universal answer to "is this the same product?". In the UCP base schemas, an item's id is the merchant's own product identifier — bilateral: meaningful between two parties that already know each other, and meaningless to everyone else. This extension adds the universal counterpart next to it: the PTPGE configuration fingerprint, a SHA-256 over the open canonical serialization (ptpge-cfs/1) of the product configuration. The merchant's id says what this item is called here; the fingerprint says what it is — computable by anyone, verifiable by anyone, owned by no one.

2 · Name and governance

UCP encodes governance into capability names through reverse-domain namespaces. Under the protocol's governance model, the namespace org.ptpge.* is governed by the holder of ptpge.org, and the spec and schema URLs of every capability in the namespace MUST have origin https://ptpge.org/… — platforms validate this binding. The extension therefore requires nobody's permission to exist, and its authority is checkable by construction.

3 · What it adds

One optional object, ptpge, on the item inside checkout line_items:

The fingerprint identifies the manufacturable configuration — never the transaction, the price, the promise or the file. Every fingerprint resolves to a permanent public page at https://ptpge.org/f/{fingerprint}, and every fingerprint can be re-verified by recomputation from the open specification with no account and no API. In the base item object, price sits beside ptpge as a sibling field: the vendor's claim and the product's identity travel side by side, and neither contaminates the other. Ten businesses can quote the same fingerprint at ten prices — which is precisely what makes an agent's price comparison honest.

4 · Schema

The full JSON Schema is published at /ucp/schemas/identity.json. It follows the protocol's extension pattern: $defs keyed by the full parent capability name, composition via allOf, and a requires block declaring version constraints.

5 · Declaring the capability

A business declares the extension in its profile at /.well-known/ucp, alongside the parent capability:

"capabilities": {
  "dev.ucp.shopping.checkout": [
    {
      "version": "2026-04-08",
      "spec": "https://ucp.dev/2026-04-08/specification/checkout",
      "schema": "https://ucp.dev/2026-04-08/schemas/shopping/checkout.json"
    }
  ],
  "org.ptpge.print.identity": [
    {
      "version": "2026-08-05",
      "spec": "https://ptpge.org/ucp/identity",
      "schema": "https://ptpge.org/ucp/schemas/identity.json",
      "extends": "dev.ucp.shopping.checkout"
    }
  ]
}

Negotiation follows the protocol's server-selects intersection: the extension is active only when both parties declare it, and when it is not active, checkout proceeds exactly as before. Adoption is strictly additive: no existing integration changes behaviour, and no party is ever required to implement it.

6 · Example

"line_items": [{
  "item": {
    "id": "BRO-ACC-A5-4211",
    "title": "Accordion brochure A5",
    "ptpge": {
      "fingerprint": "f2e377cbb004c4e628180d877f8b1e008a7055e5d699140ecb8f3bf0a73f5df1",
      "profile": "spec",
      "serialization": "ptpge-cfs/1"
    }
  },
  "quantity": 500
}]

This reference fingerprint is live: resolve it at ptpge.org/f/f2e377cbb004c4e6, or recompute it from the worked example in the PTPGE integration guide. The corresponding offer-profile vector (the same configuration plus quantity) is ad112a406169f743….

7 · Validation and verification

Receiving platforms SHOULD validate the fingerprint pattern as part of normal composed-schema validation. Beyond that, two independent checks are available to any party, neither requiring an account or an API key: lookup — fetch https://ptpge.org/f/{fingerprint} and read what the identity means and, for offers, who stands behind it; recomputation — rebuild the canonical serialization from the open specification and confirm the hash matches. Everything the extension transports is verifiable without its author, which is the property that makes it safe to adopt.

8 · Non-goals

The extension carries identity and nothing else. It does not carry price, availability, delivery promises, order state, payment data or file requirements — those belong to the base protocol, its official extensions and the file-format standards, and remain exactly where they are. It reaches into no system: it is one optional object on an existing type.

9 · Relationship to a print vertical under dev.ucp.*

This extension is deliberately designed to be superseded: should a print vertical sanctioned by the UCP governing body carry a product-identity field natively under dev.ucp.*, these semantics transfer unchanged — the fingerprint, the register and the verification model are defined independently of the carrier, and org.ptpge.print.identity remains as the compatibility path for early adopters. The extension exists so that no implementer has to wait; it succeeds equally in being adopted and in being absorbed.