Re: Dealing with multiple signatures

On 2013-09-01 18:44, Manu Sporny wrote:
> On 08/31/2013 04:59 AM, Anders Rundgren wrote:
>> Although an array of signatures a la JWS is doable it severely
>> complicates canonicalization. I believe the following approach is
>> more reasonable:
>>
>> { { "@context": "http://example.com/test-multiple-signatures", "Now":
>> "2013-08-30T07:56:08+02:00", "ID": "lADU_sO067Wlgoo52-9L", "STRINGS":
>> ["One","Two","Three"], "Signature": { } }, "Signature": { } }
>>
>> That is, there wouldn't be multiple signatures signing _exactly_ the
>> same content.
> 
> Agreed. The work we've done on the PaySwarm specs has led us to the same
> conclusion.
> 
>> IMO signatures _wrapping_ each other does the same thing (or better)
>> except in theoretic use-cases like multiple human attesters.  The
>> latter have considerably better solutions using a server-based system
>> collecting individual attestant's response _separately_.
> 
> +1
> 
> However, if there is a use case for an array of signatures, we've
> thought through the details of that and have a solution that would work.
> The benefits of that approach are that you can know the order in which
> endorsements on the original document occurred. For example, if the
> signatures look like this:
> 
> "signature": [A, B, C]
> 
> Then you know that A signed the document, then B signed the document,
> then C signed the document. To verify the signatures, you remove C from
> the signature list, and verify the document like so:
> 
> Verify C's signature: "signature": [A, B]
> Verify B's signature: "signature": [A]
> Verify A's signature: Just use the data w/o a signature property
> 
> This is fairly trivial to implement, but we just left it out for now as
> there don't seem to be any use cases where you'd want to place all the
> signatures together in that way.

I have one question: What is the scope of an [] signature?  Is it
the parent object?


> 
> I've been trying to track down the JWS use case that required multiple
> signatures on the same document. I don't understand why they didn't just
> go with the embedded signatures route.

They don't have any use-case but since multiple signatures would be
extremely clumsy using JWS they were *forced* coming up with this
scheme/workaround.

> 
>> The scheme above also copes with countersignatures like when you have
>> filled a shopping- basket with stuff and perform a B2B checkout.  The
>> merchant could sign the shopping- basket with its "Merchant key"
>> which would transform it into a non-forgable "Quote". The purchaser
>> could if accepting the quote just put the shopping-basket object in
>> an empty PO object and counter-sign it with its "Buyer-key".
> 
> Yep. In fact, this is exactly how one of the buy flows with PaySwarm
> works, which is explained in more detail here:
> 
> https://hacks.mozilla.org/2013/04/payswarm-part-2/
> 
> https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-purchasing-part-3-of-3/

Cool!

Anders
> 
> -- manu
>

Received on Sunday, 1 September 2013 19:33:42 UTC