Wildcard or open-trust option for trusted issuer configuration

[lucasmorales18]

Problem

The current TrustedIssuerConfigurationExtension requires every peer DID to be explicitly listed in edc.iam.trusted-issuer.* properties before that peer's credentials are
accepted. For an open/permissive dataspace where participants are not known in advance, this is impractical.

What we want

Something like a wildcard trusted issuer:

edc.iam.trusted-issuer.issuer1.id=*
edc.iam.trusted-issuer.issuer1.supportedtypes=["VerifiableCredential","MembershipCredential"]

Where the trust anchor is purely cryptographic: the DID is resolvable, the credential signature matches the public key in the DID document, and the credential is valid and
non-expired — no pre-approved DID list required.

1. Is a wildcard or "trust-any-resolvable-DID" mode supported or planned in TrustedIssuerRegistry?

2. What is the recommended pattern for open/permissive dataspaces? We have considered approaches like a shared membership registry where nodes self-register their DID, but we'd
   like to know if there is a cleaner supported solution.

---

cc @paullatzelsperger @ndr-brt

[paullatzelsperger]

your assumption is not correct. it is not the participants' DIDs that need to be listed, it is the issuer's DID. Hence the name TrustedISSUERConfigurationExtension. The purpose of this is to list which Issuer are trusted in a dataspace.

also, this has nothing to do with DIDs per se, instead this module is intended to restrict who (= which issuer) can issue VerifiableCredentials, and which type. Coincidentally, we are using DIDs as identifiers.

I would recommend reading the documentation and getting familiar with the Decentralized Claims Protocol, because clearly, you are operating on half-knowledge at best.

[lucasmorales18]

Thank you for the clarification. We are fully aware of the issuer/participant distinction — our situation is specifically why the problem arises.

In our setup, each node self-signs its own participant credential (containing the information used for policy evaluation) and submits it to Gaia-X for identity verification. Gaia-X responds with a compliance credential as proof. The participant credential issuer is therefore the node itself by design, not a shared central organization.

This is exactly why we face the trusted-issuer problem: we can configure Gaia-X's DID once for the compliance credential, but the participant credential issuer is each node's own DID, requiring us to pre-configure every participant's DID individually — which we want to avoid, as it creates a dependency on a centralized trust configuration.

Given this context, our two questions stand:

1. Is there a wildcard or "trust-any-issuer" mechanism in TrustedIssuerRegistry?

2. For the registry approach — if a shared participant registry is the recommended pattern for this kind of open dataspace, has any reference implementation or extension been
   built for this in the EDC ecosystem?

cc @paullatzelsperger

[lucasmorales18]

Thank you for the clarification, that is exactly the answer we needed.

Just to address the trust concern: in our architecture a wildcard on the issuer would not mean trusting everyone unconditionally. Policy evaluation still requires a valid compliance credential signed by the Gaia-X Compliance Service, which cannot be self-minted. The self-signed participant credential only carries the legal attributes used for policy — the actual trust gate is the Gaia-X signature. We agree a plain wildcard with no additional check would be meaningless.

We will go ahead with a custom TrustedIssuerRegistry implementation. Thanks again.

[paullatzelsperger]

You do you, but validating a self-minted credential of any sort is pointless from a technical perspective. Validating a policy against self-attested claims (legal attributes) has no trust value whatsoever, because there can never be any (technical) assertion to the negative with any level of confidence.

In addition, if you require a ComplianceCredential anyway, that can only be minted by a central service, your custom trusted issuer registry could just filter on that ComplianceCredential type and return true in any other cases.

[lucasmorales18]

We appreciate the technical perspective, but this argument applies equally to the Gaia-X Trust Framework itself. The credentials submitted to the Compliance Service are self-attested — the participant signs their own legal attributes. Gaia-X hashes those claims and issues the LabelCredential on top of them.

However, Gaia-X verifies identity through technical controls: the VAT ID is checked live against the VIES registry, domain ownership is confirmed, and — most strictly — the x509 certificate backing the DID must be issued by a Gaia-X Trust Anchor CA. This cannot be self-generated; a real approved CA with its own identity verification process must issue it.

Self-attestation here is not anonymous. It is made by an entity whose cryptographic identity is certified by a Gaia-X Trust Anchor. Gaia-X explicitly treats this as a valid trust level, and our implementation follows that same model.

[paullatzelsperger]

Going by what you just said, the legal properties do not need to be presented to Gaia-X in the form of a VC. Instead, a simple onboarding process, e.g. through an API, would be sufficient, because the claims are verified server-side. This would be simpler, it would be synchronous, and it would nullify the original topic of discussion, i.e. trust-all-issuer-registries.

I can/will not comment on the merits or demerits of the Gaia-X Trust Framework, because I'm not intimately familiar with it, and it is not my place, but I will say, that it does seem overly complicated and not compliant with DCP issuance. Especially the requirement to use a X.509 certificate for your domain that was issued by a Gaia-X CA sounds very restrictive and impractical.

In any event, EDC provides you with the technical underpinnings to do whatever you like here, regardless of whether it is the recommended approach.

[paullatzelsperger]

I would also question whether a dataspace that requires a SSL cert from a specific CA, is really open and permissive, as you said. Gaia-X holds the sole control, and as soon as the SSL cert is revoked, the participant is locked out of the dataspace.

This will also create significant problems with other SSL connections, because you'd have to filter out "normal" SSL connections. And as soon as you have to handle non-Gaia-X DIDs in the same runtime you have another problem, because you don't know which DIDs are Gaia-X DIDs and which aren't.

[paullatzelsperger]

closing, because a solution has been provided and the discussion has veered off-topic.