Would it be too confusing to ask for a sat "signed at" field for the header? In my application this makes more sense (with the multiple signatures serialization specification jws-js) than a payload time stamp.
Daniel Holth On Oct 4, 2012, at 8:15 PM, Mike Jones <[email protected]> wrote: > As editor, I’m going to make the observation this is the one poll question > where the results are not clear enough for it to be obvious what I should do. > There were many people who made comments about the question being unclear > and the intended use and meaning of the potential field or fields unclear. > > Unless you feel differently, Karen and Jim, I believe that the best course at > this point is for me to add nothing to the specs as a result of this poll > question, but for the working group to try to make decisions on much less > ambiguous proposals (should any be made) than the one in the poll question. > > -- Mike > > From: [email protected] [mailto:[email protected]] On Behalf Of Jim > Schaad > Sent: Tuesday, August 28, 2012 8:38 PM > To: 'Dick Hardt'; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > > The question from my point of view is that common fields from many structures > should potentially be supported in the base specification so that they can be > common rather than having each structure define them separately. This is > only an issue if one wishes them to be placed in the header structure and not > in the data structure. > > If one is looking at signing an unstructured data object – such as a file – > then it becomes difficult to have the fields such as a time that it was > signed be part of the file itself, especially if one is applying multiple > signatures at different times. This is not an issue for the token > specification but could be for other uses of the signature or encryption > specifications. > > I would agree that “iat” is a timestamp for the purposes of this > conversation. If one wanted a formalized timestamp from a third party > authority then a totally different way of going about it would be required. > I chose the term nonce or timestamp because both had been discussed in the > past without any specific resolution about what is needed. > > Jim > > > From: Dick Hardt [mailto:[email protected]] > Sent: Monday, August 27, 2012 2:55 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > > I was considering "iat" to be the timestamp. I was not thinking there would > be an additional timestamp. > > On Aug 27, 2012, at 2:13 PM, <[email protected]> wrote: > > > We have exp > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.1 > and iat > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.3 > in JWT. Why do we need a timestamp? > > Replay attacks of the same jwt can be mitigated through the jti claim > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.7 > > What do timestamp and nonce add to these? > > Axel > > > > From: Dick Hardt [mailto:[email protected]] > Sent: Monday, August 27, 2012 10:23 PM > To: Brian Eaton > Cc: Nennker, Axel; Jim Schaad; [email protected] > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > > > On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: > > > > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <[email protected]> wrote: > I have an application for JWT that is not OAuth2. > > Should nonce and timestamp logic go in the application level protocol? > > I prefer to NOT have the application level deal with token validity. > > > > > Having said that, nonce's are difficult to implement at scale and I have > heard of many sites that don't implement them fully. > > Nonce alone can't be implemented efficiently. You have to have time stamps > as well, otherwise you are stuck storing ever nonce you've ever seen, forever. > > Even nonce + time stamp is challenging in distributed systems. It adds a lot > of complexity. That complexity is sometimes merited, but not always. > > Thanks for confirming my statement. > > I have stopped using nonce and only use time stamps lately and have made the > system relatively stateless so that a second submission of the token is ok. > That may not work for everyone, but I have found that architecture to be > easier to implement and scale. > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
