In reading JOSE specs, I can't help asking a question that I asked some
time ago in the Magic Signatures discussion:
Why does a signature contain three parts instead of four? Please let me
know if what I wish to do, as described below, can be done with JOSE today.
Perhaps I've missed something...
The reason I ask is that I'm interested in the set of use cases that
involve multiple people signing a single payload. In order to store the
multiple signatures and in order to create messages that represent the
payload packaged with a set of multiple signatures, it would be convenient
if the JWS Header and Payload encodings were the same for all signatures
and thus did not contain any data specific to an individual signature.
Given the current specs, the payload bits might, in fact, be the same for
multiple JOSE signed messages, but since the JWS header contains
information specific to the signature (i.e. optional jwk value, etc.) in
addition to information about the payload (like type, etc.) it might not be
possible for two signers to share the same JWS Header and Payload bits...
If JOSE signatures supported a four part representation, the JWS header
would only 1) Identify the header as a JWS header and 2) contain data
concerning the payload's type and encoding. Signatures would then have two
parts: 1) A signature header, and 2) the signature itself. The signature
header would be Base64URLencoded, just like JWS Headers. Thus, a four-part
object might look like:
<JWS Header>.<Payload>.<Signature Header>.<Signature>
The advantage of such a four part system is that I could then take the
following three signed objects:
<JWS_Header>.<Payload>.<Signature Header 1>.<Signature 1>
<JWS_Header>.<Payload>.<Signature Header 2>.<Signature 2>
<JWS_Header>.<Payload>.<Signature Header 3>.<Signature 3>
and combine them into a single, smaller object that looked something like
this:
<JWS_Header>.<Payload>.<Signature Header 1>.<Signature 1>.<Signature Header
2>.<Signature 2>.<Signature Header 3>.<Signature 3>
Doing so would potentially save a great deal of storage and/or
communication resource as well as make it easier to communicate the
presence of multiple signatures.
Note: If this business of using multiple signatures on a single
header/payload pair was supported, I think I might also ask for some syntax
to make handling sets of signatures easier. Something like the following
might be reasonable:
<JWS_Header>.<Payload>.[<Signature Header 1>.<Signature 1>,<Signature
Header 2>.<Signature 2>]
Having distinct signature headers would also allow me to do another thing I
need for my use case, which is to record not just the signature, but
information concerning why the signature was created. Thus, I could
distinguish between an assertion of "authorship" over the payload, a claim
of acceptance of whatever was asserted in the payload (i.e. "I agree." or
"I accept."), the inverse of that ("I disagree.") or whatever... Given the
current three part system, any such signer-specific statements would have
to be included in the payload body and that would make it impossible to
have multiple signatures for the same payload unless all signers were
making precisely the same statement with their signatures.
Is there a strong reason why signature specific data is included in the JWS
Header or is that just a case of path-dependence? Is there some way to
address my concerns for the use cases hinted at above with JOSE signatures
as currently defined?
bob wyman
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
