-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
There are basically 3 problems to be solved.
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:
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:
In this scheme, either a single "multisig public key" would be present, or a verifier could compute it from the header. |
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.
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). |
So there are basically 3 scenarios which we discussed:
|
It's possible to also have:
|
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). |
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. |
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
I agree with this
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. |
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 |
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. |
I believe the flexibility will be there to do this within an algorithm definition. For example, use an If we adopt #59 then the algorithm can use the |
Is there interest in resurrecting this topic? |
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. |
@dwaite and I propose to close this unless concrete use cases necessitating multiple signatures is endorsed by the working group. |
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. |
Closing, since no use case was produced. |
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).
The text was updated successfully, but these errors were encountered: