GitHub

Docs

Conformance

Named, testable profiles — so that "supports PATH" becomes a claim a third party can check rather than a marketing line.

DRAFT

Nobody claims "PATH compliance"

An implementation declares profiles and a version:

Fig. 01 — A declaration

PATH-ID.Core + PATH-ADDR.Format + PATH-REQ.Link, v0.1

Not "PATH compliant", which is unfalsifiable and therefore worthless to whoever is reading it.

The declaration lives in the discovery document, and anyone can run the suite against it without permission.

Two families

The split matters as much as the profiles themselves.

Open profiles — ring 1

Implementable by anyone, with no membership and no permission.

ProfileRequires
PATH-CORE.DiscoveryDiscovery document, versions, published keys
PATH-ID.CoreSubjects, verified identifiers, policies, revocation
PATH-ADDR.FormatAddress format, resolution to capability, signatures
PATH-ADDR.StandingStanding intent and inbound states
PATH-REQ.LinkIssue and serve a signed payment request with disclosed fees
PATH-REQ.PayerRead another issuer's request, verify it, pay it, obtain the receipt
PATH-REQ.CheckoutCheckout sessions and the hand-back
PATH-CONNECT.CoreConnection objects, scope, counters
PATH-CONNECT.DelegationDelegation with binds_to and exposed counters
PATH-FINDER.RelationshipResolution with no index and no membership
PATH-INTEROP.ReadParse both forms, refuse unanchored input, verify sig when present
PATH-INTEROP.IssueEmit signed HTTPS URIs; path: only as an alias; op= never on HTTPS
PATH-INTEROP.PayTestable: declared accepts rails, a resolving rulebook, a declared certificate origin

PATH-INTEROP.Pay is a third profile, not a rename of Issue. An acquirer that only scans declares Read. An issuer that never pays declares Issue. Pay is the claim you can fail a suite on: rails, rulebook, certificate origin.

| PATH-SETTLE.Receipts | Signed receipts and reconciliation |

PATH-FINDER.Relationship is the load-bearing one. It is the complete path from key to capability that requires membership of nothing. An implementation that passes it demonstrates the open ring is real, which is why it is worth claiming even when you are also a network member.

Network profiles — ring 2

These require admission to a club. Technical conformance alone is never sufficient.

ProfileRequires
PATH-FINDER.DirectoryFull reachability — step 1 then step 2, against a network's index
PATH-NETWORK.MemberMutual resolution, opposable caps, audit
PATH-SONAR.ClientQuery the index, verify signed answers, respect budgets
PATH-SONAR.RegistrantRegister entries in the index
PATH-SONAR.OperatorOperate an index — with retention and audit obligations
PATH-NETWORK.ComplianceCounterparty data exchange on the network channel
PATH-NETWORK.DisputesDisputes and the rulebook

Levels

LevelMeaning
DeclaredStated in the discovery document. Engages the implementer
VerifiedA third party ran the suite and it passed
AuditedIndependently reviewed — for PATH-SONAR.Operator, whose obligations are ongoing rather than testable at a point in time

Most implementations sit at Declared, and that is fine. It is not nothing: a profile announced and not honoured is a non-conformity, not an approximation, and the suite exists to contradict it.

What the suite checks

Beyond happy paths, the cases that matter:

Constant-shape negatives. An unknown key and a hidden key must produce identical responses, including timing. This is the check most implementations fail first.

Canonicalisation. Signed objects must verify against vectors produced by an independent implementation. A serialiser that only agrees with itself passes every internal test and nothing else.

Reserved fields survive. An object carrying a populated reserved field must round-trip unchanged, not be rejected or silently stripped.

Version transforms. A caller pinned to an older date gets the older shape.

Revocation at execution. An authorisation revoked after issuance must fail at use, not at issue.

Withdrawal is total. Withdrawing a subject removes every identifier, not the one that was asked about.

Running it

npx @pathprotocol/conformance --target https://api.example.com --profiles PATH-REQ.Link,PATH-ADDR.Format

The suite is published alongside the reference implementation. It runs against any operator's public surface with no credential for the open profiles — which is the point: verification that needs the implementer's cooperation is not verification.

Publishing results

{
  "conformance": ["PATH-ID.Core", "PATH-ADDR.Format", "PATH-REQ.Link"],
  "conformance_verified": [
    {
      "profile": "PATH-REQ.Link",
      "path_version": "0.1.0",
      "verified_at": "2026-09-09T10:00:00Z",
      "verified_by": "third-party-slug",
      "report": "https://…"
    }
  ]
}

Declaring is free and engages you. Verifying costs a test run and means something.


On this page