PTI RFC Index
Portable Trust Infrastructure (PTI) normative specifications evolve through Request for Comments (RFC) documents — public proposals reviewed by the community before they become normative.
| Step | Action |
|---|---|
| 1 | Open an issue or discuss in the Working Group |
| 2 | Submit an RFC draft pull request using the template under rfcs/ |
| 3 | Review cycles: Draft → Proposed → Final per RFC process |
| 4 | Conformance tests updated where behavior is normative |
Each RFC is self-contained but cross-references related documents. RFCs use RFC 2119 normative keywords: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and RECOMMENDED.
RFC lifecycle
| Status | Meaning |
|---|---|
| Draft | Under community review; breaking changes permitted |
| Proposed | Stable enough for pilot implementations |
| Final | Normative; backward-compatible changes only via versioning RFC |
| Deprecated | Superseded; implementations SHOULD migrate |
All RFCs listed below are Proposed as of PTI specification v1.0.
RFC catalogue
| RFC | Title | Scope | Status |
|---|---|---|---|
| RFC-001 | PTI Architecture | System layers, roles, data planes, and trust lifecycle | Proposed |
| RFC-002 | Trust Contexts | Context identifiers, isolation, lens derivation | Proposed |
| RFC-003 | Trust Events | Event schema, ingest channels, validation | Proposed |
| RFC-004 | Trust Lookup API | Consumer-facing lookup operations and report tiers | Proposed |
| RFC-005 | Trust Graph | Subject graph model, edges, signal propagation | Proposed |
| RFC-006 | Trust Exchange | Cross-implementation portability and federation | Proposed |
| RFC-007 | Governance | Consent, retention, accountability, audit | Proposed |
| RFC-008 | Security | Authentication, encryption, threat model | Proposed |
| RFC-009 | Privacy | Data minimization, subject rights, purpose binding | Proposed |
| RFC-010 | Versioning | Schema evolution, compatibility, deprecation | Proposed |
| RFC-011 | Identity Resolution | PTI-ID assignment, deduplication, external subjects | Proposed |
| RFC-012 | Trust Evidence | Provenance chains, verification hooks, explainability | Proposed |
Reading order
Implementers building a minimal compatible system SHOULD read RFCs in this order:
- RFC-001 (Architecture) — establishes vocabulary and boundaries
- RFC-002 (Trust Contexts) — scopes all downstream data
- RFC-003 (Trust Events) — producer ingest contract
- RFC-011 (Identity Resolution) — subject identity model
- RFC-005 (Trust Graph) — internal representation
- RFC-012 (Trust Evidence) — outcome provenance
- RFC-004 (Trust Lookup API) — consumer contract
- RFC-007, RFC-008, RFC-009 — governance, security, privacy obligations
- RFC-006, RFC-010 — federation and evolution
Relationship to other documentation
| Document set | Purpose |
|---|---|
| Conformance | Profiles, certification, test categories |
| Build your PTI | Independent implementer guide |
| Specification v1.0 | Operational compliance and explainability guides |
Contributing
RFC changes require a revision PR with:
- Motivation for the change
- Backward-compatibility analysis per RFC-010
- Updated conformance test references where applicable