what needs to be defined as a standard.

[Sakurann]

Hi, Trying to address my own concernz in #34 but also trying to answer questions I have been receiving regarding how OpenID4VP and other decentralized identity can be used to achieve the goals of this project.

I am trying to do two things:

• separate what needs to be defined in a standard and what is implementation-specific
• clarify where authentication is needed and when authorization is needed

In short, from what I have gathered, I think what needs to be defined in a standard is the following flow: "Data Space X authenticates itself to Data Space Y and requests access to certain resources. (Data Space X has a way to pre-discover out of band what it needs to present to Data Space Y to get authorization for each resource being requested.) Data Space Y makes authorization decision and returns Access Token to Data Space X. Data Space X takes that Access Token to Data Space Y's Server (can also be called wallet, ID Hub, etc.) and Data Space Y returns the resource."

and it this flow is happening twice as per diagram below: 1) Data Space B getting access to Data Space A to get information about Data Space A (part of B authenticating A); and 2) Data Space A getting access to Data Space B to get B's resources it wants (end goal)

Below are implementation details:

• If Data Space A' Authorization Server alone doesn't know if Data Space B should be allowed access, B can use to authenticate itself in step 2 using whatever it received in step 1 from A itself.
• In this model, Wallet (Server) need to be able to process the Access Token. By using VCs as Access Tokens, one might be able to simplify that.

If above diagram is true, I think defining, a new OAuth grant type might be sufficient where and entity authenticates itself using a sender-constrained Token (aka VC) (in steps 1 and 2) to receive an Access Token (in steps 4 and 6 respectfully). No need to Decentralized Identity Foundation ID Hub/Decentralized Web Nodes (DWN) spec. and probably no need for OID4VP either.

What I still don't understand is if Data Space A is sending a VC to authenticate itself in step 1, why does Data Space B needs more VCs about Data Space A from A's server...

[PeterKoen-MSFT]

Hi Kristina,

Thanks for your help and insight and for taking the time to create the diagram and writing down your thoughts on this issue. You raise some really good points and we see some areas where the specifications can be improved based on your feedback:

