Re: Future-proofing VCs via multiple signatures

On 1/6/22 11:59 AM, Leonard Rosenthol wrote:
> I might be missing something here, but doesn’t this approach open up an 
> attack/abuse vector?

You're missing something here, but in a good way! :P

It's basically what Bob Wyman said... more below:

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

The Data Integrity spec (was Linked Data Proofs/Signatures) signs everything,
including all of the values in the `proof` block, excluding the final
signature itself.

Unlike (JWS Unprotected Header), there is no option to NOT sign something (and
introduce a security vulnerability). With Data Integrity Proofs, everything
that can be signed, must be signed.

You can have two types of Data Integrity Proofs; Proof Sets and Proof Chains:

https://w3c-ccg.github.io/data-integrity-spec/#multiple-proofs

A proof set is useful when the same data needs to be secured by multiple
entities, but where the order of proofs does not matter, such as in the case
of a set of signatures on a contract.

A proof chain is useful when the same data needs to be signed by multiple
entities and the order of when the proofs occurred matters, such as in the
case of a notary counter-signing a proof that had been created on a document.

If you're doing a proof set, the other proofs are not signed over. If you're
doing a proof chain, all the existing proofs are included (in the order in
which they were added) in the signature of the new proof you're adding.

> Since each of the signatures/proofs is associated with a different key pair
> – how does the validator know which one(s) to trust?

With a Verifiable Credential, the /verifier/ (not validator) will check the
following things:

1. The vc.issuer value is an issuer that they trust to
   issue the VC being issued. It is the /validator/ that
   instructs the verifier software on what issuer(s)
   should be trusted.

2. At least one of the vc.proofs[...].verificationMethod
   is associated with the vc.issuer above. That means that
   the issuer claims the verificationMethod is theirs for
   the purposes of creating a VC (assertionMethod in a DID
   Document, for example).

With those two checks, the verifier knows which signatures it can trust for
the VC it is checking.

> What prevents a bad actor from adding their own proof on a VC after the
> original issuer one has expired?

A bad actor can always do this, and a verifier can detect that it has been done.

To state this plainly; The bank doesn't care if your 3 year old kid "signed"
their name in crayon on your loan agreement... They just care that /you/ have
a signature on that agreement.

What happens when a signature in a set is added is up to the verifier. It could:

1. Reject any VC where there is an unknown issuer
   signature. This would probably be the wrong thing to do
   in most cases. The bank might do this because they
   don't want a 3 year olds crayon on their official
   paperwork.

2. Only accept a VC if there is at least ONE signature
   from at least one issuer that it trusts for the
   purposes of the transaction. This is probably the right
   thing to do. The bank goes "oh, how cute, and this
   is on a non-signature page so it's fine." and moves
   on.

3. A bunch of other approaches that depend on if you're
   looking for one or more signatures from one or more
   verificationMethods. There's a lot of variability here,
   and it's not worth going into in this thread.

Also note that with Proof Sets... the Holder only needs to send the signatures
that the issuer requested (if it specified any). With Proof Sets, you can
remove all but the signature(s) that the verifier is expecting and everything
is still secure and will verify.

> 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??

Yes, although those use cases have tended to be a bit navel-gazing over time.
We've had those sorts of discussions with a number of education institutions
and most of them tend to just give ONE entity signing authority.

So, yes, this would be a mechanism to do that (we'd have to discuss whether
`issuer` in a VC can be an array -- I see no reason why it couldn't be)... but
then that's extra complexity that people seem to do just fine without for now.
Another approach there is a single DID owned by a multi-sig
verificationMethod. There are a number of ways that we could do this in the
future, but it hasn't been a pressing requirements for any use case that I've
heard of over the past decade (that hasn't been solved in another way).

-- 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/

Received on Friday, 7 January 2022 18:04:49 UTC