Time of signing would be valuable in many contexts. However, there are many other attributes that can be associated with the signature that would also be valuable -- depending on the specific context. Exhaustively listing all these attributes in advance is not going to work.
So, I'd like to suggest again that the JWT format be extended to four parts rather than three. The added part would be "signature header" and would contain, in addition to those signature-specific elements now in JWS Header, arbitrary JSON content which is associated with the signature. Thus, instead of: <JWS Header>.<payload>.<signature> we would have: <payload_header>.<payload>.<signature_header>.<signature> Such a four-part structure, by isolating signature-specific data from payload-specific data also makes it very easy to support multiple signatures for the same payload (since all signatures would be applied to the same base <payload_header>.<payload> bytes.) Additionally, the ability to associate metadata with each signature allows a broad range of application requirements to be addressed. For instance, I might define a "signature purpose" attribute that allowed signers to distinguish between various intents such as "claiming authorship," "approving," "denying," "have read," etc. Other applications might want to support signatures that not only were created on a certain date but should be considered to "expire" after some time or upon some other event described in the signature header. There are all sorts of things that folk might want to do and each signer of any particular piece of payload is likely to have some different intent in mind when signing. The four-part structure is vastly more flexible than the existing three-part structure and introduces very little complexity or added bits to the protocol. Why not use it? bob wyman On Tue, Oct 9, 2012 at 2:33 PM, Jim Schaad <[email protected]> wrote: > I propose that we create a header entry that is optional and contains a > time > that the signer claims that they signed at. > > There are two different types of times that can found in signed statements. > The first is going to be a time field associated with the data. This is > the > current approach that is used for the JWT in that part of the claims about > the token itself is the time that the claims in the token are created. The > second time field is associated with the signing operation and is a claim > not about the content but about the signature. This is a signing time. > The > claims may be attested to at a different time that the signature was > created. > > > Having a signing time is not an important issue for the JWT specification; > however I believe that it will become an issue for cases where multiple > people will be signing a single document. These signatures may be either > made in parallel or serialized but as they occur at different times knowing > a claimed signing time may be of interest. > > > > Side note - I believe that the nonce question should be dropped until > somebody makes a case for it that is related to signatures and not to > protocols which is where I generally see nonces being used. (That is for > freshness checking or associating multiple documents in a single dialog.) > > Jim > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
