Multi-signature Verifiable Credentials

Jack TannerTue, Sep 27, 5:00 PM
Hi CCG Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly
Hi CCG

Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly call. It uses the existing W3C CCG's verifiable condition standard to specify such conditions in the DID Document.

Please see the presentation for context. We have several questions:
  1. What should the proof look like?
  2. Which VC library would make the most sense for the initial implementation?

Open to hearing thoughts and opinions on the questions above.

I am pasting here if the links that Orie posted in the chat during the call:
https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660

Cheers,
Jack

--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
David ChadwickWed, Sep 28, 11:03 AM
Hi Jack We (Spruce and Crossword) are also working on this topic in the NGI Atlantic project. We are proposing two different mechanisms for JWT proofed VCs: serial signing and concurrent signing.

Hi Jack

We (Spruce and Crossword) are also working on this topic in the NGI Atlantic project. We are proposing two different mechanisms for JWT proofed VCs: serial signing and concurrent signing. Serial signing does not require any changes to the VC DM JWT signing algorithm, since the JWT output from the first signing can be used as the payload for the second signing. This process can be recursed as often as required. For concurrent signing we are proposing to use JSON Web Signatures with JSON Serialization from RFC 7515. We do not need the compact encoding since the JWT VC wont in general be passed as a token, but rather as a payload in any transfer protocol (such as OIDC4VCs). We are proposing to implement this in the next month or so.

Kind regards

David


On 27/09/2022 18:00, Jack Tanner wrote:
Hi CCG

Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly call. It uses the existing W3C CCG's verifiable condition standard to specify such conditions in the DID Document.

Please see the presentation for context. We have several questions:
  1. What should the proof look like?
  2. Which VC library would make the most sense for the initial implementation?

Open to hearing thoughts and opinions on the questions above.

I am pasting here if the links that Orie posted in the chat during the call:
https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660

Cheers,
Jack

--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Julien FraichotWed, Sep 28, 12:28 PM
Hi Jack, With Blockcerts we are supporting multiple signature. At this moment we only support chained signature, and for lack of a better option at the time, we settled with the ChainedProof2021

Hi Jack,

 

