Question Regarding Extending Existing Functionality Without Modifying Source Code

[Zhipeng-lin1]

Hello,

I would like to know if it's possible to override or extend the functionality of the following classes without directly modifying the source code:

HasValidSubjectIds.java

VerifiableCredentialValidationServiceImpl.java

Is there an official or recommended way to achieve this via an extension mechanism?

Thank you in advance!

[ndr-brt]

not easily and not without some hacking, these are services that are not expected to be overridden.
Could you share what's the root of your need?

[jimmarino]

They are not designed to be overridden, and I strongly encourage you to follow what we recommended above. Barring that, you can exclude the module(s) from your build. You will then need to replace the appropriate services.

[Zhipeng-lin1]

Here are the responses I received from the Gaia-X team regarding the previous questions:

• How Verifiable Credentials are bound to a holder, and how this binding can be verified?

The verification of the binding of a VC to an issuer is done via the verification of the VC signature with iss field from the JWT payload and kid field from the JWT header.

How to interpret those iss and kid values is protocol specific.
For OpenId Connect, the flow is to:

1. resolve iss + .well-known/openid-configuration and fetch the OpenID config JSON object. (ex: https://auth.gaia-x.eu/realms/gaia-x/.well-known/openid-configuration)
2. resolve the url from the OpenID object jwks_uri property and fetch the JWK set object.
3. identify in the JWK set, the correct key using kid.
4. verify the JWT signature using the found key.

This flow is implemented on https://jwt.io/

The verification of the binding of a VC to a holder is done during the presentation of the VC to a verifier.
This key-binding mechanism which must be done during issuance, is very well illustrated in this OID4VC documentation https://www.authlete.com/developers/oid4vci/#251-key-binding\
This mechanism is not mandated by Gaia-X specifications but highly recommended.

• How the relationship between credentialSubject.id and the holder is expected to behave (must they match)?

No, there is no limitation on the Credential subject, since there are countless cases in which the subject of the credential (although related to) is not the holder.

• How credentialSubject.id IRIs (URIs or @id) are intended to be linked to DIDs, especially across credentials?

Which DID ?

[jimmarino]

Hi

Those aren't quite the questions I asked. However, the bigger issue is that what you are pointing to is not a specification or a coherent set of technologies. I understand you are stuck here, but I would push back and demand more coherent requirements:

• A precise specification for how the linkage between credentialSubject id and holder id is verified
• iss + .well-known/openid-configuration is not valid according to RFC 8615, which mandates that well-known URIs be placed at the top of the path hierarchy. Relaying on a mechanism like this will also run afoul of the Web DID specification, which states that Web DIDs do not mandate control of an entire domain (or subdomain)
• I have no idea how any of this will work according to the DSP specification
• Again there are massive security holes in stating that, "there are countless cases in which the subject of the credential (although related to) is not the holder"

Unless Gaia-X can point to a set of specifications and coherently articulate how those technologies should work in the context of the DSP specification, I cannot help.

[Zhipeng-lin1]

Hi, thanks a lot for your response.

Based on the reply I received from the Gaia-X team, the linkage between credentialSubject.id and the holder is not what they rely on to ensure that a Verifiable Credential (VC) is held by the correct Participant.

Instead, they use a key-binding mechanism at the time of issuance to bind the VC to the holder. However, this mechanism binds the VC to the holder’s key—not necessarily to the credentialSubject.id.

Regarding the example they gave using iss + /.well-known/openid-configuration, it was meant in the context of OpenID Connect, which relies on RFC 5785, not RFC 8615.

Isn't the DSP specification intentionally agnostic about VC formats and exchange protocols? From what I understand, DSP doesn’t dictate how Verifiable Credentials should be structured or verified—instead, it leaves those decisions to individual implementations or higher-level frameworks.

[jimmarino]

RFC 8615 supersedes RFC 5785. However, both mandate that the Well-Known URI must be at the root of the path.

DSP is not agnostic about how VCs are structured or how they should be verified. Depending on the profile, it relies on VCDM 1.1 or 2.0, requires specific cryptographic suites, and details how verification should be performed.

Regardless, what is missing is a specification of the protocol Gaia-X seems to be defining and how that is supposed to work with DSP. Unless there is a specification that defines the message exchanges and how they fit with DSP, we can't help, nor can we spend time trying to guess what is intended.