Verifying a submitted identity

[Martin Atkins]

Those who have read the source to my OpenID Guestbook demo will probably 
have seen the hack I used to get the library to validate the signature 
during the final request when the guestbook entry is actually logged.

The API works fine for dealing with the return from the ID server, and 
my code then puts the ID URL, timestamp and signature in hidden form 
elements which get submitted along with the comment.

Of course, in this last request the form values aren't using the same 
field names as OpenID uses to return the data the first time (and they 
can't, because otherwise the code can't distinguish between the two 
requests) so the Consumer perl module can't validate it with a little 
help. The hack is to make a fake list of parameters and trick the 
consumer module into using it:

     $c->args({
         'openid.mode' => 'id_res',
         'openid.sig' => $vars->{oid_sig},
         'openid.assert_identity' => $oid_url,
         'openid.return_to' => '...',
         'openid.timestamp' => $vars->{oid_ts},
     });

Clearly this is not ideal. My first thought was for an API function 
which can just take a (id, sig, timestamp, return_to) tuple and operate 
on that as does the current verified_identity() method does on the 
matching form arguments. Brad thinks that might break the ability to add 
support for nonces, though, and suggested I raise it on the list.

After pondering this a bit, it seems to me that the nonce could just be 
kept in the valid list until the whole process is complete, also 
including it in a hidden form field for example. However, this means 
that the nonce gets thrown back and forth a few times before it's 
actually used and invalidated, which might be harmful. I'm not sure.

Any thoughts?



(Obviously, most "big" applications will be able to track people using 
session cookies and such, so this form-passing trickery is unnecessary. 
My guestbook app, though, is a good example of a simple app which can't 
do any of that fancy state-requiring stuff very easily. As a side-effect 
it's valnerable to replay, but something as trivial as a guestbook 
doesn't really warrant all of the complication and overhead of tracking 
state, in my opinion. An easy improvement would be to limit how far in 
the past the timestamp can be, as we've discussed previously.)