Trust Architecture

PDTF 2.0 uses a federated trust model where the unit of trust is a credential, not the platform that served it.

A verifier answers three questions:

1. Identity: Who issued this credential? (DID resolution)
2. Integrity: Was it altered? (signature verification)
3. Authority: Is the issuer allowed to make this claim? (OpenID Federation (relying on Trust Anchors, Federation Entity Statements, and Property Trust Marks like title-data-provider and regulated-conveyancer) authorisation)

Signatures are not enough

Anyone can create a DID and sign JSON. A valid signature proves who signed, not whether they are authoritative.

Authority is established via the OpenID Federation, which grants trust at entity:path scope.

Trust roles

PDTF recognises four trust levels:

• rootIssuer: the primary authoritative source
• trustedProxy: an adapter that issues faithfully from a primary source
• accountProvider: a platform trusted to issue or manage user identities
• assertion: a human stating something as true, signed against their verified identity

An assertion is the only level that is not independent confirmation. It is the right level for the large class of facts that no registry holds and only the occupier knows (the TA6 property information form is the canonical case). Its value comes from the binding: the statement is traceable to an identified individual and the liability that attaches to them, which a physically signed form is not. Credentials at this level carry UserAttestation evidence so that verifiers never mistake them for registry data.

Three-phase evolution

PDTF expects trust to evolve:

1. Trusted proxies bootstrap the ecosystem.
2. More independently hosted adapters reduce centralisation.
3. Primary sources issue credentials directly when feasible.

The OpenID Federation is the mechanism that expresses this evolution over time.

Visibility and conflicts

PDTF does not mandate a single conflict resolution policy across the ecosystem. It provides:

• clear issuer identity
• explicit authority scopes
• revocation checks

Consumers (lenders, conveyancers, agents) can choose how to surface or resolve conflicts.

Where to go next

• Read the OpenID Federation spec for governance and caching rules.
• Read the VC data model and revocation specs for verification requirements.