No subject

- RP is sure that the OP's reply is fresh because it includes
  the nonce it sent;

- RP doesn't have to worry anymore about having clock synchronization
   issues with the OP... or having to content with an OP changing
   its clock (backward or forward).

- The RP only has to memorize the nonce value until it gets the
  verified reply from the OP. Compare this with the current 
  d12 proposal, where the RP has to store the OP nonce for an 
  indefinite amount of time. This may become an issue when an RP
  handles thousands of openid transactions every hour.

- We don't need the OP nonce anymore.

But this is not yet enough to safely use RP Nonces. They should
also be binded with a signature to the request to avoid having
someone just do a cut and and paste of a valid Nonce to a replayed
message sent to the OP.

2. RP->UA
   openid.mode=checkid_setup
   openid.assoc_handle=1234ABC
   openid_return_to=http://myrp.example.com
   ...
   openid_rpnonce=1234ABCD
   openid_signed=assoc,return_to,rpnonce,...
   openid_rpsig=12345ABC

I've not given much thought to what fields would need to be signed.
As this signature and what it covers is basically part of the 
counter-measure against replay attacks, we can save some bytes
and just say that it's implementation-dependent and out-of scope. 
Indeed, the OP doesn't care about what fields were signed by the 
RP; only the RP needs to know it. It is only important that the answer
from the OP includes the same fields that were signed.

We could even have something in the end like this:

2. RP->UA
   openid.mode=checkid_setup
   openid.assoc_handle=1234ABC
   openid_return_to=http://myrp.example.com
   ...
   openid_rpnonce=2007-11-23T18:42:01Z:UNIQUE:SIGNATURE

Although this RP nonce proposal requires doing some slight 
extra processing on the RP server, I think that in the long term it 
offers an equivalent protection against replays and scales better
than the actual proposal 2.0/d12 nonce proposal. There's no need
to store state indefinitely on the RP or need to synchronize 
clocks.

On the other hand, a drawback is that the nonces have to be stored
on the RP side until the OP replies (or times out). This could be 
used as a DOS attack by making multiple requests on the RP.

A last word concerning the use of multiple mirrored RP servers.
Suppose we have the following RP pool,
RP1.example.org, RP2.example.org, ... selected thru the generic
DNS name RP.example.org. In the RP nonce proposal, the RP
has to store the nonce value. If we include the hostname (or IP@)
of the RP server in the openid_return_to field, we make sure
that the UA will always come back to the "correct" RP server:

2. RP->UA
   openid.mode=checkid_setup
   openid.assoc_handle=1234ABC
   openid_return_to=http://RP1.example.com
   ...
   openid_rpnonce=2007-11-23T18:42:01Z:UNIQUE:SIGNATURE

As before, I don't take into account how mirrored RPs could share 
the OP association. In general, I  think it would be interesting 
to see more notes on scalability and OpenID, e.g. how to setup 
multiple mirrored OpenID consumers, performance stats, and have a 
forum to discuss this with other developers.

Many thanks for your time. I'm looking forward to go deeper in my
exploration of OpenID consumers.

-jose