Trust Over IP — the governance model PDTF follows

    PDTF has publicly committed to the Trust Over IP (ToIP) Foundation's 4-layer governance model. This is the most consequential governance decision in the project — it shapes what we do not need to invent and what we do need to codify.

    Quoted directly

    "PDTF follows the Trust Over IP (ToIP) governance model, mapping proven internet trust patterns to property data."

    Source: source/07-website/related-domains/propdata.org.uk/about.html

    Provenance: propdata.org.uk is a legacy developer site that carries OPDA copyright but was not authored or approved by OPDA (OPDA has no editing access). The technical approaches it maps onto these layers — notably DIDComm and the DID methods below — are exploratory, not yet OPDA / MHCLG / DPMSG-ratified, and still to be tested and certified against the emerging Smart Data Guidebook and aligned to the DSIT Digital Verification Services standards.

    Why ToIP — and why not DCAM

    DCAM (EDM Council's Data Management Capability Assessment Model) assumes a single accountable enterprise governing data inside its walls. That's not OPDA. OPDA is a federated standards body — its "data" is the agreement between many independent organisations on what data means, how to share it verifiably, and who is allowed to issue or rely on what claims.

    ToIP was built specifically for that shape: federated trust frameworks. It has an explicit two-stack model at every layer — one technical stack, one governance stack — and PDTF needs both.

    The four layers

    flowchart TB L4["`**Layer 4 — Application Ecosystems** PDTF · OPDA · DPMSG Industry rules and standards`"]:::infra L3["`**Layer 3 — Credential Exchange** OIDC Verified Claims → VCs How claims are formatted and shared`"]:::service L2["`**Layer 2 — Secure Communication** HTTPS · DIDComm How data is transmitted securely`"]:::security L1["`**Layer 1 — Utility / Network** TCP/IP · IETF standards Foundation infrastructure`"]:::process L4 --> L3 --> L2 --> L1
    PDTF's published mapping. Each layer has a technical stack and a governance stack.

    What each layer needs as a governance document

    LayerTech stack (PDTF)Governance document we need
    L4 — Application ecosystems PDTF rules, OPDA membership, DPMSG decisions, accreditation scheme Ecosystem Governance Framework — purpose, scope, who decides what, change-management process, conformance criteria
    L3 — Credential exchange OIDC + Verified Claims → W3C VCs Credential Trust Framework — which credentials, which issuers can issue what, validity/revocation rules, presentation format
    L2 — Secure communication HTTPS, DIDComm Communication Governance — required TLS profile, DIDComm version, endpoint discovery, security audit cadence
    L1 — Utility / network DID methods (key, web, ion) Utility Governance — which DID methods are allowed, trust-registry data structures, key rotation policy

    Orthogonal governance documents

    Cutting across all four layers, ToIP-style trust frameworks need a set of cross-cutting governance documents:

    Cross-cutting

    Conformance & Certification

    How members prove they meet the standard. Open Banking-style scheme.

    Cross-cutting

    Change Management Process

    How a schema, overlay, or rule changes — proposal → impact assessment → consultation → release. Templates already exist in trust-framework/docs/.

    Cross-cutting

    Data Quality Framework

    Verified Claims dimensions (completeness, timeliness, authoritativeness). Maps to JSON Schema validation + VC provenance.

    Cross-cutting

    Lifecycle & Versioning

    Semantic versioning, deprecation policy, NTS-style retirement when underlying regulation is withdrawn.

    Cross-cutting

    Risk & Liability Allocation

    Who is liable when data is wrong. Tested in the Sandbox phase.

    Cross-cutting

    Disputes & Redress

    Process for raising and resolving issues between participants.

    Cross-cutting

    Trust Registry

    Authoritative list of accredited issuers, verifiers and their credentials. Spans all four layers — see governance.md §4.

    What OPDA already has (don't reinvent)

    The source/03-standards/trust-framework/docs/ directory already contains:

    The job isn't to write these from scratch. The job is to:

    1. Re-bucket them under the ToIP four layers so each layer has a clear governance doc.
    2. Fill the orthogonal gaps (conformance scheme, liability allocation, disputes & redress).
    3. Map every document to the UK initiative tier it relates to (MHCLG / DSIT / DPMSG / etc.) so government partners can navigate the framework.

    The Open Banking parallel

    Worth borrowing patterns from. Open Banking's governance has matured through:

    • OBL (Open Banking Limited) — the standards body, separate from regulators
    • JROC (Joint Regulatory Oversight Committee) — multi-regulator coordination
    • Conformance & certification — annual re-certification, technical conformance suites
    • Funding model — cost-recovery through participant fees
    • Public consultation for any spec change
    • Standards version cadence — predictable release intervals

    Raidiam — the Sandbox technical partner (see Raidiam slides Open Property sandbox.pdf) — built the Brazil and UK Open Banking infrastructure. They bring the operational patterns into OPDA's Sandbox directly.

    Proposed governance document set

    The structure I'd propose for source/00-deliverables/governance/:

    00-deliverables/governance/
    ├── 00-context-uk-initiative.md      (links to this docs site)
    ├── L1-utility-governance.md         ToIP Layer 1
    ├── L2-secure-communication.md       ToIP Layer 2
    ├── L3-credential-exchange.md        ToIP Layer 3
    ├── L4-ecosystem-governance.md       ToIP Layer 4 — biggest doc
    ├── conformance-and-certification.md cross-cutting
    ├── change-management.md             cross-cutting (consolidates existing templates)
    ├── data-quality-framework.md        cross-cutting
    ├── lifecycle-and-versioning.md      cross-cutting
    ├── risk-and-liability.md            cross-cutting
    ├── disputes-and-redress.md          cross-cutting
    └── strategic-alignment.md           how this maps to HMLR/DSIT/DVSTF/Open Banking

    Each document follows the same structure: purpose, scope, what's already in place (citing existing OPDA artefacts), gap analysis, proposed operating model, KPIs.

    Comments

    Loading comments…