EDC 0.6.3+ DataIntegrityKeyPair implements wrong interface.

[ricardas-buc]

Bug Report

Describe the Bug

With iron-verifiable-credential update to 0.14 DataIntegrityKeyPair class was moved from the library to the edc side. Current implementation corresponds only to VerificationMethod interface, but previously it also implemented VerificationKey interface.

Due to this change LdpVerifier fails when DataIntegrityKeyPair is used as verification method.

Connector/extensions/common/crypto/ldp-verifiable-credentials/src/main/java/org/eclipse/edc/verifiablecredentials/linkeddata/LdpVerifier.java

Lines 251 to 253 in 74da292

	if (!(verificationMethod instanceof VerificationKey)) {
	return failure("Proof did not contain a valid VerificationMethod, expected VerificationKey, got: %s".formatted(verificationMethod.getClass()));
	}

Context Information

• Used version EDC 0.6.3, 0.6.4

Possible Implementation

Making DataIntegrityKeyPair implement VerificationKey does solve the issue. I've not investigated if rewriting LdpVerifier check would bettter approach.

[paullatzelsperger]

We have discussed this at length, me explaining the details of linked vs embedded proofs. Is this issue based on an actual test case you have, or is this conjecture? In the earlier case I would kindly ask to submit a reproducible test case (as a gist) that clearly outlines the issue, otherwise I’m afraid there is little we can do.

[edit] link for reference: eclipse-edc/IdentityHub#330

[ricardas-buc]

We did discuss it, but that time we were concentrating on IH not embedding public key. I've created a patch for connector which adds an unit test which reflects what is happening for us:

https://gist.github.com/ricardas-buc/d54d475eafb869d9427f15a3e5d70965

Notes:

• VP is being returned by edc identity hub. In gist I've added what LdpVerifier gets as rawInput string.
• It seems that IH returns expanded VP. Should it be like that?

If underlying VP is wrong, is that an issue on our side? VP gets signed and returned by IH, we're not controlling that part. Let me know if any extra information would help you, thanks.

[paullatzelsperger]

as I said before, all signing is done on the expanded, canonicalized (URDNA) form. IH does not embed public keys but it adds a reference URL to where they can be dereferenced, i.e. the DID.
Unless there is a technical problem with IH, like wrong keys are used, or signing doesn't work etc. I will close this issue.
Before you raise any more issues, please familiarize yourself in depth with core concepts such as VerifiableCredentials, Linked-Data, Decentraliced Identifiers and the IATP protocol, on which IH is based.

[ricardas-buc]

as I said before, all signing is done on the expanded, canonicalized form. both on VCs and VPs. IH does not embed public keys but it adds a reference to where they can be dereferenced, i.e. the DID.

Right :) not disagreeing at all, then the VP in gist should be correct. Have you at least checked the use case?

[paullatzelsperger]

I did just now, and yes, it seems there actually is an issue with the type. However, even if that, and small issue are fixed, the VP is not validated correctly. Are you sure you used detached payloads?

[ricardas-buc]

I did just now, and yes, it seems there actually is an issue with the type. However, even if that, and small issue are fixed, the VP is not validated correctly. Are you sure you used detached payloads?

Glad to hear that type is indeed confirmed as an issue :) Regarding signature validation - underlying VC/VP uses gaia-x specific signature format, its an extension on our side. Vanilla edc fails to validate these signatures. Forgot to mention that in notes.. hope you've not spent a lot of time on that :)

[paullatzelsperger]

I did just now, and yes, it seems there actually is an issue with the type. However, even if that, and small issue are fixed, the VP is not validated correctly. Are you sure you used detached payloads?

Glad to hear that type is indeed confirmed as an issue :) Regarding signature validation - underlying VC/VP uses gaia-x specific signature format, its an extension on our side. Vanilla edc fails to validate these signatures. Forgot to mention that in notes.. hope you've not spent a lot of time on that :)

no worries, all good. Although I will say that we advise against using any proprietary non-standard signature formats, as that will hinder interoperability.

[ricardas-buc]

I did just now, and yes, it seems there actually is an issue with the type. However, even if that, and small issue are fixed, the VP is not validated correctly. Are you sure you used detached payloads?

Glad to hear that type is indeed confirmed as an issue :) Regarding signature validation - underlying VC/VP uses gaia-x specific signature format, its an extension on our side. Vanilla edc fails to validate these signatures. Forgot to mention that in notes.. hope you've not spent a lot of time on that :)

no worries, all good. Although I will say that we advise against using any proprietary non-standard signature formats, as that will tank interoperability.

Agreed, but our aim is to use Gaia-X provisioned VCs which use same JSON web signature 2020, but they take different payload during sign/verify compared to "normal" operation. https://gitlab.com/gaia-x/lab/json-web-signature-2020 It is already deprecated (but new approach is still being finalized), hopefully everything will properly align in the future.