With Blockcerts we are supporting multiple signature. At this moment we only support chained signature, and for lack of a better option at the time, we settled with the ChainedProof2021 proposal: https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/SJoDWwTdK (which comes with this issue for context: https://github.com/w3c/vc-data-integrity/issues/26).

 

I am not too favorable to having the previous proof redundant in the next proof and would rather see something different, especially, as you point out, that we are also hashing the previous proof in the next proof.

 

As for the signature suite, we are mainly using MerkleProof2019, although we do now also have support for EcdsaSecp256k1Signature2019 and Ed25519Signature2020.

Nothing is set in stone but I would be happy to see one standard emerge that would be flexible enough for everyone.

 

Best

 

Julien

 

From: Jack Tanner <jack@tonomy.foundation>
Date: Wednesday, 28 September 2022 at 10:08
To: public-credentials@w3.org <public-credentials@w3.org>
Cc: rebal@tonomy.foundation <rebal@tonomy.foundation>, Suneet Bendre <bendre.android@gmail.com>
Subject: [EXTERNAL] [jfraichot@learningmachine.com] Multi-signature Verifiable Credentials

CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi CCG

 

Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly call. It uses the existing W3C CCG's verifiable condition standard to specify such conditions in the DID Document.

 

Please see the presentation for context. We have several questions:

  1. What should the proof look like?
  2. Which VC library would make the most sense for the initial implementation?

 

Open to hearing thoughts and opinions on the questions above.

 

I am pasting here if the links that Orie posted in the chat during the call:

https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660

 

Cheers,

Jack

 

--

_________________________________________

Image removed by sender.

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

Image removed by sender. Image removed by sender.

 

----------------------------------------- Please consider the environment before printing this e-mail -----------------------------------------

CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.
Jack TannerFri, Sep 30, 9:30 AM
Hey all Just wanted to share an update. We have successfully implemented multiple signatures using the existing did-jwt and did-jwt-vc libraries by DIF. If you want to see a summary of the decision and
Hey all

Just wanted to share an update. We have successfully implemented multiple signatures using the existing did-jwt and did-jwt-vc libraries by DIF. If you want to see a summary of the decision and strategy and invite you to check this one-pager summary here (feel free to comment there as well if you like):

We believe this complies with the DID, VC, JWS and JWT standards, no modifications are needed.

You can also see the working implementation here, currently on feature branches from the forked repositories:

On Wed, 28 Sept 2022 at 14:28, Julien Fraichot <Julien.Fraichot@hyland.com> wrote:

Hi Jack,

 

With Blockcerts we are supporting multiple signature. At this moment we only support chained signature, and for lack of a better option at the time, we settled with the ChainedProof2021 proposal: https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/SJoDWwTdK (which comes with this issue for context: https://github.com/w3c/vc-data-integrity/issues/26).

 

I am not too favorable to having the previous proof redundant in the next proof and would rather see something different, especially, as you point out, that we are also hashing the previous proof in the next proof.

 

As for the signature suite, we are mainly using MerkleProof2019, although we do now also have support for EcdsaSecp256k1Signature2019 and Ed25519Signature2020.

Nothing is set in stone but I would be happy to see one standard emerge that would be flexible enough for everyone.

 

Best

 

Julien

 

From: Jack Tanner <jack@tonomy.foundation>
Date: Wednesday, 28 September 2022 at 10:08
To: public-credentials@w3.org <public-credentials@w3.org>
Cc: rebal@tonomy.foundation <rebal@tonomy.foundation>, Suneet Bendre <bendre.android@gmail.com>
Subject: [EXTERNAL] [jfraichot@learningmachine.com] Multi-signature Verifiable Credentials

CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi CCG

 

Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly call. It uses the existing W3C CCG's verifiable condition standard to specify such conditions in the DID Document.

 

Please see the presentation for context. We have several questions:

  1. What should the proof look like?
  2. Which VC library would make the most sense for the initial implementation?

 

Open to hearing thoughts and opinions on the questions above.

 

I am pasting here if the links that Orie posted in the chat during the call:

https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660

 

Cheers,

Jack

 

--

_________________________________________

Image removed by sender.

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

Image removed by sender. Image removed by sender.

 

----------------------------------------- Please consider the environment before printing this e-mail -----------------------------------------

CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Orie SteeleFri, Sep 30, 2:02 PM
Great work! I'd love to hear from @Mike Jones @Kristina Yasuda @Tobias Looker regarding multisignature JWS / CWS and standardization and adoption. Regards, OS On Fri, Sep 30, 2022 at 4:33 AM Jack
Great work!

I'd love to hear from @Mike Jones @Kristina Yasuda @Tobias Looker regarding multisignature JWS / CWS and standardization and adoption.

Regards,

OS

On Fri, Sep 30, 2022 at 4:33 AM Jack Tanner <jack@tonomy.foundation> wrote:
Hey all

Just wanted to share an update. We have successfully implemented multiple signatures using the existing did-jwt and did-jwt-vc libraries by DIF. If you want to see a summary of the decision and strategy and invite you to check this one-pager summary here (feel free to comment there as well if you like):

We believe this complies with the DID, VC, JWS and JWT standards, no modifications are needed.

You can also see the working implementation here, currently on feature branches from the forked repositories:

On Wed, 28 Sept 2022 at 14:28, Julien Fraichot <Julien.Fraichot@hyland.com> wrote:

Hi Jack,

 

With Blockcerts we are supporting multiple signature. At this moment we only support chained signature, and for lack of a better option at the time, we settled with the ChainedProof2021 proposal: https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/SJoDWwTdK (which comes with this issue for context: https://github.com/w3c/vc-data-integrity/issues/26).

 

I am not too favorable to having the previous proof redundant in the next proof and would rather see something different, especially, as you point out, that we are also hashing the previous proof in the next proof.

 

As for the signature suite, we are mainly using MerkleProof2019, although we do now also have support for EcdsaSecp256k1Signature2019 and Ed25519Signature2020.

Nothing is set in stone but I would be happy to see one standard emerge that would be flexible enough for everyone.

 

Best

 

Julien

 

From: Jack Tanner <jack@tonomy.foundation>
Date: Wednesday, 28 September 2022 at 10:08
To: public-credentials@w3.org <public-credentials@w3.org>
Cc: rebal@tonomy.foundation <rebal@tonomy.foundation>, Suneet Bendre <bendre.android@gmail.com>
Subject: [EXTERNAL] [jfraichot@learningmachine.com] Multi-signature Verifiable Credentials

CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi CCG

 

Here is the presentation outlining the work that Tonomy Foundation is undertaking to allow multiple signatures and delegated signatures on verifiable credentials that I just gave at the weekly call. It uses the existing W3C CCG's verifiable condition standard to specify such conditions in the DID Document.

 

Please see the presentation for context. We have several questions:

  1. What should the proof look like?
  2. Which VC library would make the most sense for the initial implementation?

 

Open to hearing thoughts and opinions on the questions above.

 

I am pasting here if the links that Orie posted in the chat during the call:

https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660

 

Cheers,

Jack

 

--

_________________________________________

Image removed by sender.

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

Image removed by sender. Image removed by sender.

 

----------------------------------------- Please consider the environment before printing this e-mail -----------------------------------------

CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries


Manu SpornySat, Oct 1, 6:51 PM
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote: > What should the proof look like? We're trying to lock this down over the next couple of weeks in the VCWG. The
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

-- 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/
Jack TannerMon, Oct 3, 10:15 AM
For the cases that we are looking at * Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC) * Using multiple proofs to perform chain-based multi-
For the cases that we are looking at
* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

Proof sets for JSON-LD format is also a great approach.

Cheers,
Jack

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Markus SabadelloMon, Oct 3, 11:32 AM
For me, whenever I hear the term "multi-signature", my first question is always if the "multi-signature" happens on the cryptographic layer (ie a single signature is created using

For me, whenever I hear the term "multi-signature", my first question is always if the "multi-signature" happens on the cryptographic layer (i.e. a single signature is created using multiple keys) or if happens elsewhere in the data model or protocol layer (e.g. multiple signatures are attached to a VC or JWT or whatever).

My understanding of Verifiable Conditions is that they are about the latter, i.e. they do multiple proofs and combine them in flexible ways.

Manu's list may also be missing a few things that can be done with Verifiable Conditions, e.g.:

* Using multiple proofs to perform M of N threshold multi-signature.

Markus

On 03.10.22 12:15, Jack Tanner wrote:
For the cases that we are looking at
* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

Proof sets for JSON-LD format is also a great approach.

Cheers,
Jack

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Jack TannerMon, Oct 10, 8:37 AM
Hey @Manu Sporny What are the options you are considering for how to verify that a M/N proof set contains the required number of signatures? How do you express the condition for this? What we are doing
Hey @Manu Sporny 

What are the options you are considering for how to verify that a M/N proof set contains the required number of signatures? How do you express the condition for this?

What we are doing here is using the W3C Verifiable Condition, a verification method type. I am wondering if you have got a different approach?

Cheers,
Jack

On Mon, 3 Oct 2022 at 12:15, Jack Tanner <jack@tonomy.foundation> wrote:
For the cases that we are looking at
* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

Proof sets for JSON-LD format is also a great approach.

Cheers,
Jack

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Manu SpornyMon, Oct 10, 10:39 PM
On Mon, Oct 10, 2022 at 4:37 AM Jack Tanner <jack@tonomy.foundation> wrote: > What are the options you are considering for how to verify that a M/N proof set contains the required number of
On Mon, Oct 10, 2022 at 4:37 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What are the options you are considering for how to verify that a M/N proof set contains the required number of signatures?

I should probably start by saying that we (Digital Bazaar) hasn't
found a super strong market need for M-of-N threshold signatures yet.
It doesn't mean that it doesn't exist, just that we haven't found it
yet. :)

That's further complicated by there being multiple design paths for
implementing M-of-N (either as a single "anonymous" signature or
multiple signatures).

> How do you express the condition for this?

There are multiple ways... I'd suggest to use the easiest to implement
mechanism in order to make sure that others have an easy time
implementing it.

> What we are doing here is using the W3C Verifiable Condition, a verification method type. I am wondering if you have got a different approach?

The VerifiableCondition2021 mechanism does seem to cover all of the
possible cases. I would argue that it might be too complex to
implement and have it pass a security review. You might consider
breaking threshold signatures into separate use cases and then using a
different type for each use case. What's the simplest threshold
signature you can model... start with that (and specifically don't
include support for weights or arbitrary branching logic such as
conditionAnd or conditionOr). So, start with something simple like
this:

{
    "id": "did:example:123#4",
    "controller": "did:example:123",
    "type": "ThresholdVerification2022",
    "threshold": 3,
    "verificationMethod": [A, B, C, D, E]
}

... and then use standard Data Integrity proof sets to collect the
signatures on the thing you're signing:

https://w3c.github.io/vc-data-integrity/#proof-sets

There is a challenge there in that you're going to have to figure out
how to communicate both the ThresholdVerification2022 Verification
Method as well as the specific public key that generated each
signature, which probably means defining a new cryptosuite for
threshold signatures.

All that said, you've probably thought about this problem far more
deeply than I have given your work on VerifiableCondition2021. My only
advice is that that prior work might be too complicated to catch on
and so you might try something more focused that achieves a large
number of use cases (without trying to solve all of them with a single
verification method scheme).

-- 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/
Dave LongleyTue, Oct 11, 3:21 PM
On Mon, Oct 10, 2022 at 4:37 AM Jack Tanner <jack@tonomy.foundation> wrote: > What are the options you are considering for how to verify that a M/N proof set contains the required number of
On Mon, Oct 10, 2022 at 4:37 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What are the options you are considering for how to verify that a M/N proof set contains the required number of signatures?

Another option is to actually hide all the details around how a
special signature is produced from verifiers and, instead, expose a
simple signature for verification. In other words, design your system
such that there is a key hidden away in an HSM that will only perform
a signature if you send it (or it eventually "collects") whatever it
needs (be that M-of-N other signatures or anything else). You are then
able to implement this however you want to -- and avoid exposing those
details to every external (and perhaps unknown) verifier, in the hopes
that they will all implement your complex verification scheme.

There may be details that could make this approach unworkable for your
use case(s), but it should be considered first as it puts less burden
on interop with verifiers and allows for more experimentation hidden
away in the implementation details.

--
Dave Longley
CTO
Digital Bazaar, Inc.
Christopher AllenSat, Oct 15, 6:59 PM
On Tue, Oct 11, 2022 at 8:24 AM Dave Longley <dlongley@digitalbazaar.com> wrote: Another option is to actually hide all the details around how a special signature is produced from verifiers and,
On Tue, Oct 11, 2022 at 8:24 AM Dave Longley <dlongley@digitalbazaar.com> wrote:
Another option is to actually hide all the details around how a
special signature is produced from verifiers and, instead, expose a
simple signature for verification. In other words, design your system
such that there is a key hidden away in an HSM that will only perform
a signature if you send it (or it eventually "collects") whatever it
needs (be that M-of-N other signatures or anything else). You are then
able to implement this however you want to -- and avoid exposing those
details to every external (and perhaps unknown) verifier, in the hopes
that they will all implement your complex verification scheme.

This is the design pattern that Bitcoin has adopted in the latest consensus soft-fork called "taproot", and also we are puzzling through it for our own Gordian Envelope CBOR redactable triple-store (see demo at https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Transcripts/1-OVERVIEW-TRANSCRIPT.md)

In bitcoin taproot, there are two parts: 

* The first is a simple "optimistic" proof with a only single signature for verifiers (Schnorr). However, in fact, this "single" signature may be from an off-chain non-accountable multisignature threshold (i.e. you don't know who joined the threshold, just that the final signature is valid).

aka:

On Sat, Oct 1, 2022 at 11:54 AM Manu Sporny <msporny@digitalbazaar.com> wrote:
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

* a second is a hash tree of proofs, where lots of different business processes can be involved in offline, including both accountable (you know who signed) and non-accountable proofs.

Currently, in our Gordian Envelope POA (proof of architecture) all of our signatures are single signature Schnorr, but you must presume that they likely were generated from a threshold quorum, not a single private key (note that quorum may not be multi-person, for instance, it might be an MPC key ceremony between a hardware key, mobile software wallet key, and an online service key, all controlled by a single person).

We also considering allowing for #SmartSignatures as well, which are script-like rules for signatures where the script is part of the signature, which parallels the 2nd half of bitcoin taproot. 


If you are interested in participating in a developer community working through these various multi-party computing approaches for credentials, contact me.

-- Christopher Allen

Snorre Lothar von Gohren EdwinTue, Oct 18, 1:51 PM
I would love to understand what customers are asking for to translate this logic into human needs. Because we are facing a situation where credentials have had the Presidents signature on them(
I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.
ᐧ

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:
For the cases that we are looking at
* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

Proof sets for JSON-LD format is also a great approach.

Cheers,
Jack

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:
On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 


--
Snorre Lothar von Gohren Edwin
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter
steve.e.magennis@gmail.comTue, Oct 18, 2:44 PM
Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC's are great for preserving the intent of one or more parties *at a given point in

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack

 

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


 

--

_________________________________________

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

 


 

--

Snorre Lothar von Gohren Edwin

Co-Founder & CTO, Diwala

+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter

John, AnilTue, Oct 18, 4:30 PM
Speaking as a “Real, Live Customer” the following is what I am looking for: The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential A proof

Speaking as a “Real, Live Customer” the following is what I am looking for:

 

  • The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
    • A proof that is using FIPS Compliant Cryptographic Primitives
    • A proof that is using Post-Quantum Cryptographic Primitives
    • A proof that is using BBS Cryptographic Primitives for Selective Disclosure
  • A mechanism for the Digital Wallet to signal to an Issuer that it is capable of supporting the above
  • A mechanism for the Digital Wallet to signal to a Verifier about the proof formats it has available on a particular credential
  • A mechanism for the Verifier to signal to the Holder/Wallet about the proof formats it supports

 

Intent

  • Cryptographic agility / flexibility to transition to new primitives without the holder being impacted
  • Ability to have a FIPS compliant baseline for cryptography as a default while at the same time supporting “experimental/standards-track” cryptography that counter-parities may support on a faster timeline

 

Best Regards,

 

Anil

 

Anil John

Technical Director, Silicon Valley Innovation Program

Science and Technology Directorate

US Department of Homeland Security

Washington, DC, USA

 

Email Response Time – 24 Hours

 

A picture containing graphical user interface Description automatically generated/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395

 

From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
Sent: Tuesday, October 18, 2022 10:44 AM
To: 'Snorre Lothar von Gohren Edwin' <snorre@diwala.io>; 'Jack Tanner' <jack@tonomy.foundation>
Cc: 'Manu Sporny' <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; 'Suneet Bendre' <bendre.android@gmail.com>
Subject: RE: Multi-signature Verifiable Credentials

 

CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.

 

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

Image removed by sender.ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack

Snorre Lothar von Gohren EdwinTue, Oct 25, 11:06 AM
Thanks for all these responses guys! On Tue, Oct 18, 2022 at 6:35 PM John, Anil <anil.john@hq.dhs.gov> wrote: Speaking as a “Real, Live Customer” the following is what I am looking for: The
Thanks for all these responses guys!

On Tue, Oct 18, 2022 at 6:35 PM John, Anil <anil.john@hq.dhs.gov> wrote:

Speaking as a “Real, Live Customer” the following is what I am looking for:

 

  • The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
    • A proof that is using FIPS Compliant Cryptographic Primitives
    • A proof that is using Post-Quantum Cryptographic Primitives
    • A proof that is using BBS Cryptographic Primitives for Selective Disclosure
  • A mechanism for the Digital Wallet to signal to an Issuer that it is capable of supporting the above
  • A mechanism for the Digital Wallet to signal to a Verifier about the proof formats it has available on a particular credential
  • A mechanism for the Verifier to signal to the Holder/Wallet about the proof formats it supports

 

Intent

  • Cryptographic agility / flexibility to transition to new primitives without the holder being impacted
  • Ability to have a FIPS compliant baseline for cryptography as a default while at the same time supporting “experimental/standards-track” cryptography that counter-parities may support on a faster timeline

 

Best Regards,

 

Anil

 

Anil John

Technical Director, Silicon Valley Innovation Program

Science and Technology Directorate

US Department of Homeland Security

Washington, DC, USA

 

Email Response Time – 24 Hours

 

A picture containing graphical user interface Description automatically generated/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395

 

From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
Sent: Tuesday, October 18, 2022 10:44 AM
To: 'Snorre Lothar von Gohren Edwin' <snorre@diwala.io>; 'Jack Tanner' <jack@tonomy.foundation>
Cc: 'Manu Sporny' <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; 'Suneet Bendre' <bendre.android@gmail.com>
Subject: RE: Multi-signature Verifiable Credentials

 

CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.

 

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

Image removed by sender.ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack



--
Snorre Lothar von Gohren Edwin
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter
Steve CapellTue, Oct 25, 12:43 PM
Yes me too - keen to understand how the same credential can have multiple proof methods - especially when one of them is selective disclosure Steven Capell Mob: 0410 437854 > On 19 Oct 2022, at 3:35
Yes me too - keen to understand how the same credential can have multiple proof methods - especially when one of them is selective disclosure 

Steven Capell
Mob: 0410 437854

> On 19 Oct 2022, at 3:35 am, John, Anil <anil.john@hq.dhs.gov> wrote:
> 
> 
> Speaking as a “Real, Live Customer” the following is what I am looking for:
>  
> The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
> A proof that is using FIPS Compliant Cryptographic Primitives
> A proof that is using Post-Quantum Cryptographic Primitives
> A proof that is using BBS Cryptographic Primitives for Selective Disclosure
> A mechanism for the Digital Wallet to signal to an Issuer that it is capable of supporting the above
> A mechanism for the Digital Wallet to signal to a Verifier about the proof formats it has available on a particular credential
> A mechanism for the Verifier to signal to the Holder/Wallet about the proof formats it supports
>  
> Intent
> Cryptographic agility / flexibility to transition to new primitives without the holder being impacted
> Ability to have a FIPS compliant baseline for cryptography as a default while at the same time supporting “experimental/standards-track” cryptography that counter-parities may support on a faster timeline
>  
> Best Regards,
>  
> Anil
>  
> Anil John
> Technical Director, Silicon Valley Innovation Program
> Science and Technology Directorate
> US Department of Homeland Security
> Washington, DC, USA
>  
> Email Response Time – 24 Hours
>  
> 
>  
> From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com> 
> Sent: Tuesday, October 18, 2022 10:44 AM
> To: 'Snorre Lothar von Gohren Edwin' <snorre@diwala.io>; 'Jack Tanner' <jack@tonomy.foundation>
> Cc: 'Manu Sporny' <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; 'Suneet Bendre' <bendre.android@gmail.com>
> Subject: RE: Multi-signature Verifiable Credentials
>  
> CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.
>  
> Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.
>  
> -S
>  
> From: Snorre Lothar von Gohren Edwin <snorre@diwala.io> 
> Sent: Tuesday, October 18, 2022 6:52 AM
> To: Jack Tanner <jack@tonomy.foundation>
> Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
> Subject: Re: Multi-signature Verifiable Credentials
>  
> I would love to understand what customers are asking for to translate this logic into human needs.
> 
> Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.
> 
> What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
> While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.
> 
> What are your thoughts on this?
> 
> Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.
> ᐧ
>  
> On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:
> For the cases that we are looking at
> * Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
> * Using multiple proofs to perform chain-based multi-signature.
> * Using multiple proofs to perform multi-level/enveloped multi-signature.
> * Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
> * Using a single proof to perform chain-based multi-signature.
> * Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
> * Using a single proof to perform privacy-preserving M of N  threshold
> multi-signature.
>  
> Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.
>  
> Proof sets for JSON-LD format is also a great approach.
>  
> Cheers,
> Jack
Manu SpornyTue, Oct 25, 2:59 PM
On Tue, Oct 18, 2022 at 12:35 PM John, Anil <anil.john@hq.dhs.gov> wrote: > The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
On Tue, Oct 18, 2022 at 12:35 PM John, Anil <anil.john@hq.dhs.gov> wrote:
> The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
>
> A proof that is using FIPS Compliant Cryptographic Primitives
> A proof that is using Post-Quantum Cryptographic Primitives
> A proof that is using BBS Cryptographic Primitives for Selective Disclosure

As mentioned in the previous email, this is supported by VC Data Integrity:

https://w3c.github.io/vc-data-integrity/#proof-sets

We'll find out how many implement the feature, which is not difficult
to implement if you support a single Data Integrity proof, when we get
to the Candidate Recommendation phase.

> A mechanism for the Digital Wallet to signal to an Issuer that it is capable of supporting the above

This would probably be a privacy violation if done on a per-individual
basis (it could broadcast which types of DIDs the individual has). For
example, if you are using a type of cryptography that is used by a
particular nation state, it would out you as potentially having ties
with that nation state.

If this is done at the wallet level, it's probably not useful
information. Just because a digital wallet supports 20 DID Methods
doesn't mean that the individual using the wallet actually has all 20
of those DID Methods at their disposal.

A design with a better privacy position would be for the Verifier to
assert that it supports verifying certain types of digital signatures.
This is the approach that the VC API has taken with Verifiable
Presentation Requests and is shown in the DIDAuthentication flows here
(note the "acceptedMethods" and "acceptedCryptosuites" fields.):

https://w3c-ccg.github.io/vp-request-spec/#the-did-authentication-query-format

> A mechanism for the Digital Wallet to signal to a Verifier about the proof formats it has available on a particular credential

Same as the comment above. The Digital Wallet signalling specifics
about what it holds on a per-individual basis can lead to privacy
violations. The Digital Wallet signalling its feature set, in general,
might not be useful in this particular scenario (but might be useful
in others, like asserting that it passes certain industry
certifications).

> A mechanism for the Verifier to signal to the Holder/Wallet about the proof formats it supports

What's the use case here? Is it: "Verifier Gamma would like to offer a
Verifiable Credential in a format that the Holder will be able to
process."? Why isn't this driven off of something like the
"acceptedCryptosuites" field in DID Authentication -- given that, you
know what sort of cryptography the Holder software prefers and you can
issue using the same cryptography. OR, an Issuer might not care...
they might only issue using EdDSA and BBS, and when you get a VC, you
get it with both (because you had to prove possession for both in many
cases).

Thoughts?

-- 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/
John, AnilTue, Oct 25, 9:10 PM
Manu -- Just to be clear that if I knew HOW to implement WHAT I was looking for, I would be an Implementor and not a Customer :-) Anil > A mechanism for the Verifier to signal to the Holder/Wallet
Manu -- Just to be clear that if I knew HOW to implement WHAT I was looking for, I would be an Implementor and not a Customer :-)

Anil > A mechanism for the Verifier to signal to the Holder/Wallet about the 
Anil > proof formats it supports
Manu >> What's the use case here?

It is less of a use case and more of trying to think out loud around what the art of the possible is now and downstream.

USG Agencies, like my professional home, require that the technologies we use conform to relevant federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography. Federal Information Processing Standards Publications (FIPS PUBS) are the official series of publications relating to standards and guidelines adopted and promulgated under the provisions of FISMA.

Which is why SVIP funded the independent cryptography review of W3C VCs and W3C DIDs by SRI (http://www.csl.sri.com/papers/vcdm-did-crypto-recs/crypto-review-and-recs-for-VCDM-and-DIDs-implems-FINAL-20211015.pdf ).

So the default, immovable, baseline for us is the use of FIPS compliant cryptography primitives in our implementation of VCs and DIDs. So once that hard, legally mandated compliance requirement is met (which just so happens also provide security/privacy benefits beyond simple compliance), and based on individual agency goals as well as appetite, acceptance, and understanding of risk/rewards, there are additional options that are ... possible.

In particular we have some specific privacy requirements in our personal credential workstream (driven by U.S. Citizenship and Immigration Services) around selective disclosure and non-correlation to which the BBS Signature Scheme could provide solutions. We appreciate that it is on a legitimate and formal standards-track (https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/ ) in a forum (the IETF CFRG) that has international credibility and expertise -- at which the USG Technical Authority on Cryptography (NIST) participates. 

This has an impact on our internal risk/reward calculus on pre-standard use of this tech as our thinking is that there exists measurable and very real privacy benefits to individuals *in this particular case* and we may be willing to incur and accept additional risk to ensure that those benefits are realized by our customers on a faster time-line than is usual. We also acknowledge that private sector implementations may also exist at the pre-standard level.

So, in order for our customers to realize this benefit, I think some mechanism needs to exist for a Verifier/RP to say the following to a Customer/Holder when they show up at the front door >> "You don't need to send us all the attributes in your credential since we support BBS signatures .. If you support it as well, we just want attributes A and B for this is purpose, we will use and manage that information in the following manner X. Do you understand and consent to the release of A and B?"

Happy to explore other ways of reaching the same outcome as nothing is fixed/decided. But we do need more information in order to make thoughtful and informed decisions in this area.

Best Regards,

Anil
Jack TannerMon, Dec 5, 9:59 AM
We have now completed an implementation of the multi-signature and delegated VCs up and running using the DIF did-jwt(-vc) libraries! https://blog.tonomy.foundation/verifiable-credentials-with-provable
We have now completed an implementation of the multi-signature and delegated VCs up and running using the DIF did-jwt(-vc) libraries!

The above article explains what we've done and links the various works.

I'd like to add this as a discussion agenda point on tomorrow's weeks W3C CCG call. Eventually, we'd like to get this change approved and added to the upstream repos as well.

As part of this, we renamed "Verifiable Conditions" to "Conditional Proofs" as suggested in our call, and would like to see upstream change approved to the W3C CCG repo as well.

Cheers,
Jack

On Tue, 18 Oct 2022 at 16:44, <steve.e.magennis@gmail.com> wrote:

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack

 

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


 

--

_________________________________________

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

 


 

--

Snorre Lothar von Gohren Edwin

Co-Founder & CTO, Diwala

+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter



--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
Gabe CohenTue, Dec 6, 6:35 PM
Jack, awesome work! It would be great for you to add to this issue: https://github.com/w3c/vc-data-model/issues/932 which attempts to address “multiple issuers” in the VCDM. Perhaps your work could
Jack, awesome work!

It would be great for you to add to this issue: https://github.com/w3c/vc-data-model/issues/932 which attempts to address “multiple issuers” in the VCDM.

Perhaps your work could make it into the spec as a reference to VC-JWT or similar.

Gabe

On Dec 5, 2022 at 1:59:05 AM, Jack Tanner <jack@tonomy.foundation> wrote:
We have now completed an implementation of the multi-signature and delegated VCs up and running using the DIF did-jwt(-vc) libraries!

The above article explains what we've done and links the various works.

I'd like to add this as a discussion agenda point on tomorrow's weeks W3C CCG call. Eventually, we'd like to get this change approved and added to the upstream repos as well.

As part of this, we renamed "Verifiable Conditions" to "Conditional Proofs" as suggested in our call, and would like to see upstream change approved to the W3C CCG repo as well.

Cheers,
Jack

On Tue, 18 Oct 2022 at 16:44, <steve.e.magennis@gmail.com> wrote:

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack

 

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


 

--

_________________________________________

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

 


 

--

Snorre Lothar von Gohren Edwin

Co-Founder & CTO, Diwala

+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter



--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 
HarrisonSun, Dec 11, 4:50 PM
to Gabe CohenSnorre Lothar von Gohren Edwinrebal@tonomy.foundationsteve.e.magennis@gmail.comJack TannerManu Spornypublic-credentials@w3.orgSuneet Bendre
We've invited Jack and the Tonomy team to present and lead the discussion on this topic of "Multi-Signature Verifiable Credentials and Conditional Proofs" on 2/14/2023. Please continue
We've invited Jack and the Tonomy team to present and lead the discussion on this topic of "Multi-Signature Verifiable Credentials and Conditional Proofs" on 2/14/2023.  Please continue this great discussion!  

You can see the latest W3C CCG calendar here: https://www.w3.org/groups/cg/credentials/calendar.

Sincerely,
Harrison
    

On Tue, Dec 6, 2022 at 12:30 PM Gabe Cohen <gabe@tbd.email> wrote:
Jack, awesome work!

It would be great for you to add to this issue: https://github.com/w3c/vc-data-model/issues/932 which attempts to address “multiple issuers” in the VCDM.

Perhaps your work could make it into the spec as a reference to VC-JWT or similar.

Gabe

On Dec 5, 2022 at 1:59:05 AM, Jack Tanner <jack@tonomy.foundation> wrote:
We have now completed an implementation of the multi-signature and delegated VCs up and running using the DIF did-jwt(-vc) libraries!

The above article explains what we've done and links the various works.

I'd like to add this as a discussion agenda point on tomorrow's weeks W3C CCG call. Eventually, we'd like to get this change approved and added to the upstream repos as well.

As part of this, we renamed "Verifiable Conditions" to "Conditional Proofs" as suggested in our call, and would like to see upstream change approved to the W3C CCG repo as well.

Cheers,
Jack

On Tue, 18 Oct 2022 at 16:44, <steve.e.magennis@gmail.com> wrote:

Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.

 

-S

 

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: Tuesday, October 18, 2022 6:52 AM
To: Jack Tanner <jack@tonomy.foundation>
Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
Subject: Re: Multi-signature Verifiable Credentials

 

I would love to understand what customers are asking for to translate this logic into human needs.

Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.

What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else..

What are your thoughts on this?

Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.

ᐧ

 

On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:

For the cases that we are looking at

* Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

 

Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.

 

Proof sets for JSON-LD format is also a great approach.

 

Cheers,

Jack

 

On Sat, 1 Oct 2022 at 20:52, Manu Sporny <msporny@digitalbazaar.com> wrote:

On Wed, Sep 28, 2022 at 4:08 AM Jack Tanner <jack@tonomy.foundation> wrote:
> What should the proof look like?

We're trying to lock this down over the next couple of weeks in the
VCWG. The specific sections of the Data Integrity spec (with examples)
are here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-sets

and here:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/59.html#proof-chains

> Which VC library would make the most sense for the initial implementation?

Digital Bazaar's open source vc-js library will support proof sets and
chains (as specified in the Data Integrity spec by the VCWG) in
production. There is strong customer pull for proof sets. There is not
strong customer pull for proof chains, but given that we have the
opportunity to define a global standard for doing that AND because
there are use cases like notarization that are important, we plan to
add full support for that as well.

Regarding the concept of multi-signature, I am a bit concerned that
people are talking past each other as there are a number of categories
there and it's possible that not everyone is talking about the same
categories of multisig. There are at least these categories:

* Using multiple proofs to perform set-based multi-signature.
* Using multiple proofs to perform chain-based multi-signature.
* Using multiple proofs to perform multi-level/enveloped multi-signature.
* Using a single proof to perform set-based multi-signature.
* Using a single proof to perform chain-based multi-signature.
* Using a single proof to perform M of N threshold multi-signature.
* Using a single proof to perform privacy-preserving M of N  threshold
multi-signature.

So, when you say "multi-signature" -- which one of these things are
you talking about?

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


 

--

_________________________________________

Jack Tanner

Founder and Architect | Tonomy Foundation

p: (+31) 6 2216 5433

 


 

--

Snorre Lothar von Gohren Edwin

Co-Founder & CTO, Diwala

+47 411 611 94
www.diwala.io

Stay on top of Diwala news on social media! Facebook / LinkedIn / Instagram / Twitter



--
_________________________________________
Jack Tanner
Founder and Architect | Tonomy Foundation
p: (+31) 6 2216 5433
 


--
Harrison Tang
CEO
 LinkedIn  •   Twitter  •   Tiktok  •   Facebook
Want to share your email?
GET Streak SHARE


This email link is not publicly discoverable,
and is only shared at the discretion of the sender.
Privacy  |  Security

Opening...

Opening...

Click "Install now" in the

Safari Extension Gallery

Taking you to Gmail...

Install successful

Waiting for install...

Install by clicking the blue “Add to Chrome” button in the

Chrome Web Store

Sorry, Streak currently only supports Google Chrome, Safari, and Microsoft Edge.
Sign up to be notified when support is available for your browser.

Thank you! We'll let you know when it's available for other platforms!

Opening...