1. As you highlighted in Issue 33 (Issue 33 (https://github.com/eclipse-tractusx/identity-trust/issues/33)), text needs to be incorporated describing the use of a nonce for verifier requests to a client's Credential Service. This is a known issue and a PR is planned shortly.
2. There are plans to improve consistency in verbiage and hopefully this work will be done over the course of the next couple of months
3. It is valuable to reference parts of other specifications where appropriate. As there is not yet a finalized specification format it may be decide to replace those references with inline descriptions if it makes the text clearer
4. The diagram presented in Issue 36 (https://github.com/eclipse-tractusx/identity-trust/issues/36) does not accurately capture dataspace interactions. Thank you for adding this diagram to explain your thoughts and to help us understand your proposal. While it would be possible to redraw the diagram to reflect the mechanisms at play in a dataspace and thus make it more accurate, it will be necessary to first start by reviewing the DSP specifications and Catena-X use cases. These have been developed over the last three years and should be the basis of discussion. A great starting point are the DSP specifications (https://github.com/International-Data-Spaces-Association/ids-specification) because those outline the problems being addressed and the constraints of the current identity and trust protocol being defined.

It would be great to continue the discussion with the DSP in mind.

[ma3u]

The Dataspace Protocol (DSP) draft didn't address Identity yet.

As described in the IDSA rulebook 2.0 function requirements: https://docs.internationaldataspaces.org/ids-knowledgebase/v/idsa-rulebook/idsa-rulebook/3_functional_requirements

The data space authority (DSA) is responsible for issuing membership credentials. It ensures that an appropriate mechanism is provided for identifying and verifying membership... In a largely decentralized architecture, it could be the issuance of a tamper-proof credential, such as a W3C verifiable credential (VC) which provides proof of the attribute of membership.

The DSA (operational company) also performs other functional roles not directly related to building trust but necessary for the operation of a data space. These are primarily the mandatory function of regulating the lifecycle of membership (participant discoverability, issuing of membership credentials, verification services for membership proofs), but also many optional services like observability and auditing, brokering and marketplaces, providing vocabularies or other services required by the data space members.

The communities coming together in the data space needs to make decisions for the setup. Whether a centralized DSA is required, or a more federated or even fully decentralized model is appropriate must be reasoned over when the data space is founded, as these architectural choices are very hard to change later. Where on this spectrum of possibilities an optimal design for a data space can be found depends on the context and purpose of the data space.

That's so true, because if we are not designing the drafted protocol in the right way we can't integrate commercial wallet provider like Microsoft Entra, Bosch, SAP, T-Systems etc. in the future.

:warning: The community want to help to specify a disambiguous protocol that fosters an easy integration of commercial wallets and self-made wallets into the data spaces ecosystems.

:point_right: We need a working group to refine the Verifiable Presentation protocol for data spaces to address the issues stated here by other members like @PeterKoen-MSFT and @Sakurann and @matgnt.

[jimmarino]

@ma3u, thanks for your thoughts. A few comments:

1. The DSP specifications are not reliant on the IDSA rulebook. They are designed to lay out a standalone, normative protocol specification. The relationship between the IDSA rulebook and DSP specifications has been discussed at length in the IDSA standards working group.
2. The IATP specifications are based on a specific identity and trust architecture. They detail an interoperable way for dataspace participants to present (and validate) verifiable claims that preserves communications privacy and limits the possibility of dataspace network disruption. They also detail an interoperable way for dataspace participants to request issuance of verifiable credentials from trust anchors.
3. It is not in the scope of these specifications to define activities related to the DSA
4. We already have a Tractus-X working group comprising multiple stakeholders to define the specifications. There will be new developments in this space soon, so please stay tuned.
5. Our primary goal is to design a protocol that adheres to Eclipse IP policies and can be implemented by independent runtimes. The protocol must allow for both open source and proprietary solutions.
6. We have not chosen as a starting point any existing proprietary solution as that is counter the goals and principles mentioned above.

I hope this clarifies the background of IATP. Since this issue does not contain a specific, actionable item that can be addressed in the specification text, I'm going to close it out.

[c2bo]

I don't understand why this issue was closed when it contains protocol feedback and a concrete proposal? It might not 100% fit the DSP ideas, but I 100% agree that there is value to try to better align with extrem standards/concepts.

A new OAuth grant type that uses either DIDs or some form of client attestation (some form of attestation that this system belongs to company or trust domain XYZ) would go a long way and solve at least the AS related parts of the system in a way that aligns with existing standards and can be re-used.

[jimmarino]

I'd like to preface the following by saying we appreciate feedback, and, of course, we want to align with existing standards when possible. We also need to make forward progress and deliver a solution in a reasonable amount of time. Fundamental to this is respecting the work that has already gone into these specifications (and the DSP specification). This involves taking the time to engage and understand the specifications and the use cases that have informed them. Asking questions and making proposals is welcome and fine. Posting issues or solutions that make no effort to follow this process is not.

This issue was closed because it does not contain any actionable items. For example, #33 identifies a specific item in the specification (use of a nonce), which is still open. As both @PeterKoen-MSFT and I mentioned, the diagram does not accurately capture dataspace interactions and is not actionable. It's not a question of being a little off or not a "100% fit"; it is wholly inaccurate. For example:

• "Dataspaces" do not communicate with one another
• "Wallets" (the term in the specs is "Credential Service") do not manage data resources
• The diagram confuses fundamental DSP architectural principles, namely the separation between the control plane and data plane
• There is no understanding of the key DSP messaging patterns, including catalog request, contract negotiation, and data transfer request

If one "corrects" (re-writes) the diagram and:

• Removes the "dataspace" actors which don't exist in DSP
• Removes the "Dataspace B Wallet," which does not play a role in these interactions
• Removes steps 6-8, which are misrepresented and are not part of the IATP interactions
• Includes the proper actors as defined in the DSP specs or in the current specs here

The resulting presentation flow will only change by introducing a new series of calls to an authorization server to receive an access token for the Credential Service. It does nothing else.

Adding this extra step introduces a series of unnecessary complications:

• The requesting dataspace participant agent will need to expose an authorization server and pass an authorization request object as part of its outbound request
• The authorization server will need to correlate the request for the access token with the outbound request object, guard against replay attacks, and ensure that the generated access token corresponds to the access privileges needed for the outbound request. This couples the authorization server to the Credential Service rather than the Credential Service to the authorization server as is with the current design. The authorization server will now need to understand an additional grant type (or whatever the IATP defines, see the point below). This is not the case with the current design.
• Significantly more remote calls will be introduced into the DSP interactions, particularly because they are based on bipartite message exchanges that must establish trust.
• We will need to standardize the request for the access token, which we do not have to do in the current flow as it is not part of the identity and trust interaction. This will significantly increase the surface area of what needs to be standardized and greatly restrict implementation freedom, including two implementations that are currently making use of this.

There was a conscious effort not to expose the authorization server through IATP interactions for the above reasons. You're welcome to make an argument for why this should be done, but please invest time in understanding the DSP specifications and our use cases. Feel free to bring it to the working group as a formal proposal for discussion.

We currently have two working implementations of the presentation flow client: EDC and a proof-of-concept that uses Keycloak. It's therefore not unreasonable to assume the current design can be implemented with many off-the-shelf solutions.

Specifically regarding client attestation in Catena-X, I would recommend looking at its defined credentials (membership, dismantler, etc.) for more details.