Proposed Specification for New Consumer-Server Commnunications
paul at ciphergoth.org
Wed Jun 8 15:46:04 PDT 2005
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
(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
More information about the yadis