Isn't the pool question really about JOSE (this is the JOSE list after all) and if a nonce or timestamp type thing should be defined in JWE/JWS as a Reserved Header Parameter Name?
I don't think it can be said that we already have an issued time defined. "iat" (Issued At) is a claim defined in JWT. That's all together a different thing than a JOSE header and I don't see anything like it anywhere in the JOSE docs. JWT is a layer above JOSE and, while there is a lot of overlap of people, is being developed in a completely different WG. I'm, at this point, saying we need this thing but rather just trying to clarify the question. On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros <[email protected]> wrote: > I agree that this should be looked independently of oauth2. > > Nonce is a generally used concept in crypto, though sometimes protocol > designers have called for nonces with bad outcomes because the difficulty > of implementing nonce-checking was disregarded. However, difficulties to > implement nonces in general are not relevant if there is a compelling use > case that is able to leverage nonces effectively. > > As for timestamps: we already have issued time and the nonce can embed a > timestamp additionally. So I don't think we need to concern ourselves with > timestamps when considering nonces. > > > > > On Tue, Aug 28, 2012 at 8:09 AM, John Bradley <[email protected]> wrote: > >> 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 <[email protected]> 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 <[email protected]> >> >>> 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: [email protected] [mailto:[email protected]] On Behalf Of >>> Jim Schaad >>> Sent: Friday, August 17, 2012 12:05 AM >>> To: [email protected] >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> >> >> _______________________________________________ >> jose mailing [email protected]https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> > > > -- > --Breno > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
