More details on responsiblities of Trust Frameworks

[PeterKoen-MSFT]

The role of trust frameworks in dataspaces is not yet clearly defined and has evolved since the rulebook v1 was released. We need to update content on how Trust Frameworks support and enable dataspaces. Especially explain the plurality of Trust Frameworks.
Also in relation to #69 we need to explain how the Trust Framework(s) drive the selection of identity proofs.

[marioholesch]

Here is a summary of the discussion from our last meeeting, related to that topic:

Data spaces can be described through multiple layers: technical, business/economic, legal, and governance. While simplified models reduce this to fewer layers, it is essential to avoid oversimplification, particularly at the organizational or “middle” layer where business operations, identity management, and trust frameworks intersect.

At the technical layer, the minimal roles are data provider and data consumer. This simplification highlights the act of data exchange, but it risks obscuring additional roles that are crucial for establishing trust. Identity management, credential issuance, and validation processes, for example, are technical in execution yet deeply connected to business and legal responsibilities. Treating them as merely “data” overlooks their special role in enabling secure participation.

The trust framework spans all layers. Claims such as “this is my identity” or “this organization is ISO-certified” may be self-issued (asserted directly by the participant) or provided by an external authority (e.g. certification bodies). Self-issued claims lower barriers to participation but raise questions of credibility and verification. The validation of such claims—who performs it, under what rules, and how it is recognized across data spaces—is a key open issue. From a technical perspective, the exchange of validity information could be modeled as a form of data exchange. Yet the implications reach into the business and legal domains, since validation establishes the basis for trust, liability, and compliance.

Governance authorities are pivotal in defining and overseeing these trust arrangements. Their institutional form may range from informal agreements among communities to formalized organizations such as foundations or associations. Regardless of form, they typically exert influence across layers: setting participation rules, defining identity and credential requirements, and sometimes mandating specific technical choices to ensure interoperability.

Interoperability across data spaces requires alignment not only at the technical level (protocols, standards, APIs) but also at the governance and regulatory level. Without shared approaches to identities, claims, and trust validation, data spaces risk fragmentation into isolated silos. Achieving scalable interoperability will depend on common abstractions, protocols, and agreements that allow participants to engage in multiple data spaces without duplicating roles or credentials.

Open Points and Questions

How should the distinction between a data space and a trusted data space be defined, and what additional requirements elevate one to the other?

Are self-issued identities acceptable in certain contexts, and under what conditions must they be supplemented or replaced by externally verified claims?

Should validation of claims (e.g. credentials, certifications) be treated as a technical data exchange or as a higher-level trust function?

Which roles beyond “provider” and “consumer” must be explicitly recognized at the technical layer to reflect identity, trust, and validation processes?

How can the responsibilities of governance authorities be described to capture their cross-layer influence, especially in identity and trust frameworks?

What common standards, protocols, and agreements are required to achieve cross-data space interoperability without duplicating memberships or credentials?

[PeterKoen-MSFT]

There is still some inaccuracy: at the technical level there is no distinction between data provider and data consumer. There are only participants. Distinction between provider and consumer only happens at the business level. Technically speaking everyone is a participants and operates a connector. Every participant can be provider, consumer, observer etc... or all of these at the same time.

Trust Frameworks do NOT span all layers. They are purely existing on the business/process layer and the governance layer. Although some Trust Frameworks try to enforce specific technologies, Trust Frameworks should be all about business processes and governance, not about picking technological winners.
It is true that Trust Frameworks can have policies that express technical necessities, but they do not control their implementation. E.g. a Trust Framework can say that a specific encryption algorithm needs to be used and provide details how to express this in a claim. It should not provide the encryption mechanism and insist on the usage of its single implementation. It should specify the WHAT, not the HOW.

A "Trusted Data Space" does not exist. What exists is Dataspace Technology (Protocols, Components, etc...), Dataspace Participants and Dataspace Governance Authorities... Trust is the result of the evaluation of a bag of evidence that is being collected for a specific action. There is no such thing as trusted dataspace as there us no such thing as blind trust. Even with the right choice of technology, participants, trust frameworks and governance authorities trust must be a case by case dynamic decision and not a general state. Otherwise it would be easy to have trust misused by bad actors.

Claims can be validated at a technical level but also at a business process or governance level, depending on the type of claims the layers will have to work together to achieve the desired result. Once the technical validity of a claim is established it needs to be processed for business process and governance meaning.

There is no such thing as cross-dataspace. It is at best a "cross governance" or "cross business process" interoperability question. It is the participant that is in 2 different dataspaces and thus needs to resolve potential conflict between those two ecosystems and how they interact with those. However, DSGA's and Trust Frameworks can massively reduce the conflict potential and support the resolution of remaining conflicts.

[mspiekermann]

@PeterKoen-MSFT @rajiv-ishare is this addressed in the currently discussed document about the trust perspective?