Proposed Specification for New Consumer-Server Commnunications

[Paul Crowley]

Nathan D. Bowen wrote:
>    Parameter: openid.mode
>    Value: 'associate'

"associate" may well be a better name here.

>    Parameter: openid.id_token_format
>    Value: 'HMAC-SHA1'

I still prefer auth_type here.  Future authentication protocols 
supported by OpenID may not rest on the idea of an id_token at all in 
the way we currently think of it.  But since several other people don't 
seem to like it, perhaps "protocol", since part of what they're doing is 
negotiating what protocol they will use across the UA?

I notice that HMAC-SHA1 has gone ALL CAPS.  That has something to be 
said for it.

> A Diffie-Hellman key 
> exchange protects this secret in transit. The consumer provides the 
> shared Diffie-Hellman parameters along with its own Diffie-Hellman 
> public integer.

Use of DH is optional.  That's what the parameter openid.enc is for.

> name: value

I slightly prefer

name:value

(no space) for easy parsing.

>    Parameter: openid.association_handle
>    Value: handle
>       Parameter: openid.association_issuetime
>    Value: UTC date and time of issue
>       Parameter: openid.association_expires
>    Value: UTC date and time this association will expire
>       Parameter: openid.association_replacetime
>    Value: UTC date and time on which the server
>        recommends initiating a new association

You forgot server_time, which enables the consumer to interpret all 
these times.  Also, these seem quite long; Brad was expressing a 
preference for shorter names.

I do like your use of "association" terminology though.  I'm most 
familiar with that terminology from IPSec.

> * For HMAC-SHA1:

DH might well end up being used for other protocols than HMAC-SHA1 - we 
shouldn't tie it down.

But we probably should make it explicit that we're using SHA1 as part of 
our DH protocol - I've just changed the name for it on the Wiki from 
"dh" to "dh-sha1".  Or "DH-SHA1" to stick with the ALL-CAPS convention 
if that's preferred.

> The Consumer needs to know what shared secret will be used for identity 
> tokens created under this association.
> 
>    Parameter: openid.encrypted_hmac_secret
>    Value: base64(SHA1(BTWOC(DH_secret_integer)) XOR hmac_secret)

No need to include the word "hmac" in here.

>    2) Use a "get_secret" method that can calculate secrets from handles, 
> e.g., LiveJournal's LJ::get_secret, which allows a secret to be 
> retrieved by a handle without requiring all known secrets to be 
> explicitly stored.

We need to say quite a lot more about this.  The only condition is that 
the map between valid handles and secrets appear to be random to an 
attacker who does not know the server's secrets.  But there are various 
ways to achieve this.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/