Skip to content
PDTF PDTF2
Proposed specification for review. We are seeking feedback on key architectural choices in the industry consultation.

Credentials

PDTF 2.0 represents property data as W3C Verifiable Credentials (VCs). Each credential is a signed, portable statement about an entity in the PDTF graph (Property, Title, Transaction, or a relationship entity).

Why credentials

Section titled “Why credentials”

A credential carries its own cryptographic proof. A recipient can verify integrity and issuer identity without trusting the API or database that delivered the JSON.

In PDTF, signatures are necessary but not sufficient. Verifiers also consult the OpenID Federation (relying on Trust Anchors, Federation Entity Statements, and Property Trust Marks like title-data-provider and regulated-conveyancer) to confirm the issuer is authorised for the specific entity:path combinations being asserted.

Sparse credentials

Section titled “Sparse credentials”

PDTF credentials are usually sparse. An EPC issuer does not re-issue a whole Property object. It issues a PropertyCredential containing only the energyEfficiency subtree.

State assembly combines many sparse credentials into a composed view, applying pruning when discriminators change so stale subtrees are removed.

Credential types

Section titled “Credential types”

Credential types align with the entity graph:

  • PropertyCredential and TitleCredential for facts about those entities.
  • Relationship credentials (SellerCapacityCredential, OfferCredential, GiftCredential, RepresentationCredential, TransactionRoleCredential) to express each party’s role and authority.
  • TransactionCredential for sale-specific lifecycle state.

Access control

Section titled “Access control”

VCs can include termsOfUse to express confidentiality and role restrictions. A third party such as a lender is tied to the transaction by its TransactionRoleCredential; how a scoped consent should sit on top of that is an open consultation question.

Revocation

Section titled “Revocation”

Every PDTF credential includes credentialStatus so verifiers can check whether it is still valid. PDTF uses Bitstring Status Lists for scalable revocation.

Where to go next

Section titled “Where to go next”
  • See the protocol specs for the VC data model and revocation.
  • Use @pdtf/core to issue and verify credentials in development.