search

w3c-ccg / vc-api

A specification for an HTTP API used to issue and verify Verifiable Credentials.
https://w3c-ccg.github.io/vc-api
Other
118 stars 44 forks source link

Proposal: The WG needs to agree to an interoperability profile that covers the suites #130

Closed OR13 closed 2 years ago

OR13 commented 3 years ago
msporny commented 3 years ago

I'm just going to write this down so we don't lose track of it:

  1. DB is supportive of this profile. Ed25519 for primary, and *384 for secondary is good.
  2. Bls is for selective disclosure, and is a fundamentally different cryptosuite -- I will note that we don't have a secondary if a flaw is found in Bls... and that's a problem. We should go into this profile with our eyes wide open on that particular issue.
  3. We should move to Ed25519VerificationKey2020 and Ed25519Signature2020 for the next iteration of the plugest.
OR13 commented 3 years ago

@tplooker is there another pairing friendly curve that we might use as a backup for bls12381 ?

tplooker commented 3 years ago

Yeap @OR13 BN Curves used by EPID, we elected not to use this curve as it is slower and less secure than BLS12-381.

tplooker commented 3 years ago

So to answer your question @msporny we could have BnBbsSignature2021 that would be functionally equivalent.

msporny commented 3 years ago

Yeap @OR13 BN Curves used by EPID, we elected not to use this curve as it is slower and less secure than BLS12-381.

+1 to having an alternative, no idea if BN should be the alternative (others that are qualified should make that decision). It's good to see CFRG working on this -- we may want to engage them more formally in the next couple of months, noting that we predict some sort of W3C WG that would like to have their input on a primary and backup pairing-friendly curve that wouldn't be susceptible to the same sorts of attacks.

It might also be useful to chase down Barreto, Naehrig, Lynn, and Scott to see where their current thinking is wrt. "what would you choose today for the primary and backup?"

mavarley commented 2 years ago

Agreed this is important, but more appropriate for https://github.com/w3c-ccg/vc-api-test-suite ?

Recommend we close this issue.

msporny commented 2 years ago

Agreed this is important, but more appropriate for https://github.com/w3c-ccg/vc-api-test-suite ?

Agreed. I'll also note that we have other test suites that we're working on that do not require an interop profile for all test suites... for example, the "soon to be moved to the CCG" VC API modular test suites don't test the actual signature, they just check to make sure the API exists and returns something that's well-formed:

... while the Ed25519 test suite uses the same API endpoints, but then checks the actual digital signature format:

This approach allows us to test the shape of the VC API without requiring any particular cryptosuite... and then we also have cryptosuite test suites that do require very specific output (proper digital signatures).