Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for multiple signatures/proofs #50

Closed
quartzjer opened this issue May 2, 2022 · 15 comments
Closed

Support for multiple signatures/proofs #50

quartzjer opened this issue May 2, 2022 · 15 comments

Comments

@quartzjer
Copy link
Collaborator

H/T @OR13 on looping me into a thread about the difficulty (complete lack-of) of supporting multiple signatures in JWTs, this is definitely a use case we should try to directly support for JWPs.

My initial take would be to extend the use of ~ to support compound issuer headers and proofs:
issuer_header_alice~issuer_header_bob.payload_1~payload_2~payload_3.issuer_proof_alice~issuer_proof_bob
and the presentation
issuer_header_alice~issuer_header_bob.payload_1~~payload_3.presentation_proof_alice~presentation_proof_bob

The multiple issuer headers/proofs wouldn't have any intrinsic linking/relationship (unless they encoded such internally in their headers), so the presenter would be free to include/exclude whatever ones they choose to. The verifier would be required to verify all of them (that are included).

@OR13
Copy link
Contributor

OR13 commented May 3, 2022

There are basically 3 problems to be solved.

  1. how are the issuers committing to multisig (header semantics)
  2. how are issuers able to attach signatures (adding or appending signatures)
  3. what process does an honest verifier have to follow ensure issuer multisig is achieved.

In order for a verifier to believe multisig, they need N valid signatures over the same data, we do't want an issuer to be "removable" which means that "all the headers" need to be signed the same way... if the issuer intends all to be required.

There are also schemes where signatures can be added to together, and ones where that is not possible.

For example, lets assume the following headers:

{
  "kid": "did:example:bob#key-0",
  "alg": "ES256"
}
{
  "kid": "did:example:alice#key-0",
  "alg": "ES384"
}

Assuming that order can be relied on, a verifier would pop the first header, and signature, verify the payloads, and then pop every other header and signature and verify that the payloads match the first.

