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

    Preamble — Introductory principles and good practice

    The Preamble sets the foundations the five numbered chapters inherit: ten baseline principles, a common decision-making framework, an interoperability doctrine, and a cross-sector risk register. It explicitly disclaims being a trust framework itself — it aims to "build alignment and coherence across trust frameworks".

    The Preamble names bare “PDTF” (source wording)

    Its "Relationship to legislation, existing trust frameworks and schemes" section lists Open Property and the Property Data Trust Framework (the Guidebook's wording) alongside Open Banking, Open Finance and the Energy Smart Data Scheme. The source document's bare “PDTF” is on the record as a Smart Data initiative — which is both the standing this section is built on and, per the caveat below, a mischaracterisation worth correcting.

    The ten cross-cutting principles

    Every chapter is expected to be read against these. Each is "anchored in statutory obligations under the DUA Act 2025, the UK DVS Trust Framework, and the requirements of UK GDPR".

    1. Consent, user agency and fair treatment. Consent must be meaningful and revocable — but protection must go beyond consent to deliver good outcomes. Consent dashboards, one-click revocation, granular per-item purpose and duration. Where journeys span multiple data holders, consent must be orchestrated, machine-readable, scoped, with revocation propagating to all relying parties without re-consenting the user. Extends to fourth-party disclosure — who ultimately receives the data.
    2. Privacy and lawfulness by design. Minimisation, retention schedules, DPIAs. And the sharpest sentence in the document for a standards body: "Computed outputs (e.g. risk indices) must carry provenance and purpose metadata and support selective disclosure so relying parties receive only what is necessary."
    3. Security and resilience. OpenID FAPI with mutual TLS, DPoP, NCSC guidance, ISO/IEC 27001 and 27701. Entirely a scheme-operator obligation.
    4. Support interoperability and minimise fragmentation. Calls for a "shared semantic layer — a common language of attributes, roles and consent concepts" — and never says who builds it.
    5. Inclusion and accessibility. WCAG 2.2 AA. "Schemes must support assisted and delegated access for vulnerable users, with verifiable delegation and auditable role boundaries."
    6. Transparent governance and accountability. "Schemes should operate or recognise trust registries that publish machine-readable permissions, status/revocations and accreditation/conformance to automate trust decisions."
    7. Proportionality and innovation. Obligations proportionate to risk; room for SMEs and new entrants; tiered compliance.
    8. Evidence-led design. Research, testing, transparent reporting.
    9. Environmental and societal outcomes. Including the energy and carbon footprint of data infrastructure.
    10. Readiness for AI and automation. "Making data AI-ready may involve ensuring data is well-defined, interoperable, machine-readable and accompanied by appropriate provenance, quality and purpose metadata, so that AI-driven use is traceable, accountable and transparent." — which closely matches the purpose of the PDTF schema and the separate ontology extracted from it.

    The eight-category risk taxonomy

    Schemes "should explicitly document which apply and why". The eight cross-sector categories:

    1. Cybersecurity and operational resilience — confidentiality, integrity, availability; amplified by automation and third-party dependencies.
    2. Legal and regulatory — non-compliance with data protection, consumer protection, competition or sector law.
    3. Privacy and data protection — excessive, unclear or unlawful processing, including misuse of consent.
    4. Commercial and market-functioning — misaligned incentives, barriers to entry, SME impact.
    5. Reputational and trust — loss of public confidence.
    6. Ethical and societal — unfairness, bias, exclusion.
    7. Environmental and sustainability — energy, carbon and water footprint of data infrastructure.
    8. National security and systemic — strategic dependency, concentration.
    A numbering collision to watch

    The Preamble presents 8 risk categories, then a section listing risk manifestations under 10 headings that are the principles. The two are easy to conflate. They are kept apart here deliberately.

    The stress-test method

    Performed in the final workshop of each chapter. Reproducibly:

    1. Define a representative sector use case.
    2. Map the user journey step by step (authentication → consent → data access → service delivery → redress).
    3. At each step ask: which risk categories apply here, and how might they challenge the baseline principles?
    4. Record risks against the register template.
    5. Assess baseline controls and residual mitigations.
    6. Identify opportunities preserved — innovation, inclusion, cross-sector portability.

    How DBT governs the Guidebook

    • DBT is steward — maintains the Guidebook, convenes DSIT, OfDIA, DESNZ and the regulators (CMA, FCA, ICO, Ofgem, Ofcom).
    • Sector bodies review drafts and propose sector-specific content. This is OPDA's slot for property.
    • The Smart Data Council provides oversight and reviews major revisions. OPDA's Chair sits on it.
    • Cadence: annual comprehensive review, interim updates after major developments, two-to-three workshops per chapter.

    What this could mean for SPDTF

    Full analysis on the overlap page. In short:

    • Principle 4 and Principle 10 describe questions for SPDTF. A "shared semantic layer" and data that is "machine-readable and accompanied by provenance, quality and purpose metadata" describe an OWL/SKOS/SHACL standard. The PDTF schema and its separately derived ontology are evidence for that work; neither is the collaboratively authored SPDTF scheme draft. This is a substantial opportunity in the document.
    • Principle 2 would need selective disclosure, which the Ed25519 proof suite published alongside the PDTF schema cannot provide. That is a conditional capability question for SPDTF — and it also exposed a defect in OPDA's governance.md, which claimed "selective disclosure enforced". That claim was untrue regardless of what DBT does (gap SD8).
    • Principles 3, 8 and 9 create no data-modelling obligation at all. Say so; do not manufacture ontology work from them.
    • Principle 5 is a trap — half of it is ours. Its WCAG / assisted-channel half is pure scheme-operator territory. But the same principle says schemes "must support assisted and delegated access… with verifiable delegation and auditable role boundaries" — and a verifiable delegation is a data structure, not a screen. That is gap SD5. Waving Principle 5 away as "accessibility" would let a real obligation escape unassigned — exactly the failure this section exists to prevent.

    Caveats on this draft

    • It mischaracterises the programme. The Open Property section says the bare “PDTF” (the source document's wording) is "adopting similar approaches to directory-based onboarding, secure API specifications and consent-driven, portable data-sharing". Directory onboarding and API security are scheme-operator functions; the PDTF schema is an existing JSON Schema implementation. DBT appears to have conflated the standard with the Raidiam sandbox operator layer.
    • "Not a trust framework" — but it behaves like one. It disclaims the status while issuing MUST-flavoured requirements, and notes schemes "may, over time, be expected to align with its principles more formally". Soft law hardening.
    • V5 has visible editorial defects — empty bullets, a duplicated "functional interoperability" paragraph, and an empty second table. Treat quoted text as provisional.

    Comments

    Loading comments…