DSP catalog request should not return 401 when trusted-issuer check fails

[smanolloff]

Bug Report

Describe the Bug

✅ When requesting VCs for accessPolicy validation, the connector hides the corresponding offers where the policy evaluates to false (as expected).
❌ However, the connector returns an error (HTTP 401) if it receives VC from an untrusted issuer, even if only one offer in the catalog has an accessPolicy requiring this VC.

Expected Behavior

Catalog response is 200 with the visible offers (where accessPolicy evaluates to true).

Observed Behavior

Catalog response does not return any offers (HTTP 401) because one of the offers fails to validate a VC because it is from an untrusted issuer.

Steps to Reproduce

Setup:

• Connector A with VC "Membership" issued by issuer X
• Connector B which trusts issuer Y and has two offers:
  • offer1: no accessPolicy (visible by all)
  • offer2: accessPolicy requiring "Membership" VC

Test:

• Connector A requests Connector B's catalog via DSP

e.g.

curl 'http://connector-A/management/v3/catalog/request' --json '{
      "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
      },
      "counterPartyAddress": "http://connector-B/protocol",
      "counterPartyId": "did:web:connector-B",
      "protocol": "dataspace-protocol-http"
    }'

Context Information

• EDC v0.14.1
• OS: Linux

Detailed Description

Connector A receives this error:

[{"message":"{\"@type\":\"dspace:CatalogError\",\"dspace:code\":\"401\",\"dspace:reason\":\"Unauthorized\",\"@context\":{\"dcat\":\"http://www.w3.org/ns/dcat#\",\"dct\":\"http://purl.org/dc/terms/\",\"odrl\":\"http://www.w3.org/ns/odrl/2/\",\"dspace\":\"https://w3id.org/dspace/v0.8/\",\"@vocab\":\"https://w3id.org/edc/v0.0.1/ns/\",\"edc\":\"https://w3id.org/edc/v0.0.1/ns/\"}}","type":"BadGateway","path":null,"invalidValue":null}]

Connector B logs this error:

Unauthorized: Credential types '[VerifiableCredential, MembershipCredential]' are not supported for issuer 'did:web:...'

Adding an edc.iam.trusted-issuer... for issuer X to connectorB's configuration resolves the issue. However, this is only a workaround.

Possible Implementation

You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.

[github-actions[bot]]

Thanks for your contribution 🔥 We will take a look asap 🚀

[paullatzelsperger]

This is not a bug, but indeed by design. Credentials, where the issuer is not trusted cannot be regarded as secure/trusted.
Every dataspace or participant must maintain their own list of trusted issuers.
After all, a malicious actor could just set up their own issuer service, and issuer their own credentials.

It is the same with SSL certificates: unless they're issued by a trusted CA, browsers will likely reject them.

Or you could compare this to using an OAuth2 access token that only grants permission to certain areas of a web-page, versus using an OAuth2 access token issued by a random third party. In the earlier case you'd simply expect to see only those parts you are allowed to see, whereas in the latter case you'd expect a HTTP 4xx.

[smanolloff]

I fear you have missed my point.

For example, taking your statement:

Credentials, where the issuer is not trusted cannot be regarded as secure/trusted

Great, no problem there. However, with current EDC implementation, the behaviour is:

Participants with at least 1 credential where the issuer is not trusted cannot be regarded as secure/trusted.

Or another of your examples:

It is the same with SSL certificates: unless they're issued by a trusted CA, browsers will likely reject them.

This analogy is wrong: on the WWW, each website presents exactly one certificate. Trusting the "website" means trusting the certificate CA.
This is not applicable to a dataspace: each participant presents many VCs. In the current implementation, trusting the "participant" means trusting all VC issuers.

This is problematic for EDC dataspaces with a de-centralized issuer ecosystem.
It's normal to have multiple authorities issuing the same VC.
It's normal that a participant A presents such a VC to participant B and that participant B does not trust its issuer.
What this should also mean is: participant A should not see offers from B whose accessPolicy requires this VC. But currently A cannot see any offers from B (error 401), even "open" offers without any requirements, because EDC fails the entire catalog request due to an untrusted VC required by just one of B's offers.

What do you think?

[jimmarino]

This is not a realistic use case, nor would we likely support it given the complications it would entail.

Each dataspace authority is responsible for defining a list of trusted issuers. If a data provider only trusts a subset of those issuers, it must provide a way to advertise that subset, which is beyond the scope of the DSP and DCP specifications. If this is done, then the requesting participant can determine the set of credentials it needs to present.