LdpPresentationGenerator fails to add public key to a VP proof node.

[ricardas-buc]

Bug Report

With version 0.6.2 there seem to be a change of how VP proofs are populated. Missing publicKeyJwk leads to an verification exception in LdpVerifier as it fails to correctly parse verification method.

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

Possible Implementation

LdpPresentationGenerator fails to add publicKeyJwk as it was not passed to proof draft verification method. JsonWebKeyPair uses provided key to derive public key.

https://github.com/eclipse-edc/IdentityHub/blob/main/core/identity-hub-credentials/src/main/java/org/eclipse/edc/identityhub/core/creators/LdpPresentationGenerator.java#L169

Passing jwk to the proof makes VP proof valid again.

        var proofDraft = Jws2020ProofDraft.Builder.newInstance()
                .proofPurpose(ASSERTION_METHOD)
                .verificationMethod(new JsonWebKeyPair(URI.create(controller + "#" + publicKeyId), verificationMethodType, controllerUri, jwk))
                .created(Instant.now())
                .mapper(mapper)
                .build();

[github-actions[bot]]

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

[paullatzelsperger]

I think you don't have the whole picture here. LD proofs can have embedded JWKs, in which case you'd be correct, simply adding the jwk would solve the issue. But they can also be "linked", which means, you have to resolve the JWK during JSON-LD expansion. This basically downloads the JWK (which would have to be publicly available as JSON document) and inserts it into the expanded form of the signed credential.

Generally, LDP verification has to be done on the expanded form of the credential.

As a matter of security, public key material should not be embedded directly, but should be resolved from the credential/presentation issuer's DID to establish provenance.

[ricardas-buc]

I think you don't have the whole picture here. LD proofs can have embedded JWKs, in which case you'd be correct, simply adding the jwk would solve the issue. But they can also be "linked", which means, you have to resolve the JWK during JSON-LD expansion. This basically downloads the JWK (which would have to be publicly available as JSON document) and inserts it into the expanded form of the signed credential.

Generally, LDP verification has to be done on the expanded form of the credential.

As a matter of security, public key material should not be embedded directly, but should be referenced from the credential/presentation issuer's DID to establish provenance.

Fair point. I will assume that even though it is possible, edc IH is not exepcted to populate it.

I did try using default approach, it fails due to mismatching interfaces in LdpVerifier.

org.eclipse.edc.verifiablecredentials.linkeddata.DidMethodResolver is being used, which always create DataIntegrityKeyPair. Another oversight on my end or a bug?

[paullatzelsperger]

that's not a bug either :) the DidMethodResolver doesn't know anything about the specific verification method, JWK is just one, but there are others like RSA or Ed25519.
it will simply delegate the object down to the verification infrastructure.

[ricardas-buc]

that's not a bug either :) the DidMethodResolver doesn't know anything about the specific verification method, JWK is just one, but there are others like RSA or Ed25519. it will simply delegate the object down to the verification infrastructure.

Sorry, I am still not fully grasping what should be correct implementation here. Is default MethodResolver not capable of passing LdpVerification checks as it will never provide correct verification method?

To me it looks like that DataIntegrityKeyPair class implements wrong interface.

0.6.1:
This class is part of iron vc lib.
Class inheritance: DataIntegrityKeyPair -> KeyPair -> VerificationKey -> VerificationMethod

0.6.2:
Class was moved to edc:
Class inheritance: DataIntegrityKeyPair -> VerificationMethod

In both version LdpVerifier checks VerificationKey interface:

if (!(verificationMethod instanceof VerificationKey)) {
                return failure("%s: %s".formatted(ErrorType.Unknown, methodProperty.term()));
            }

[paullatzelsperger]

no, the key aspect is to remember, that all verification checks happen on the expanded JSON-LD of a LDP-Credential. Expansion is the process of dereferencing and resolving all linked data, such as the public key material.

That means, whether you embed the JWK or link it via a URL does not matter in the end, because both "variants" produce the same (ugly) JSON document. You have to expand though.

The LdpVerifier takes a String, which contains the credential/presentation in JSON(-LD) format.

If you have discovered bug, I would ask you to provide a reproducible test case, preferably as Gist, otherwise I would like to convert this issue in a discussion, as that seems more appropriate.

[ricardas-buc]

Thanks. Since its not directly identity hub issue- lets convert this one to discussion then. I will try using referenced verification and see if it works.

Still, LdpVerifier and DataIntegrityKeyPair code looks a bit misleading or wrong. In any case, if that part will continue blocking me - will report with a gist in connector repo :)

[paullatzelsperger]

I would also recommend reading up on the related specifications and material about Linked-data proofs, in particular the W3C VC Data Model, the W3C JsonWebSignature2020 Specification and the W3C VC Data Integrity document, but like i said, if you have specific suggestions for improvements, feel free to raise a well-scoped issue.

just be aware that when adding linked proofs to a VC, they must subsequently be resolvable, e.g. via a DID resolver, a HTTP resolver, or some other method, otherwise the verification fails.