Verfiable credentials issuing workflow in MinimumViableDataspace

[alfonsoegio]

I've been working with the Minimum Viable Dataspace (MVD) to implement
an independent issuer service. This service should be capable of signing
credentials for participants in the MVD deployment.

I reviewed the implementation of the JWTSigner test class within the
Identity Hub's launcher directory. I was able to leverage the
issuer_private.pem file located under the deployment/assets path
to sign customized credentials running the JWTSigner test class
for new participants adding the inputs to the current consumer/producer
ones. This extends beyond the typical consumer/provider scenario.

I successfully tested the complete workflow using the Postman
collection. This includes steps like:

• Fetching cached catalogs Initiating negotiation for an asset
• Initiating a transfer Obtaining Electronic Data Records (EDRs)
• Proceeding with the data download endpoint

This workflow was validated for newly onboarded participants using
Terraform configurations. These configurations provision the necessary
pods with distinct DIDs, such as
did:web:alfonso-identityhub%3A7083:alfonso.

The process of signing membership and data processor credentials for
the desired DIDs using the issuer_private.pem key was successful.
These credentials are used for provisioning the identity hubs of new
participants able to follow the control plane postman collection
workflows. Upon further inspection of the JWTSigner source code, I
discovered that the JWS algorithm employed is EdDSA: My investigation
using OpenSSL confirmed that the issuer_private.pem key is indeed an
EdDSA key.

https://github.com/eclipse-edc/MinimumViableDataspace/blob/main/launchers/identity-hub/src/test/java/org/eclipse/edc/demo/dcp/JwtSigner.java#L60

$ openssl ec -in deployment/assets/issuer_private.pem -text -noout -param_out

read EC key
ED25519 Private-Key:
priv:
    f3:66:84:0f:12:a8:35:fd:14:4e:39:7e:e9:3f:a7:
    5f:a4:af:e3:19:40:4a:98:85:af:ba:5a:75:1a:b9:
    82:da
pub:
    84:ad:83:43:6c:d9:e3:2f:d0:1c:35:e2:df:1f:66:
    53:1e:92:0b:60:33:22:53:f8:34:ae:c1:8e:b7:c4:
    f5:63
read EC key

So, I thought that generating a new issuer_private.pem/issuer_public.pem keypair
from scratch like that:

openssl genpkey -algorithm ed25519 -out deployment/assets/issuer_private.pem

openssl ec -in deployment/assets/issuer_private.pem -text -noout -param_out


read EC key
ED25519 Private-Key:
priv:
    cb:73:48:64:c8:08:33:b3:1d:11:c9:93:1f:3b:75:
    c8:74:ca:27:37:35:8e:af:d0:9b:16:b4:15:db:26:
    87:4c
pub:
    f2:36:83:c0:01:c5:20:ef:61:24:1b:f4:89:dd:b1:
    7b:71:39:41:b3:43:ea:5c:b9:1a:c1:d7:b2:cd:59:
    bf:b4

openssl pkey -in deployment/assets/issuer_private.pem -pubout -out deployment/assets/issuer_public.pem

After a complete re-run of the tests, resulting in the generation of
new credentials, I thought that the system was able to operate as it
did in the prior scenario.

> Task :launchers:identity-hub:test

---------------------------------------------------------------
|  Results: SUCCESS (8 tests, 8 passed, 0 failed, 0 skipped)  |
---------------------------------------------------------------

But trying to access the GET catalog / cached catalog endpoints, I'm getting this API response
regarding an authorization issue:

{
 "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
}

• What are the potential issues involved in replacing the issuer
  keypair before proceeding with a deployment from scratch?

• In the current MVD implementation, what is the role of the
  consumer/producer keypair located within the deployment/assets path? I
  have successfully onboarded new participants who can execute control
  plane workflows using Postman without provisioning these key pair files.
  This was achieved by generating signed credentials using the JWTSigner
  workflow and the issuer_private.pem key from the upstream repository
  (not a newly generated one).

• What is the function of the CryptoConverter and PemParser classes
  from the connector repository in the verification workflow? It appears
  that there is support for additional RSA/EC algorithms, but I have
  been unable to sign a valid credential for the MVD (i.e. supporting
  the Postman workflow execution) using the standard Ed25519 (most
  common instance of EdDSA) with the commonly used node:crypto
  implementation and the jose package in a Node.js running
  environment.

Many thanks in advance.

[paullatzelsperger]

@alfonsoegio I transferred this discussion here, since your questions are clearly about MVD, not EDC.

in the IntelliJ-based deployment, every participant gets the same keypair. this is because there is no way for the connector and IH to share a HSM/vault with in-mem implementations. In the kubernetes deployment, keys are generated when creating participant contexts.

If you want to know the function of certain classes, I strongly recommend reading their code and javadoc. We can't provide individual 1:1 guidance in Github.

In terms of cryptography, EDC uses only standard algorithms, most of which are implemented by the Nimbus library, which is the de-facto standard library for Java. I don't know about node:crypto, nor do I care about it, since it's Node.js, not Java.

I recommend you familiarize yourself with EDC's documentation.

[alfonsoegio]

Thank you for your prompt reply! I will follow your advice and
continue reviewing the documentation and source code.

However, regarding replacing the existing issuer_private/public
keypair with a newly generated one using OpenSSL,
I'm encountering the mentioned issue and don't understand
what's going on.

I found a relevant README.md link from an old issue discussing key
generation procedures.

Could you please clarify what potential issues could arise when
replacing the keypair without proceeding with the KeyStore Explorer
managing steps?

KeyStore Explorer should be used to manage keystores (from UI). Using
openssl combined with keytool to obtain a JKS keystore will result in
a keystore the EDC cannot read (incompatible inclusion of key
parameters).

https://github.com/eclipse-edc/MinimumViableDataspace/tree/fb99832678eea0a16377a6cdd3cfaff2bc2bda06/system-tests

Are these instructions still valid in current MVD state of development?

[paullatzelsperger]

this issue is quite old, MVD and the upstream code base have been significantly refactored in the mean time. it bears no relevance anymore. The fact that the instructions document you mention isn't in the current code base should have been enough of a hint. No point in discussing it any further.

MVD is a demo that comes as-is without any guarantees or support. You are welcome to play around with it, generate new keys using the means provided by EDC (i.e. the JwtSigner utility, JDK and Nimbus Key generators), although you will be on your own there.

You are also welcome to ask questions in our discord channel, where you may get some support from the community.

[alfonsoegio]

Thank you for your clarification. I completely understand that the repository doesn't provide a finished or fully supported solution, and I did not mean to imply otherwise. My goal is to experiment with the demo and contribute where possible to align with my current project goals.

I appreciate the guidance on generating new keys using EDC tools, and I'll continue exploring the available resources. As I work through it, I'll also keep an eye on potential ways to improve interoperability and contribute back to the community if I discover anything useful.

I'll definitely check out the Discord channel for any additional insights. Thanks again for the direction, and I look forward to continuing to play around with MVD and seeing how it evolves.