EDC User management

[joelweihrauch]

We would like to enable an end-user-specific use of the EDC in our use case. We want to achieve that every process(Negotiation, CatalogRequest etc.) in the EDC is connected to a specific User not only the connector itself.
In detail, we want to carry out the following steps:
0.1. User is already registered in an authentication process(e.g. "userID = 1234")
0.2. Asset is created with Policy, PolicyDefiniton on provider-side
-> Policy has constraint e.g. "userID = 1234"

1. Use Case App sends Post to Endpoint "/negotiation" with Session/User Object
2. Ids interface sends Negotiation with Session/User Object
3. Process recieved contract Negotiation in Provider
   3.1. Get Identity from "IdsMultipart Message"
   3.2. Evaluate Policy in respect of identity
   3.3. Confirm Negotiation
   (4. Get State of Negotiation)

The only way without changing a lot of core modules in our opinion is to utilizing the identityService. But we still have to change the send function of the "IdsMultipartSender", because we can't really identitfy the user with only the token scope and the remote connector address. That all would lead to more changes in the core.

public CompletableFuture<R> send(M request, MessageContext context) {
        var remoteConnectorAddress = retrieveRemoteConnectorAddress(request);

        // Get Dynamic Attribute Token
        var tokenParameters = TokenParameters.Builder.newInstance()
                .scope(TOKEN_SCOPE)
                .audience(remoteConnectorAddress)
				".someExtensionParameters(user object)"
                .build();
				
        var tokenResult = identityService.obtainClientCredentials(tokenParameters);
        if (tokenResult.failed()) {
            String message = "Failed to obtain token: " + String.join(",", tokenResult.getFailureMessages());
            monitor.severe(message);
            return failedFuture(new EdcException(message));
        }

        var token = new DynamicAttributeTokenBuilder()
                ._tokenFormat_(TokenFormat.JWT)
                ._tokenValue_(tokenResult.getContent().getToken())
                .build();
				
				....
}

Is there another possibility how we can achieve our use case?

[jimmarino]

Hi,

The IdentityService explicitly deals with participant agents, not end-users, which is explained in more detail here.

What is an end-user? Are they identifiable outside in the dataspace? Do they have secure data storage and compute resources?

Scenario 1

It appears the assumption is a user is identifiable in the dataspace and must have secure compute resources since a policy constraint can reference the user id. If that is the case, the connector is a participant agent for the end-user, which would be the participant. The connector identity should therefore correlate to the end user, and the existing EDC code paths will work.

It may be that there is a trust chain from connector identity to an organization, e.g. "Connector X is operating on behalf of a participant that is an employee of Corporation C and therefore should be trusted." If that is the case, you need a form of federated trust. Web DIDs can be used to enable this.

In this scenario, your app will need to manage a connector per end-user, which is fine since the connector is a lightweight runtime.

Scenario 2

If, on the other hand, the user is not identifiable in a dataspace, it can't be referenced by a third-party policy constraint. In this scenario, the end-user is the initiator of a request, not an identity in the dataspace. Your app will need to handle correlation to the end user by referencing the request id returned by the connector. The correlation data should be managed outside the ambit of the EDC.

[joelweihrauch]

Thank you for your answer. In our understanding the end user is a citizen. From our perspective the citizen can but not has to be in an organization.

Regarding Scenario 1:

The assumptions you make in the first two paragraphs are correct so far for our use case. In the last paragraph, you state that we would need "one connector per end-user". Actually, this is an assumption that we also made within the project until now for the sake of simplicity. However, we are concerned about how this approach scales at large within a cloud environment, as in our use case we may presumably have millions of users. In your opinion, would this still be a reasonable approach? Could you give an estimation about how this scales at large or how high the resource consumption per instance would be (e.g., for the IDS Launcher)?

Regarding Scenario 2:

What we understand this would lead to the point that the connector would have access rights to all assets. However, in our scenario we would start a catalog request and we would need to somehow limit the answer of this request to the specific user. In our scenario, the access from data consumer’s connector to the provided data depends on end-user's consents. In this case, it is required to identify the end-user in order to provide the corresponding specific data.

[jimmarino]

It's impossible to give generic scaling figures as it depends on multiple factors, including the extensions you are running, configuration, hardware, etc. I would perform scale-out testing to provide real figures once you have arrived at a design and implementation, then iterate those based on the results.

I would also not worry about "millions" of users at the outset since those users are unlikely to materialize all it once. Instead, I would focus on the system design and getting that right. Based on your comments, it appears your design is unsettled:

1. It's not clear what an end user is. Is it an identity in the dataspace? The answer to this should either be "yes" or "no," not "maybe".
2. Do organizations play a role in the trust chain? For example, can access control or usage policies depend on an identity being associated with another identity (organization)?
3. What are the trust anchors in the dataspace?

Assets are shared with identities. Those identities are responsible for adhering to the usage control policy associated with an asset. If the end-user is an identity, it is responsible for adhering to the usage control policy (which can be done via a participant agent running on their behalf). If, on the other hand, an entity (organization, state actor, etc.) is the identity, it may allow its consitutents (employees, citizens, etc.) access to the data based on criteria, but the entity is responsible for its control.

What I understand your approach to be doing (I don't have a lot of context, so this could be wrong) is muddying the waters, and this may subtely change point 3 above. By adding additional attributes about the "identity" in the consumer connector (and tunneling it in the request), the design is introducing an additional identity trust anchor, which is the consumer connector (e.g., how are those attributes verified by the provider?). This does not seem right.

This will also lead to practical problems on the consumer, for example, how to track the "same" (by GUID) assets per user in a shared consumer connector?

I think the design path to take will become much clearer once these questions are settled. If you need to run EDC in a dense cloud environment, there are a number of ways this can be done. In your case, it may be that each connector is run on behalf of a citizen but its EDC instance does not need to be "always on/running". In this case, the EDC instance could be fired up on demand and run until a transfer process completes, then taken down. The NPM and TPM use a single thread each so overhead is negligible (and will be even less so when virtual threads are added to the JVM).

From a design perspective, you could lean on K8S to do most of the heavy lifting (that would be my preference), or you could create your own EDC launcher that managed multiple EDC instances. I described both approaches in a comment (June 3) here:

https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/discussions/1301

HTH

[joelweihrauch]

Hi,
thank you for your detailed answers. We had to discuss and evaluate some of your questions. We would like to explain our use case more in depth. We also think it would be useful for the whole discussion.

Without further ado:
We would like to enable citizen to get their personal collected health data from a data source. The hospital should enable the edc as a provider and let's say give information for which user they have data. In our scenario, where a citizen in the form of a "patient of hospital XY" wants to access their health data, there is usually no citizen - company relationship as in other areas.

After our evaluation we came to the point that we would go with first scenario which you described earlier. At the moment there are no open questions from our side.

Should we leave this discussion open for future questions to that topic? Or should we open a new discussion?

Best regards

[mspiekermann]

@joelweihrauch I marked it as answered. Feel free to reopen this discussion if there is a direct link or else open a new discussion.