shared secret alternative to DSA

[Paul Crowley]

Brad Fitzpatrick wrote:
> I'd say if it's something every consumer must have, let's make it
> explicit.  If it's optional or can be handled in multiple ways, then let
> it be part of the return_to.

Fair enough - makes life easier all round really.

> Encrypting sounds like we just lost the ease of implementation we were
> seeking if ditching DSA.

> I'm for putting that "check mode" in the protocol spec as a MUST for
> servers, to support dumb consumers.

OK - that's a much better solution all around.

Here's how you use "check mode": when you ask for the auth token, don't 
specify what key you want it authenticated with.  The server will tell 
you what key it used in the reply.  Of course, you won't know that key, 
but that's fine; you specify it as an argument in your checking call, 
and the server (who does know) will use it to check.

** Checking identity

   consumer redirect -> UA -> idserver:

       openid.mode = checkid_immediate
       openid.is_identity = http://bradfitz.com/
       openid.return_to = http://return.to.com
       openid.authentication_type = hmac-sha1

   idserver redirect -> UA -> consumer:

       openid.mode = id_res
       openid.assert_identity = http://bradfitz.com/
       openid.authentication_type = hmac-sha1
       secret_handle = 1117855428-random_string_19283746
       timestamp = <UTC time>
       expiry = <expiry UTC time>
       hmac_sha1 = HMAC( secret_value(secret_handle),  token_contents )

   consumer -> idserver

       openid.mode = check_authentication
       openid.authentication_type = hmac-sha1
       openid.is_identity = http://bradfitz.com/
       openid.return_to = http://return.to.com
       timestamp = <UTC time>
       expiry = <expiry UTC time>
       secret_handle = 1117855428-random_string_19283746
       hmac_sha1 = <value as above>

   idserver -> consumer

       auth_ok = "true" or "false"
       lifetime = <seconds>

This is close to the easiest and best possible protocol for dumb 
consumers anyway; it's a happy circumstance that it's so close to the 
"real" protocol.

Note that it also means that the dumb consumers don't have to worry 
about clocks; everything is done by the server clock, and the server 
will answer "false" if the secret or the token has expired, or supply a 
relative lifetime in seconds if it should live.  The consumer must start 
counting these seconds from when it initiates the check_authentication 
request, not from when it receives the reply.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/