So the obvious question (to me) is whether or not the claim should move
to the JOSE layer.
-- Justin
On 08/28/2012 04:46 PM, Brian Campbell wrote:
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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: [email protected] <mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
--Breno
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
