Re: Future-proofing VCs via multiple signatures

Since this is food for thought, here is a thought :)
Since JWS supports multi signatures, can’t we claim that jwt encoded VCs (kind of) already support this feature?

Best,
Nikos

> 6 Ιαν 2022, 5:33 μμ, ο χρήστης «Manu Sporny <msporny@digitalbazaar.com>» έγραψε:
> 
> Hey folks,
> 
> Just throwing this out there as food for thought for now. There has been a bit
> of debate in the VCWG about when certain signature formats will be standardized.
> 
> These have raised some questions, including: "When will BBS+ be through the
> IETF process?", "What are we going to do about post-quantum crypto?", "What
> about long-lived VCs?", "How do we enable stability and innovation at the same
> time in a VC wrt. the signature format?".
> 
> Historically, when developers have to sign data, we've been forced to pick a
> signature format and stick with it. So, historically, when you sign some data,
> you have to pick ONE signature format.
> 
> This is changing, both with VCs and the Data Integrity specs (was: Linked Data
> Proofs/Signatures), as well as with things like HTTP Signatures. You can now
> support multiple signatures on a piece of data.
> 
> For example, this is supported (but not officially standardized) today with VCs:
> 
> {
>  ... standard VC goes here ...,
>  proofs: [
>    {Ed25519Signature2020 goes here},
>    {BbsBlsSignature2020 goes here},
>    {PostQuantumSignature2022 goes here}
>  ]
> }
> 
> Here's a full example for a Verifiable Driver's License that has both an
> Ed25519 signature, BBS+ signature, and a (yet to be specified) post-quantum
> signature:
> 
> https://gist.github.com/msporny/ab415042ffd9c06ea3ad1ebd1df1da0a
> 
> What this means is that it is now possible to not have to depend on one
> signature format, and instead use multiple to meet different needs. The VC
> above supports NIST-approved cryptography today, while enabling the advanced
> use of BBS+ (if an organization would like to use it /before/ it is
> standardized at IETF), and also enabling protection if a quantum computer were
> to break both Ed25519 and BBS+... all on the same VC in a fairly compact
> format. The likelihood of all three signature formats being broken at the same
> time are exceedingly low. Couple this with the new VC refresh feature, and you
> can narrow the window in which a VC might be vulnerable even lower. So the
> answers to the questions above become the following:
> 
>> "When will BBS+ be through the IETF process?"
> 
> It matters less if you can put two signatures on the VC... one using crypto
> accepted by both IETF and NIST, and one with BBS+. This allows verifiers that
> want a IETF/NIST-approved signature to request it, while allowing other
> verifiers that want to live a bit more on the bleeding edge to do so by
> requesting BBS+ proof.
> 
>> "What are we going to do about post-quantum crypto?",
> 
> We can add schemes while they're being standardized at IETF/NIST and those
> that want to use them can, while those that don't can ask for an alternative
> signature on the VC.
> 
>> "What about long-lived VCs?"
> 
> Adding multiple signature types (elliptic curve, pairing friendly, and
> post-quantum) on the same VC increases the chances of that long-lived VC
> surviving the technical failure of one of the signature formats.
> 
>> "How do we enable stability and innovation at the same time in a VC wrt. 
>> the signature format?".
> 
> If organizations want to support stability and innovation at the same time,
> they can do so by including multiple signatures on a VC.
> 
> Again, food for thought...
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
> 
>