No subject

much more sense if the Relying Party generated the nonce and have
the OP returns this nonce in its message. More precisely,
this means including the RP generated nonce in the request parameters
specified in Section 9.1. The RP needs to memorize it too, until
the OP replies. The OP needs to include this nonce 
in the Positive Assertion reply message specified in Section 10.1; 
the nonce also has to be part of the signed fields. Once the RP 
verifies the nonce, it can discard it.

Roughly, the use of the nonce starts when the RP sends the
30x redirect to the UA:

1. RP generates nonce (rpnonce) and memorizes it.

2. RP->UA
   openid.mode=checkid_setup 
   openid.assoc_handle=1234ABC
   openid_return_to=http://myrp.example.com
   ...
   openid_rpnonce=1234ABCD

3. UA->OP
   openid.mode=checkid_setup  
   openid.assoc_handle=1234ABC
   openid_return_to=http://myrp.example.com
   ...
   openid_rpnonce=1234ABCD

....

4. OP->UA
   openid.mode=id_res
   openid_assoc_handle=1234ABC
   openid_rpnonce=1234ABCD
   openid_signed=..., rpnonce, ....
   opendid_signed

5. UA->RP
   openid.mode=id_res
   openid_assoc_handle=1234ABC
   openid_rpnonce=1234ABCD
   openid_signed=..., rpnonce, ....
   opendid_signed

6. RP checks message for replay by comparing the rpnonce nonce
   against the copy it stored in memory; RP can then delete it
   from memory.