However, in a scheme where signatures can be added (like Schnorr on Bitcoin, some storage could be saved:

{
  "kid": "did:example:bob#key-0 + did:example:alice#key-0",
  "alg": "SS256K",
}

See example: https://medium.com/coinmonks/on-bitcoins-schnorr-signature-algorithm-and-taproot-script-and-witness-sizes-fe4d1e6591a7

In this scheme, either a single "multisig public key" would be present, or a verifier could compute it from the header.

@quartzjer
Copy link
Collaborator Author

A Schnorr-based scheme would need its own JPA with semantics specific and optimized to it, I don't think this generic multi-issuer syntax needs to solve for specific schemes. I'd like an approach here that is strictly one level above a JPA such that any defined algorithm used by an issuer can be included in a multi-issued JWP.

we do't want an issuer to be "removable" which means that "all the headers" need to be signed the same way

I may not be understanding what you're saying here? As a generic syntax for including multiple issuer header-proof pairs (across the same payloads), I would fully expect the holder to be in control of which pairs to use/disclose.

If one of the issuers has specific requirements about which other issuers MUST be included, they can encode that in their header either as a statement "valid only if kid-X is present" or as a witness "here's the hash of kid-X's signature" etc.

These would all be application-specific logic. The JWP layer would simply validate that all of the included proofs are correct for their given headers and the disclosed payloads. If there's specific rules about which keys must be used or how many proofs must be present, that is part of the application's specific validation logic (the same as custom verifier logic around which claims must be disclosed, etc).

@OR13
Copy link
Contributor

OR13 commented May 3, 2022

So there are basically 3 scenarios which we discussed:

  1. multi-suite multi-sig (EdDSA, ES256K, ES384) (with out without an upfront commitment to issuers)
  2. single suite multiple headers (ES256K x3) (with out without an upfront commitment to issuers)
  3. single suite single header (SS256K) (is an upfront commitment to an issuer, that is implied by public keys)

@quartzjer
Copy link
Collaborator Author

It's possible to also have:

  1. multi-suite multi-sig with a single/shared issuer header (that lists all the issuers)

@quartzjer
Copy link
Collaborator Author

On the last call @tplooker brought up handling of the presentation header when there are multiple signatures from different suites.

My suggestion is that there is only a single presentation header that every included proof must provide integrity protection for (by the holder). If there are JPA-specific fields in that header they must all be included in the same single presentation header (and must be using registered non-conflicting header parameter names already anyway).

@quartzjer
Copy link
Collaborator Author

For the different categories of multisig (listed above): could we used the word "conjoined" to describe when the issuers are aware of and witnessing each other's issuance (in a verifiable way), and "disjoined" to describe when they are unaware and the holder is independently combining different issuer header/proof pairs?

Happy to use better or any existing language to differentiate the two types.

For Schnorr-based multisig I'd like to call them "aggregated", and still believe they are best implemented as a JPA since the cryptographic layer performs the aggregation/verification and the application isn't processing multiple issuer header/signature pairs.

@tplooker
Copy link

My initial take would be to extend the use of ~ to support compound issuer headers and proofs

I think one thing to highlight here is that at the JWP layer there are two serialisations to consider how this would be represented JSON and compact and the constraint referred to around how JWT cannot express multiple signatures is actually due to the fact that a valid JWT can only be expressed in compact JWS form.

Suffice to say I think there are a few things to un-pack here

  1. Do we want to support expressing multiple signatures in JWP (i think the answer is yes and at a minimum supporting this in the JSON serialisation would not be a great lift IMO)
  2. Do we want to support multiple signatures in compact JWP form such as how @quartzjer has made a proposal
  3. Will JPT be limited like JWT to just compact serialisation (apologies if that decision has already been taken and I missed it)

My suggestion is that there is only a single presentation header that every included proof must provide integrity protection for (by the holder). If there are JPA-specific fields in that header they must all be included in the same single presentation header (and must be using registered non-conflicting header parameter names already anyway).

I agree with this

For the different categories of multisig (listed above): could we used the word "conjoined" to describe when the issuers are aware of and witnessing each other's issuance (in a verifiable way), and "disjoined" to describe when they are unaware and the holder is independently combining different issuer header/proof pairs?

Un sure about the exact language at this stage but agree its an important distinction to make, not to make it even more complex but some multisig protocols might mean all signers aren't entirely mutually aware of one and other e.g the last signer in a chain might know all other signers but not the first signer depending on the protocol.

@quartzjer
Copy link
Collaborator Author

After mulling on this a LOT, I'm currently thinking that support for multiple issuers/proofs/etc is always most properly done by adding a JPA specifically to address the needs and underlying cryptographic relationships.

There's a lot of subtlety in what an application is expecting when using any type of multisig, and providing a single/simple high level encoding for just one of them isn't likely to even be an 80% solution. It may even be actively harmful if used in situations where it is not exactly what is needed.

I'm proposing to close this for now, and we can address with better requirements in future JPA development

@OR13
Copy link
Contributor

OR13 commented Jun 13, 2022

Is there any example regarding your proposal to define this in JPA? AFAIK, there are no concrete schemes that support any form of multisig in either JPA, JWP, or JWS as of this date.

@quartzjer
Copy link
Collaborator Author

I believe the flexibility will be there to do this within an algorithm definition. For example, use an alg="BBS-MULTI" that is just an extension of the BBS alg that supports multiple signatures and has specific semantics around how they are validated.

If we adopt #59 then the algorithm can use the ~ to assist with this.

@dwaite
Copy link
Collaborator

dwaite commented Feb 16, 2024

Is there interest in resurrecting this topic?

@selfissued
Copy link
Collaborator

I'm skeptical of adding multiple signatures/proofs over the same payloads. It seems like a lot of complexity to add to support an infrequent scenario. That said, I'd be willing to be convinced if there are compelling use cases needing this functionality to support.

Maybe we should discuss this possibility at IETF 119 in Brisbane.

@selfissued
Copy link
Collaborator

selfissued commented Feb 20, 2024

@dwaite and I propose to close this unless concrete use cases necessitating multiple signatures is endorsed by the working group.

@selfissued
Copy link
Collaborator

Note that this somewhat related to #100, since like in JWS, it's much more straightforward to represent multiple signatures/proofs when the representation is a JSON Serialization that can contain arrays, versus a Compact Serialization that can't without utilizing unpleasant encoding tricks. If we want multiple signatures/proofs, we probably only want that to be possible in a JSON Serialization.

@selfissued
Copy link
Collaborator

Closing, since no use case was produced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants