Re: Future-proofing VCs via multiple signatures

Consider adopting the Structured Credential Envelope model - described at a high level here: https<https://youtu.be/kM30pd3w8qE>://youtu.be/<https://youtu.be/kM30pd3w8qE>kM30pd3w8qE<https://youtu.be/kM30pd3w8qE> <https://youtu.be/kM30pd3w8qE> (and in more detail here: https<https://youtu.be/9RLYS7Xvabc>://youtu.be/9RLYS7Xvabc<https://youtu.be/9RLYS7Xvabc>)

If different constituencies/jurisdictions/marketplaces require different forms of verification for a specific set of credentialSubject claims, package a copy of the credentialSubject inside different Credential Envelopes ...each with their own proof ...each packaged in their own Envelope.

Michael

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: Thursday, January 6, 2022 9:59:27 AM
To: Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Future-proofing VCs via multiple signatures


I might be missing something here, but doesn’t this approach open up an attack/abuse vector?



For this to work, the proof is over everything except the stuff in the `proofs` key..otherwise, you couldn’t have multiple values…. Correct?



Since each of the signatures/proofs is associated with a different key pair – how does the validator know which one(s) to trust?  What prevents a bad actor from adding their own proof on a VC after the original issuer one has expired?





The other question this raises for me is about use cases for this approach.  If I were an education institution that offers joint accreditation with a secondary institution – would you see this as a way for the VCs that we issue to have signatures from *both* institutions??



Leonard



From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thursday, January 6, 2022 at 10:34 AM
To: W3C Credentials CG <public-credentials@w3.org>
Subject: Future-proofing VCs via multiple signatures

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmsporny%2Fab415042ffd9c06ea3ad1ebd1df1da0a&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887059226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dVDE5OU3h%2BuOSwsPnD360JnU8TLosFQ3zvA6Cz0ylec%3D&amp;reserved=0

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887069177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3yElzs5jz29lqnEpWrgtg%2FSjioalohnVzYH1OYRxqaM%3D&amp;reserved=0
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7C9fbb6d55fc3c4b3cd22908d9d129db83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770800887069177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xn6CCPBznKLpcyy%2FiRby0TKDav%2BnSC%2FYE85nB1MtK6k%3D&amp;reserved=0