Can you be more specific about what this issue refers to? The aud claim must be set in the protocol layer by AudienceResolver.

My use case is that I have a dataspace with multiple EDC connector managed by differents enterprises. I don't want that an enterprise is able to use an access token retrieved by its connector onto all others connectors in the dataspace.

The RFC 8707 state that an OAuth2 client can use a resource parameter which is a URL, to indicate to the IDP the target resource server on which the access token will be used. This allows the IDP to add this target as audience inside the access token.

Without this feature, the IDP cannot know the target audience, so it either means that a common audience is used for all connectors in the same dataspace or the audience is not set and can not be checked. Both are not good in term of security.

I think it should be possible to add this parameter as part of the access token request considering the calling EDC known the called EDC. The value of the parameter is this case would be the EDC host URL.

If you consider this issue ok. We can work on it and make a PR.

@scandinave just to be 100% sure: you are proposing to add another property to the request in the OAuth2ServiceImpl like so:

@NotNull
private Oauth2CredentialsRequest createRequest(TokenParameters parameters, String assertion) {
    return PrivateKeyOauth2CredentialsRequest.Builder.newInstance()
                .url(tokenUrl)
                .clientAssertion(assertion)
                .scope(parameters.getStringClaim(JwtRegisteredClaimNames.SCOPE))
                .resource(parameters.getStringClaim(JwtRegisteredClaimNames.AUDIENCE)) // <-- this is new!
                .grantType(GRANT_TYPE)
                .build();
}

correct? The parameters object already contains that value, because it's extracted from the remote message using the AudienceResolver, as @jimmarino said. So it should be an easy fix.

However, be advised that going forward, the EDC project will focus solely on the Decentralized Claims Protocol as its main identity subsystem (i.e. the IdentityAndTrustService). This means that there is a high chance that OAuth2 will be deprecated and ultimately discontinued. In that case, once it is deprecated, we are looking at ca. 3 months until final removal.

We therefore strongly recommend considering a switch over to DCP.

Yes, this is something like this, if parameters.getStringClaim(JwtRegisteredClaimNames.AUDIENCE) can return a URL as required by the specification.

We currently have a dataspace that use the old centralized model for its security, and we need to address this issue quickly.
We have chosen this model because of assumption that state that DCP was not production ready yet. ( here, here and here ).

Do you mean that DCP is now considered production ready? If not, do you have provisional roadmap on it? This something we definitely have in our backlog.

parameters.getStringClaim(JwtRegisteredClaimNames.AUDIENCE) will contain whatever the AudienceResolver implementation stores there. In the case of OAuth2, this is the counterPartyAddress of the message receiver by default and unless another audience resolver is registered, check here.

As for DCP, you can safely disregard the first link. That clearly is a remnant of times passed, e.g. it still contains references to ION which was a blockchain-based DID method.

The DCP specification is slated for an "Editor's Draft" release in December and the implementation of the Credential Issuance Protocol in IdentityHub will likely come in 2025. DCP is actively used in production in several dataspaces, e.g. Tractus-X.

I understand the need for a quick solution, and that is fine, but it is something to keep in mind. You can also checkout the MVD project if you haven't, to play around with DCP a bit.

Thanks for this precious information. Can we make a PR for this little fix to allow us to resolve our problematic until we schedule the migration to DCP ?

Can we make a PR for this little fix to allow us to resolve our problematic until we schedule the migration to DCP ?

sure, go ahead!