Closed francis-pouatcha closed 1 year ago
About Crypto Key registry: https://w3c-ccg.github.io/ld-cryptosuite-registry/
We will be using this: https://w3c-ccg.github.io/ld-cryptosuite-registry/#jcs-ed25519-signature-2020
We do not need a verification relationship for key agreement in the first version. Francis will research on this first. As we will need the key agreement key of the mediator.
The document on VC data integrity uses this example: https://w3c.github.io/vc-data-integrity/#example-key-agreement-property-containing-two-verification-methods
Example refers to X25519KeyAgreementKey2019 as key agreement key spac.
See General Document on proof creation: https://w3c.github.io/vc-data-integrity/
Sample implementation of DID and VC in Javascript: https://github.com/transmute-industries/verifiable-data
A library for producing canonical JSON https://github.com/ahdinosaur/json-canon
Notify @francis-pouatcha
I guess there is really no need in redefining the diddoc
and vc
data models as per their specifications ourselves. While I can find the former in the aries-vcx
project, I fail to do so for the latter, which sounds really weird to me. The project seems to disregard the W3C standard on the VC data model.
However, I came across another project that is just perfect: https://github.com/spruceid/ssi/tree/main. But I doubt it would be acceptable to include in what I'm tasked with.
Thus, I would require more clarification on this matter. In the meantime, I'll just copy the diddoc
code from aries-vcx
and move ahead.
Hello @IngridPuppet i you can use https://github.com/spruceid/ssi/tree/main to achieve our target, please go ahead. We will take time an analyze how far we can get rely on their components. I will heavily depend on whether they have a open an clean governance.
For now you can use their components for our prototype.
Please define the rout of the pop endpoint to be /.well-known/did/pop.json