PATH ID

Subjects, verified identifiers and portable attestations — the pillar that answers who someone is without moving their documents.

LIVE — subjects, identifiers, attestations and ownership bindings. Selective disclosure stays RESERVED. A published revocation register (PATH-ID.Revocation) is not claimed: revocation is checked at read.

What it is for

Verification is expensive and gets repeated. A customer verified by one institution arrives at another and does it all again — same documents, same wait, same abandonment rate. Not because the first verification was inadequate, but because there is no way to carry it that the second institution can check.

PATH ID moves attestations, never documents. The regulated issuer stays the regulated party; the protocol carries a signed statement about what it established, and nothing more.

Three layers, kept apart

This is the part to get right. Most identity failures in payment systems come from merging two of these.

Layer	Question	What goes wrong if merged
Authentication	Is this session the subject it claims?	A signed-in user is treated as having a verified phone number
Identifiers	Does the subject control this identifier?	An unverified number is indexed, and someone else becomes reachable at it
Consent	Did they agree to this disclosure, to this party?	Verified silently means findable, and nobody opted in

An implementation that stores these in one table will eventually make one of the mistakes in the right-hand column.

Two of the three are separate records here — subjects and identifiers. Consent is not: it is carried by the discoverability field on the identifier itself, which records whether the subject may be found and not who they agreed to be found by. So the third column above describes a failure this implementation defends against only partially, and per-counterparty consent is not something it can express today.

The subject

{
  "id": "9f2c41a8-6d1e-4b07-9c3a-2e5f81d0a4b7",
  "subject_type": "natural_person",
  "created_at": "2026-09-09T10:00:00Z"
}

Carries no personal data. Names, dates of birth and documents stay in the operator's own systems, referenced by an internal key the protocol never sees. A subject is a hook to hang identifiers and addresses on, not a profile.

subject_type is natural_person or legal_entity. It is recorded and nothing is derived from it: the discoverability defaults below are chosen by identifier type, not by subject type. The reasoning lands in the same place for the usual cases — an LEI defaults to public, a phone number does not — but it lands there because of what the identifier is, and a company's phone number is treated exactly like anyone else's.

Identifiers

An identifier is something the world already uses to refer to a subject. PATH does not invent new ones.

Type	Form	Notes
`phone`	E.164 — `+12025550123`	Normalisation is part of the protocol
`email`	Lower-cased, trimmed
`bank_account`	`iban:…` or `bban:…`	Scheme in the value, never inferred from a country
`lei`	20 characters, ISO 17442	The global identifier for a legal entity
`reg`	`reg:COUNTRY:REGISTRY:VALUE`	The registry is always named
`tax`	`tax:COUNTRY:VALUE`	VAT, TIN and equivalents

reg:US:EIN:… and reg:US:DUNS:… are two different identifiers of the same US company. Encoding only the country would make them indistinguishable, and where two registries in one country use overlapping numeric formats it would collide two different companies onto one entry. Name the registry.

There is deliberately no siret type. A SIRET is a value of the French SIRET registry. A protocol that puts one country's registry at the top level is that country's protocol.

Normalisation is normative

Two implementations that normalise differently produce different hashes for the same person, and the directory silently splits in two — with no error anywhere. +1 202 555 0123 and +12025550123 must produce the same entry.

Verification

{
  "identifier_type": "phone",
  "verified_at": "2026-09-09T10:02:00Z",
  "verification_method": "otp_sms"
}

verified_at is set only when a method is stated. An unverified identifier may still be registered — it is useful for matching — but a counterparty reading an attestation can tell the difference, which is the only reason to record it.

Reasonable methods per type: a one-time code for phone, a confirmation link for email, a micro-deposit or a payee-name check for bank_account, a registry lookup plus documents for company identifiers.

Discoverability defaults

Per entry, because the threat is not the same per type:

Type	Default
`phone`	`network`
`email`	`network`, separate budget
`bank_account`	`private`
`lei`, `reg`, `tax`	`public`

A migration must never move an entry towards public without an explicit request.

Withdrawal

Applies at the subject level and removes every identifier at once.

Someone who opts out expects every identifier to go with them. Withdrawal is therefore at the subject, not per entry.

Attestations

LIVE

A signed statement by an issuer about a subject. Issued at POST /attestations, read at GET /attestations/{reference} — that read is the execution-time check.

{
  "type": "path.attestation",
  "reference": "9kq3m7vx2pf8dn",
  "subject": "9f2c41a8-6d1e-4b07-9c3a-2e5f81d0a4b7",
  "claim": "kyc_level",
  "value": "standard",
  "issuer": "member-slug",
  "issued_at": "2026-09-09T10:00:00Z",
  "expires_at": "2027-09-09T10:00:00Z",
  "status": "active",
  "issued": { "…": "the envelope signed at issuance" }
}

Closed claims: kyc_level, kyb_level, aml, sanctions, pep, risk_tier, identity_level (0–5). Values are closed per claim — a typo is a 400, not a new level.

issued is the envelope stored byte for byte. Verify the terms against it, never against the live fields beside it.

Three rules that matter more than the shape:

Never settle on a cached credential status. Revocation is checked at execution, not at issuance.

An attestation is a claim, not a document. It says a level was established, by whom and when. It never carries the underlying evidence.

Expiry is mandatory. An attestation without one is a claim about the past presented as a claim about the present.

Selective disclosure — proving "over 18" without revealing a birth date — is RESERVED. It is a real goal and a poor reason to block a first version.

Ownership bindings

LIVE

A proof that this subject controls that identifier, wallet or account. The clear value is hashed and forgotten — the same rule as the directory. A binding does not make anyone findable.

{
  "type": "path.ownership",
  "binding_type": "identifier",
  "target_kind": "phone",
  "target_hash": "8f2b38da…",
  "proof_method": "otp_sms",
  "status": "active"
}

binding_type is identifier, wallet or account. Read at execution (GET /ownership-bindings/{reference}); revoked and expired answer 410.