Skip to main content

Specification vs Implementation

Confusion between the standard and a product undermines portability, certification, and procurement. This document defines boundaries among four distinct entities in the PTI ecosystem.

The four layers

1. PTI Specification

The PTI Specification is the vendor-neutral normative definition of Portable Trust Infrastructure.

AttributeDescription
FormNumbered RFCs plus the integrated Specification v1.0 bundle
OwnershipPublic standard; no single company owns the category
Change controlRFC process and Working Group approval
CompatibilityDeclared via version management and RFC-010

The specification MUST NOT reference proprietary APIs, unreleased product features, or vendor-specific identifiers as normative requirements.

Examples of specification artifacts:

  • RFC-003 trust event schema
  • RFC-004 lookup tier definitions
  • Conformance profile capability matrices (published under Conformance)

2. TumiTrust (reference implementation)

TumiTrust is a commercial trust platform that implements PTI. It is the current reference implementation and founding steward — not the specification itself.

TumiTrust is…TumiTrust is not…
An example of how RFCs map to production servicesThe sole valid PTI deployment
A source of interoperability test vectorsA gatekeeper for who may implement PTI
A steward during early ecosystem phasesOwner of the PTI trademark category in perpetuity
A contributor to RFCs and conformance testsA substitute for independent certification

Product documentation under /tumitrust/ describes TumiTrust behavior. When TumiTrust diverges from published RFCs, the RFCs govern compatibility claims until amended through governance.

See Reference Implementation Policy.

3. PTI Working Group

The PTI Working Group is the community body that stewards specification evolution.

ResponsibilityOut of scope
Review and accept RFCsOperating production registries
Appoint review boards (ARB, SRG)Commercial partner negotiations
Publish governance and process docsCertifying implementations (delegated to Conformance Program)
Coordinate security disclosureLegal advice to implementers

Membership is open per Working Group and Community Participation policies. During Phase 1, operational support may be provided by the founding steward's infrastructure.

4. Conformance Program

The Conformance Program translates normative RFCs into testable, certifiable claims.

ComponentLocation
ProfilesConformance profiles
Test suitesConformance tests
Certification rulesCertification guide
Program governanceConformance Program, Certification Process

An implementation MAY be fully functional yet not PTI-compatible if it fails required tests. Conversely, a minimal implementation MAY certify for a narrow profile (e.g., Core) without implementing every optional capability.

Comparison matrix

DimensionSpecificationWorking GroupConformance ProgramTumiTrust
Primary outputRFCsDecisions, processCertificates, testsRunning platform
Binding on othersNormative for compatibilityProcess rulesCertification requirementsContractual to customers
Vendor-neutralMUST beMUST beMUST beProduct (neutral spec, branded product)
Open participationVia contributionsYesAccredited labs + self-assessmentCommercial

Common misconceptions

MisconceptionCorrection
"PTI is TumiTrust's API"PTI is defined by RFCs; TumiTrust exposes one compatible API surface
"You need TumiTrust to build PTI"See Build Your Own PTI
"Working Group approval equals certification"Certification requires conformance testing per profile
"RFC-007 governs the Working Group"RFC-007 governs in-platform trust data; this section governs the ecosystem

Language for public communication

When describing offerings:

AcceptableUnacceptable
"PTI-compatible Core profile, v1.0""PTI-certified" without certificate
"Implements RFC-003 and RFC-004""The official PTI platform" (implies exclusivity)
"Reference implementation based on TumiTrust""PTI powered by [vendor]" as if vendor owns PTI
"Submitted RFC draft for community review""PTI standard includes our proprietary feature"