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. Public Beta · 2026-10-19

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.

On the last segment of the name. Since the 2026-08-25 protocol release, identity in UCP denotes party identity — who the agent and the buyer are (dev.ucp.common.identity_linking). This extension is about the product. Inside a vendor namespace the short name is unambiguous and stays as published; should the capability graduate into a governed vertical namespace, its intended name there is product_identity — function-named, in the protocol's own style, and impossible to confuse with the party primitive. The schema and semantics would be unchanged.

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-08-25",
      "spec": "https://ucp.dev/2026-08-25/specification/checkout",
      "schema": "https://ucp.dev/2026-08-25/schemas/shopping/checkout.json"
    }
  ],
  "org.ptpge.print.identity": [
    {
      "version": "2026-10-19",
      "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.

5b · The manifest-level ptpge block

Beside the capability, a printer's manifest carries one small top-level object, ptpge, that tells an agent where the print facts live: the printer's permanent identity in the PTPGE register, its vendor declaration on its own domain, the vocabulary, and the fingerprint resolver. This is the whole of what PTPGE adds to a UCP manifest; the capability above is what it adds to checkout. The manifest form is written down as ucp-manifest/1, one of the five PTPGE documents, and a manifest can be checked against it at ptpge.org/check.

"ptpge": {
  "identity":    "https://ptpge.org/v1/vendors/trykkverk-norge",
  "declaration": "https://trykkverk.no/.well-known/ptpge/declaration.json",
  "vocabulary":  "https://ptpge.org/v1/",
  "fingerprint": { "algorithm": "ptpge-cfs/1", "resolver": "https://ptpge.org/f/" }
}

Live example: trykkverk.no/.well-known/ucp — the pilot printer's manifest, validating against ucp-manifest/1.

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.

7b · The vocabulary contract

Values that name print terms are URIs into the PTPGE vocabulary (https://ptpge.org/v1/): an open vocabulary, governed by the PTPGE association, published in dated, additive releases. Following the UCP Schema Authoring Guide — open string vocabularies with documented well-known values, enum only for provably closed sets — the capability states the four behaviours a receiver needs:

profile and serialization are open strings with well-known values (spec, request, offer; ptpge-cfs/1). Readers MUST tolerate unknown values; a fingerprint with an unknown profile or serialization cannot be verified by that reader.

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.