Rework 009 Dataspace Trust Frameworks - #130
Conversation
Rework 009 into an operational framework definition: claims must carry provenance, validity, status, and holder binding; external facts enter evaluation as attested claims instead of "decentralized oracles"; failure modes extended from two to eleven with required handling; new trust-anchor register, issuer-accountability, and conformance rules; "fully decentralized" corrected to explicit governance-plane dependencies; certification/broker models subsumed instead of invalidated. Adds sections on required DTF content, operational binding, verified self-description catalogues, and framework limits. Full delta in CHANGELOG.md.
…xamples Add before/after grounding and concrete examples to the 009 Trust Frameworks changelog bullets: claim-metadata delta, decentralized-oracle misconception, reconciliation downgraded to a governance artefact, disclosure-minimising error rationale, per-claim-type anchor scoping example, issuer-accountability delta, and empty-constraint-intersection example.
|
That is quite a good addition to the current Rulebook content. Thanks @noVaSon ! I will provide some more detailed feedback in the next few days. The text needs further linguistic improvements and alignment with related sources. Please also check this PR in the IDS RAM https://github.com/International-Data-Spaces-Association/IDS-RAM/pull/106 |
PeterKoen-MSFT
left a comment
PeterKoen-MSFT
left a comment
There was a problem hiding this comment.
There are many places where definition and implementation are mixed together. Also a core misunderstanding seems to be that a DTF merely defines policies and claims. It doesn't provide any implementations and doesn't have any authority over the data space. There is a bit of a misunderstanding of the roles of a DSGA vs a DTF in this contribution.
| ## Definition | ||
|
|
||
| A **Dataspace Trust Framework (DTF)** consists of a set of policies and reconciliation mechanisms for claims, as well as business process definitions that enable data space participants to establish trust and maintain mutual assurance in data sharing interactions. Trust is treated as a dynamic runtime property, derived from verifiable claims and policy alignments, rather than static certifications or centralized attestations. | ||
| A **Dataspace Trust Framework (DTF)** is the binding set of rules that tells data space participants how trust evidence is created, checked, accepted, rejected, and governed for data-sharing interactions. It combines policies, accepted claims, trust anchors, reconciliation rules, and business procedures into one operational framework. |
There was a problem hiding this comment.
I would disagree with this. The DTF doesn't tell you the HOW. It tells you the WHAT. Which policies exist, and what do they represent. They don't tell you what code to write to implement them. Also business processes are expressed as policies, not as a mandatory business framework that the participant must implement exactly to the dot.
so while I agree with the sentiment of the sentence, it needs to be more precise. See original statement: a DTG contains policies, and the reconciliation mechanisms (e.g. set of potential claims), but it doesn't tell the participant how to implement that policy. A subtle but important difference: definition vs implementation.
There was a problem hiding this comment.
Agreed — definition vs implementation is the yardstick I'm applying to the whole rework: every
"how" formulation becomes a statement of what a DTF defines. Applied to the definition
sentence in 2da63d2.
| A **Dataspace Trust Framework (DTF)** consists of a set of policies and reconciliation mechanisms for claims, as well as business process definitions that enable data space participants to establish trust and maintain mutual assurance in data sharing interactions. Trust is treated as a dynamic runtime property, derived from verifiable claims and policy alignments, rather than static certifications or centralized attestations. | ||
| A **Dataspace Trust Framework (DTF)** is the binding set of rules that tells data space participants how trust evidence is created, checked, accepted, rejected, and governed for data-sharing interactions. It combines policies, accepted claims, trust anchors, reconciliation rules, and business procedures into one operational framework. | ||
|
|
||
| The DTF sits between the general concept of [Trust](008_Trust.md) and the concrete mechanisms for [Establishing Trust](103_Establishing_Trust.md). Those sections explain what trust means in a data space and why attribute-based trust is the preferred model. The DTF makes that model executable: it states which evidence counts, which rules the evidence is checked against, who may issue that evidence, how disagreements are handled, and what happens when checks fail. |
There was a problem hiding this comment.
again, the wording is problematic: the DTF doesn't make it executable as it doesn't provide an implementation. It provides a definition. It enabled the implementation of a concrete execution model, but it doesn't provide it.
There was a problem hiding this comment.
Agreed — a DTF enables an implementation, it doesn't provide one. Reworded exactly that way in
2da63d2.
|
|
||
| Trust in a DTF is not a permanent status. It is a local, purpose-specific, and time-bound assessment made by each participant for a concrete interaction. Certifications, membership credentials, and onboarding results may be accepted as evidence, but they do not create standing trust by themselves. They are claims whose issuer, validity, scope, holder binding, and revocation status must be checked according to the framework. This follows the zero-trust principle that access decisions depend on current evidence and explicit policy alignment, not on prior admission alone ([NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)). | ||
|
|
||
| A DTF therefore does not make participants trustworthy. It makes the grounds for trust explicit, verifiable, repeatable, revocable, and auditable. |
There was a problem hiding this comment.
this is a bit of an AI-Slop statement. A DTF doesn't make trust explicit, nor directly verifiable, repeatable or create revocability and auditability. That is depending on the implementation details. All it does is providing the semantic model and definitions for the policies and claims.
We need to be careful to not mix implementation into definition with the DTF.
There was a problem hiding this comment.
Accepted. Intended meaning was: the DTF provides the definitions against which an
implementation can make trust verifiable, revocable, auditable — the properties belong to the
implementation. Reworded to say exactly that in 2da63d2.
| - **Claim:** A machine-readable, cryptographically verifiable assertion issued by a trusted authority about a participant or an asset (for example, an identity attribute, certification, or dataset provenance). Claims serve as primary evidence in trust evaluations and must include provenance and validity metadata. | ||
| - **Claim**: A machine-readable, cryptographically verifiable assertion about a participant, service, asset, or event, issued by an identifiable issuer. Claims can express identity attributes, membership, certifications, dataset provenance, compliance results, or operational facts. The relation between attributes, claims, and trust anchors is described in [Attributes & Claims](104_Attributes_and_claims.md). | ||
|
|
||
| - **Policy**: A machine-readable expression of rules that govern data discovery, access, contract negotiation, usage, obligations, and enforcement expectations. Policy design is covered in [Policies](105_Policies.md). |
There was a problem hiding this comment.
the list is a bit arbitrary as it mixes different levels of detail. At a high level there is discovery, negotiation, and sharing. While usage, access, enforcement are implementation details of the sharing process. I would suggest to go back to the original statement or clean this up.
Also the statement defining what a policy is, is important, however, it's correct that that should be covered by the policies document.
There was a problem hiding this comment.
Accepted — done in 2da63d2: the list reverts to the high-level triple (discovery, negotiation,
sharing) and the policy definition defers to the policies chapter instead of restating it.
|
|
||
| - **Policy**: A machine-readable expression of rules that govern data discovery, access, contract negotiation, usage, obligations, and enforcement expectations. Policy design is covered in [Policies](105_Policies.md). | ||
|
|
||
| - **Trust anchor**: An issuer, or a defined set of issuers, whose claims a verifier accepts as evidence for specified claim types. A trust anchor is not a general authority over the data space. Its role is scoped by the DTF: which claims it may issue, how its keys are discovered, how status is checked, and which accountability obligations it accepts. |
There was a problem hiding this comment.
it is not just scoped by the DTF, it must be scoped by the participant. which might differ from the DTF scope. The participant scope always overrides the DTF scope!
There was a problem hiding this comment.
Agreed. I've opened #139 to formalize exactly that layering: the DTF proposes
issuer-acceptance criteria per claim type, the DSGA adopts them as a governance decision, and
the participant decides — free to narrow or override any proposed scope.
|
|
||
| A DTF defines the mechanics of evidence and evaluation. It does not solve every trust problem. | ||
|
|
||
| - **Recognition between data spaces**: Whether one data space accepts another data space's trust anchors is a governance decision involving liability, semantics, risk tolerance, and business incentives. No protocol can force recognition. Cross-data-space common agreements are discussed in [Interoperability in Data Spaces](115_Interoperability_in_data_spaces.md). |
There was a problem hiding this comment.
wrong. A data space cannot accept any other data space. A participant must be a member of both data spaces if data needs to be shared in two different data spaces and conflict resolution happens at the participant level. DSGAs can merely suggest pre-negotiation DTF conflict resolution.
There was a problem hiding this comment.
Accepted — dual membership, with conflict resolution at the participant level; the paragraph
will be corrected accordingly. The adjacent definitional question — that cross-vocabulary
equivalences must be explicitly agreed rather than silently mapped — is #140.
|
|
||
| - **Recognition between data spaces**: Whether one data space accepts another data space's trust anchors is a governance decision involving liability, semantics, risk tolerance, and business incentives. No protocol can force recognition. Cross-data-space common agreements are discussed in [Interoperability in Data Spaces](115_Interoperability_in_data_spaces.md). | ||
|
|
||
| - **Participation**: A DTF lowers the cost and risk of trusting, but it does not create a business reason to share data. Adoption depends on demand, regulation, incentives, and implementation quality. |
There was a problem hiding this comment.
a bit of a non-sensical statement. A DTF is simply a list of policies and acceptable claims. It provides no guarantees about business risk mitigation or implementation...
|
|
||
| - **Post-transfer enforcement**: Once data has been delivered to another participant, technical control is limited. Deletion, non-onward-sharing, and usage limits are contractual or legal obligations unless the data is processed in a controlled technical environment. | ||
|
|
||
| - **Claim truth**: Verification proves that an accepted issuer signed a claim and that the claim satisfies technical checks. It does not prove that the issuer was correct. Truthfulness depends on issuer competence, accountability, audit, and liability. |
There was a problem hiding this comment.
small but important detail: Verification proves that an issuer signed a claim. whether it is accepted or not is to be evaluated by the participant. Truthfulness is the wrong wording here... an issuer who satisfies all those attributes could still choose to not be truthful. (or have an ambiguous truth).
All the verification does is authenticate the claim to represent the evidence. It doesn't make any statement about the validity, truthfulness, completeness or trustworthiness of the evidence.
There was a problem hiding this comment.
Agreed — that's a precise and useful correction. Adopted in 2da63d2: verification
authenticates a claim as the evidence presented; it makes no statement about validity,
truthfulness, completeness, or trustworthiness of the evidence. Acceptance of the issuer is the
participant's evaluation.
| - Use standards like DID (Decentralized Identifiers), VCs (Verifiable Credentials). | ||
| - Avoid assumptions of global information, or synchronous communication. | ||
| - Not assume the availability of centralized services or components (e.g., member registries) | ||
| - **Implementation quality**: A DTF does not build, operate, secure, or fund the software and processes required to execute it. The gap between framework and dependable operation is closed by engineering, governance, and investment. |
There was a problem hiding this comment.
just a side note: The first statement is correct and important, yet it is being violated many times above. The second statement is unnecessary AI filler text, courtesy Anthrophic, no need to add that to the rulebook.
There was a problem hiding this comment.
Accepted — the second sentence is removed in 2da63d2; the first ("a DTF does not build, operate, secure,
or fund…") becomes the yardstick the whole revision is checked against.
| - **Implementation quality**: A DTF does not build, operate, secure, or fund the software and processes required to execute it. The gap between framework and dependable operation is closed by engineering, governance, and investment. | ||
|
|
||
| This DTF definition invalidates legacy models relying on static certifications or central brokers, as they do not scale to decentralized data spaces. | ||
| A good DTF is therefore judged by whether it makes trust decisions explicit, checkable, limited, revocable, and accountable; not by whether it removes all central components or all residual risk. |
There was a problem hiding this comment.
This rulebook doesn't qualify whether a DTF is good, or not. That is a judgement reserved for the participant that decides to use it to create trust.
Also a DTF has no say in central components or not.
There was a problem hiding this comment.
Accepted — the quality judgement is the participant's; the sentence is dropped in 2da63d2, and
the DTF gets no say on central components.
|
Thanks for the thorough line-by-line review — the definition-vs-implementation distinction is Process-wise: most comments are accepted as-is. The few that leave a definitional gap open Commit 2da63d2 already removes the uncontested implementation-level content, so the remaining |
3 participants
Summary
009_Dataspace_Trust_Frameworks.mdpreviously described trust as a loose, largelyself-contained runtime property — verified through generic "cryptographic proofs or
decentralized oracles", reconciled via an assumed automatic transformation/mapping
capability, and closed with a "fully decentralized" framing that didn't hold up.
This PR reworks the page into an operational definition: a Dataspace Trust Framework (DTF)
is now specified as the concrete set of things a data space must actually define — accepted
claims and their required metadata, trust anchors and their scope, reconciliation and
failure-handling rules, and issuer/anchor accountability — rather than a conceptual sketch.
Three themes drive most of the changes:
oracles, and full decentralization are each replaced with an explicit statement of what is
actually guaranteed and what remains a governance decision.
each anchor is authorised per claim type, and issuers carry accountability obligations
(correctness, key/status publication, compromise reporting, liability).
than detailed, and conflicting frameworks abort-and-escalate rather than quietly picking a
winner.
New sections cover what a DTF must define, how a concrete data space binds that framework to
protocols and credentials, verified self-description catalogues, and the limits of what a DTF
can guarantee.
Revision note
Origin: revising this page was suggested by Lars Nagel. Specific input on inter-dataspace compatibility came from @arnoweiss workshop at the 6th Tractus-X Dev Community Days.
Process: roughly 10 drafting/review iterations, combining AI-assisted drafting — fact-checking and generation (mainly Anthropic Claude Fable), a fluency/readability pass (Gemini 2.5), and an independent review-and-consolidation pass (ChatGPT 5.5 + Fable) — each iteration with human review by Eric Nowak who provided domain context, contributed his own subject-matter expertise, and steered the drafting throughout; @mketterl acted as second expert human reviewer.
Key references: NIST SP 800-207 (zero trust); IETF RFC 9334 (RATS); W3C DID Core, Verifiable Credentials, Bitstring Status List, PROV-O; Decentralized Claims Protocol; Dataspace Protocol; ODRL and the Data Privacy Vocabulary; ETSI TS 119 612 and AdES/LTA; DCAT application profiles; DSSC Blueprint (Data Models); PACT Technical Specification; Eclipse XFSC Federated Catalogue.
The full itemized delta (normative and structural) is in
CHANGELOG.md.Related issue
Closes #131
Checklist