Re: [jose] DISCUSS: Nonce/Timestamp parameter

[John Bradley <[e-mail]>]

In OAuth 2 state gets overloaded with a bunch of things from preventing XSRF to providing a handle to look up who the the authorization request was sent to.

In Connect we added a nonce sent by client that is returned inside the signed id_token (JWT) to allow the client to detect replay, and optionally reference a specific browser session that presents the id_token.

The nonce I suggested for JOSE is not ether of those.  

I used nonce in the sense that it is used with stream cyphers when the same key is used over multiple messages.

JOSE will be used for more than OAuth and JWT.   There are cases where adding entropy to the header will be a security benefit.  I would like to have a standard claim for doing that.
If people want to call it something else that is fine, but it is a nonce by definition.
If used it should be a random or pseudo random value that is time variant with sufficient granularity to ensure a nonce is used only once.

John B.

On 2012-08-28, at 10:32 AM, Justin Richer <[e-mail]> wrote:

> On 08/25/2012 03:37 AM, Axel Nennker wrote:
>> To clarify: What is the base specification that Jim mentioned? 
>> Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?
>> 
>> Would somebody please present a use-case for either nonce or timestamp?
>> If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?
>> 
> 
> Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.
> 
>  -- Justin
> 
>> I guess I am missing some information that those in the room who voted "yes" had?
>> 
>> Axel
>> 
>> 2012/8/25 Mike Jones <[e-mail]>
>> I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals).  A nonce tends to be an opaque value that must be preserved across the communication.  Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.
>> 
>> For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.
>> 
>> We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value.  This seems much harder to define and possibly to use than a nonce.
>> 
>> Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient?  That would be my personal recommendation.
>> 
>>                                 Best wishes,
>>                                 -- Mike
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
>> Sent: Friday, August 17, 2012 12:05 AM
>> To: [e-mail]
>> Subject: [jose] POLL: Nonce/Timestamp parameter
>> 
>> <CHAIR>
>> 
>> If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.
>> 
>> Do we need to define a nonce/timestamp parameter in the base specification?
>> 
>> 
>> 
>> Room vote:  6 yes, 0 no, 1 discuss
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose