Field separators

[Paul Crowley]

Brad Fitzpatrick wrote:
> \n as seperator is fine too.  We'll just have to be careful to define it
> either as a seperator or as a field ending, to avoid the ambiguity of
> whether there's a newline at the end.

Actually I've been having second thoughts about this one!

In email I mentioned that we'll probably never need the protocol version 
number, because all our formats are so flexible.  But we've introduced 
an inflexibility just where our formats are hardest to change.  If we 
ever want to add a field to what we sign, it will be very hard: the 
client must tell the server whether it can accept the new field, and the 
server must say if it is present.  If there is more than one new field, 
an attacker could substitute one from the other by mis-reporting what 
fields the server asserted are present, unless we add more complication 
to handle that.

Here's one possible fix: we use x-www-form-urlencoding to encode the 
payload, and send it as a single parameter, with another parameter for 
the signature.  Then we can check the signature before we begin to parse it.

token_contents contains the following as an x-www-form-urlencoding form

     * openid.mode = 'assert_identity'
     * openid.assert_identity = OpenID URL
     * openid.return_url = return URL
     * openid.valid_from = UTC date
     * openid.valid_to = UTC date

idserver redirect -> UA -> consumer:

     * GET return URL
     * openid.mode = 'id_res'
     * openid.token = token_contents
     * openid.auth_type = 'hmac-sha-256'
     * openid.secret_handle = HMAC secret handle
     * openid.sig = HMAC( secret(secret_handle)), token_contents )

The contents end up being doubly-URL-encoded, and the return URL is sent 
twice, and you have to be able to decode x-www-form-urlencoding on 
something that isn't directly a GET request, but it means that you've 
got a simple assertion of "here's what was authenticated, and here's the 
authentication" - you don't have to piece together what was 
authenticated yourself.  And it means if we want to add more to that 
assertion, we can.

There are things not to like about this proposal, so if anyone can come 
up with a simpler/easier way that we can vary the fields in what is 
authenticated without breaking everything I'm keen to know...
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/