Field separators

[Paul Crowley]

Brad Fitzpatrick wrote:
> I'd say in the interest of consistency we go with x-www-form-urlencoded.
> It's not that hard to parse, and it's usually possible to coerce a web
> framework's API to do most the heavy lifting of decoding it anyway.

OK.

> * What format is p, g, and gx/gy?  Hex, decimal?

Base64 all the way.

> * What is dh.q (order)?

That's necessary if we use the Schnorr group.  Q is a largeish (160-bit) 
prime that divides p-1, and g^q = 1 mod p.  Schorr groups are no harder 
to work in and have certain security advantages over standard Z*_p 
groups because they are of prime order, though it's not clear that those 
advantages will matter here.

> * You don't have the check_auth mode for dumb consumers on there?

Haven't written it up yet is all...

> * We're really using SHA-256 instead of SHA-1?  I thought we agreed
>   the point of using a shared secret / HMAC approach over DSA is
>   that the uniquity of sha1 functions made implementation easier
>   than DSA would.  I just checked 4 or 5 hosts, and it's not available
>   on any of them (including any of LJ's).  The Perl package isn't
>   in Debian.  SHA-256 isn't in PHP.  etc, etc.

In that case should go for SHA1 for now.  It'll be easy enough to switch 
to a more secure hash function when it becomes clear what way the world 
is going to go; that's why I've made the hash function explicit in 
various places in the protocol.

> * I don't think the "assert_identity" literal in token_contents needs
>   to be there.  It'll just hinder us going forward when it's already
>   implied by openid.mode='id_res' and token_content's "assert_identity"
>   actual field.

No, I think it's essential that when you sign (or otherwise 
authenticate) something, that you start of by saying what it is that 
you're asserting.  You can go on to say what you're asserting it about, 
but I'm keen that we open with "this is a token that is for this". 
Otherwise if the protocol grows we could end up in a situation where a 
token intended for one situation becomes usable for another.

> * In the interest of URL space savings, let's cut down the verbosity
>   where obvious:
>      - encryption -> enc
>      - generate -> gen
>      - ... eh, can discuss it later.

OK.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/