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]]<mailto:[mailto:[email protected]]>
Sent: Monday, August 27, 2012 2:55 PM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[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]<mailto:[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]]<mailto:[mailto:[email protected]]>
Sent: Monday, August 27, 2012 10:23 PM
To: Brian Eaton
Cc: Nennker, Axel; Jim Schaad; [email protected]<mailto:[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]<mailto:[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
