<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [PROPOSAL] request nonce and name</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Josh and I chatted a good deal about this and don't believe a request nonce is actually needed. The main motivation for a request nonce is allowing a RP to retain state within the transaction. <BR>
<BR>
A stateful RP however already has the means to store the needed data for the response, which really isn't more than the association handle to validate the returned signature. All other "state" decisions by an RP are made from the data returned in the response from the IdP.<BR>
<BR>
A stateless RP is then unable to validate a nonce it generated since it wouldn't have been able to retain information about its own nonce.<BR>
<BR>
We thought about having the RP generate a nonce in the request for the IdP to verify it hasn't received the request previously, though do not see security implications with a request being replayed. As the protocol depends on browser redirections, there is not unique information within the request which should not be replayed. This is seen today if a RP redirects you to your IdP, you go to login, but refresh the page instead which works flawlessly. Adding a request nonce would break this with no anticipated benefit.<BR>
<BR>
We thus believe that any state tracking needed by a stateless RP must be maintained as GET parameters within the return_to argument. In the case of a stateful RP, it can either do the same thing, or store state via other means such as using a session id within a cookie to reference database data.<BR>
<BR>
--David<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: specs-bounces@openid.net on behalf of Dick Hardt<BR>
Sent: Sat 9/30/2006 4:57 PM<BR>
To: specs@openid.net<BR>
Subject: [PROPOSAL] request nonce and name<BR>
<BR>
Motivating Use Case<BR>
----------------------------<BR>
It is useful for an RP to know that a response to a request has <BR>
already been processed and is not stale.<BR>
A standard way to do this that can be incorporated into the Libraries <BR>
would simplify things for the RP implementor<BR>
<BR>
<BR>
Proposed Implementation<BR>
-----------------------------------<BR>
1) Allow the RP to OPTIONALLY include a nonce in the request. The <BR>
nonce would be of the same format as the nonce in the response from <BR>
the IdP. The IdP will include the nonce from the RP in its response.<BR>
<BR>
2) rename openid.nonce to openid.response_id and name the request <BR>
nonce openid.request_id<BR>
<BR>
Alternate: call them openid.response_stamp and openid.request_stamp<BR>
<BR>
naming comments:<BR>
+ openid.nonce is not in use at this time, so easy to rename<BR>
+ id or stamp may make more sense to the average developer (mainly <BR>
crypto and security people know what a nonce is, I have to explain to <BR>
most developers)<BR>
<BR>
<BR>
_______________________________________________<BR>
specs mailing list<BR>
specs@openid.net<BR>
<A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>