Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group

    Chapter 1 — Digital Identity, Roles and Trust Frameworks

    "The first mile of every scheme and the anchor for consent, authorisation and interoperability." Chapter 1 is on its seventh draft — the most worked-over document in the Guidebook — and it has the deepest overlap with existing OPDA evidence. The PDTF schema provides the Digital Property Pack structure; the separate ontology extracted from it models participants, roles, DIDs, verifiable credentials and a trust registry — though not assurance levels, which were removed from the corpus in July 2026.

    Minimum Viable Identity

    The chapter's central heuristic — "to reduce fragmentation, duplication and inconsistent assurance approaches across the economy". Four elements:

    1. Persistent identifier — stable across sessions, consent events and multi-provider journeys; supports revocation and expiry.
    2. Authentication protocol — recognised open standards (OIDC, OAuth 2.0, FAPI), risk-based, supporting assurance elevation.
    3. Role assertion — a standardised way to assert a role (ATP, data holder, issuer, identity provider, end-user) including the scope of permitted actions.
    4. Accountability role — who issued the assertion, who relies on it, and who is accountable if it becomes invalid or misused.

    It is explicitly "a suggested design heuristic, not a formal standard". The key default: "Where identity verification is required and outsourced, DVS is the default."

    The role catalogue

    Chapter 1's roles are infrastructure roles — who does what in a data-sharing scheme:

    RoleWhat it is
    Data holderHolds consumer data and provides regulated access. Notably: in Open Banking they are "prohibited from validating or re-interpreting consent directly".
    Authorised Third Party (ATP)Accredited to access data on behalf of a consumer. Defined by consumption + consent-handling + accreditation.
    Interface bodyCoordinates onboarding, accreditation, directories and technical standards.
    Relying partyRelies on identity/attribute assertions. Must check status at the point of reliance.
    Issuer"A trusted party responsible for issuing specific credentials. These may relate to property, organisational identity, regulatory status…"
    Authoritative source / trust anchorThe primary origin of a type of information; root of trust for the scheme.
    DVS rolesIDSP (identity), ASP (attributes), HSP (holder/wallet), OSP (orchestration), CSP (components) — imported wholesale from the DVS Trust Framework.
    These are not the existing model's transaction roles — and that is the point

    The PDTF schema and its derived ontology represent transaction roles (Seller, Buyer, Conveyancer, Estate Agent, Lender, Surveyor). DBT's are infrastructure roles. They are orthogonal axes, not competing lists — a conveyancer is simultaneously a data holder, an ATP, a relying party and an issuer depending on the flow. Full analysis: the role-model collision.

    The six-stage scheme lifecycle

    1. Scheme setup and governance — legal basis; the interface body defines standards and operates trust services.
    2. Participant onboarding — ATPs demonstrate capability and get accredited. Crucially: "Identity providers and credential issuers are not normally onboarded as scheme participants" — schemes rely on external DVS certification instead.
    3. Consumer initiation — consent captured and evidenced "through standardised machine-readable trust signals".
    4. Data access and sharing — the data holder verifies consent signals and ATP accreditation, then releases data.
    5. Ongoing operation — consent renewal and withdrawal; credential status maintained.
    6. Oversight, audit and enforcement — conformance (scheme rules) split from enforcement (statutory breaches).

    Credential types and the CBOM

    1. Identity/attribute evidence from DVS-certified services — the Trust Framework certifies services and provider roles, not identities.
    2. OAuth / OIDC tokens — short-lived, scoped access authorisation.
    3. Verifiable credentials — portable, tamper-evident proofs (W3C VC models, status lists).
    4. Sector-specific credentials — statutory or regulatory authorisations.

    Cutting across all four is the Credential Bill of Materials (CBOM): per journey step, the credential format, its issuer/holder/verifier, assurance type, and status/expiry/ revocation endpoints. "Relying parties should perform status checks at the point of reliance."

    The CBOM is OPDA's open goal

    The schema-derived ontology has most ingredients — VC types, issuers and a Bitstring Status List. It lacks the assurance type per credential (opda:assuranceLevel was removed on 2026-07-05 per ODR-0009 — gap SD13). Address that through SPDTF governance, and a CBOM projection compatible with the PDTF schema becomes a visible way to show how the existing schema could inform a property Smart Data scheme, should one be established.

    The six design guardrails

    What schemes must not do:

    1. Over-centralise identity or consent flows.
    2. Mandate external identity providers where not proportionate.
    3. Unbounded credential reuse — credentials issued for one purpose must not be reused for unrelated ones.
    4. Opaque delegation chains — "all delegation must be verifiable. 'Password sharing' or unverifiable proxies must not be permitted."
    5. Fragmented role definitions — "roles must be aligned with cross-sector patterns to avoid ambiguity". Read this one carefully — see below.
    6. Failure to maintain revocation or suspension information — "relying on stale trust signals is a systemic risk".

    What this could mean for SPDTF

    Full table on the overlap page. The load-bearing findings:

    • Power of Attorney, deputyship and executors must be "verifiable delegation credentials". Chapter 1 names PoA as a mechanism used across finance, energy and property. Neither the PDTF schema nor its derived ontology has a delegation model; SPDTF participants must decide whether and how to model it, and property is the delegation-heavy sector (gap SD5).
    • Selective disclosure is unsupported — the Ed25519 proof suite published alongside the PDTF schema cannot provide it. The Guidebook's ask is conditional; our own published claim that we already support it was not (gap SD8).
    • The consent gap is the strategic exposure. Stage 3/4 presupposes a machine-readable consent object that data holders must not re-interpret. Neither the PDTF schema nor the schema-derived ontology can emit one; whether SPDTF should model it is an open question. Every other sector has an answer; property has nothing named.
    • Guardrail 5 is an unbounded demand. Read literally it invites a future editor to require property schemes to adopt data-holder/ATP terminology in place of Seller/Buyer/Conveyancer. DBT has promised a cross-reference table; OPDA should supply the property column rather than have it drafted for us.
    • "Schemes should rely on DVS certification, not accredit identity providers themselves" cuts against KYC/KYB issuer onboarding in the separate trust-framework material produced alongside the PDTF schema. The reconciliation: its issuers are not identity providers, they are issuers of facts about properties — and DVS has no certification route for "issuer of a fact about a building". Nobody certifies HM Land Registry as an ASP. Say this plainly and early, or risk being told the accreditation function is redundant when it demonstrably is not.

    Caveats on this draft

    • It cannot decide what the standard is. One passage calls the bare "PDTF" (source wording) a peer of Open Banking and DVS; another calls it "a sandbox environment rather than operating as a statutory or mandated framework". Push for consistent framing — the sandbox sentence describes a pilot deployment, not the PDTF schema.
    • The property section is stale. It says Open Property aligns to DIATF patterns — while the same chapter states DIATF has been superseded by the statutory DVS Trust Framework.
    • Almost everything is deferred — diagrams, the cross-reference table, conformance detail, role allocation. The 17 model clauses are the live surface: they are the only text concrete enough to become scheme regulation.

    Comments

    Loading comments…