Federated authentication for OAuth 2.0(DAPS) extension

[git-masoud]

An OAuth 2.0 application can be configured to work with multiple identity providers, allowing applications to authenticate using different providers. This process is also known as "federated authentication".
In certain situations, there may be scenarios where connectors from different dataspaces(different Identity Providers) want to communicate with each other. However, in the current implementation of Daps extension, this is not possible even if both connectors are registered in both Identity Providers.
This would not be so complicated to validate the DAT against multiple providers in the Daps-extension. My question is if this is logical and if you would accept this approach to be applied in Daps-extension?

[jimmarino]

Hi,

Can you provide more detail? Two connectors from different dataspaces don't communicate with one another. Instead, they need to be part of a common dataspace.

A connector can be part of 1..N dataspaces. If a connector is a member of multiple dataspaces, it may need to authenticate or verify identity tokens with multiple providers depending on the current dataspace context. In that case, there should be a mechanism to specify which dataspace and trust anchors are accepted.

Is that the use case you are outlining?

[git-masoud]

Thank you for your quick response. This use case is exactly what I wanted to express. For instance, when a connector in catena-x-dataspace which is also registered in x-dataspace wants to communicate with another connector with the same conditions.

Specifically, I am looking into the challenges of communication between two connectors that are registered in different dataspaces. The potential obstacle in this scenario is how EDC manages and verifies the DAT token across multiple Daps.

[jimmarino]

It may sound pedantic, but let's be careful in our terminology: two connectors registered in different dataspaces never communicate. Two connectors may be registered in multiple dataspaces, but to communicate, they must be participants in at least one common dataspace. Another way to state this is: a dataspace is always required for EDC-based data sharing.

Complicating this, in a single dataspace, there may be one or more identity providers. If an asset is restricted by a provider, a client must have valid credentials issued by at least one of the identity providers trusted by the provider.

The issues that must be addressed are:

1. The provider needs a way to convey to clients what verifiable credentials are required
2. The client needs a way to interpret that information and obtain the appropriate credentials when sending requests to the provider
3. When a provider receives credentials, it should resolve the issuer endpoint and verify against that (after ensuring it trusts the issuer).

Items 1-2 need to be done in conjunction with the IDS specification work that is currently underway. Validation of client credentials by the provider should be handled using the appropriate OAuth 2 flow. The status of the provider DAT sent to the client is up in the air. There is no specification for this, it doesn't follow any standards-based security flow, and there is an ongoing discussion among the EDC committers about removing it as it is a potential security threat.

Can you frame what you want to achieve in this context?

Thx