Field separators

[Brad Fitzpatrick]

On Mon, 6 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > I'd have to spend some time reading before I'd understand it.  I'll hope
> > you side towards the simplest thing necessary for our requirements and
> > then maybe I won't have to do any more reading.  :-)  Let me know if I do,
> > though.
>
> It's pretty simple.  Just choose x and y to be less than q, rather than
> less than p, and everything else stays the same.

okay.

> We could do without but it's warm fuzzies for the cryptographer at
> little cost here...

your call, security dictator.

> > So maybe change:
> >    # openid.auth_type = 'hmac-sha1'
> >
> > Into:
> >    # openid.auth_type = 'hmac'
> >    # openid.hash_pref = 'sha256,tiger,sha1'
>
> Or just
>       openid.auth_pref = 'hmac-sha1,hmac-tiger,ecdsa-sha256'

That works.

> in the call to get_authkey.  But I think this is making things too
> complex.  Consumers should just call get_authkey for their favourite
> auth type, and try again with their next favourite if it's not supported.

Fail and try again works fine for consumer to idserver, but once UA
redirects are involved you run into both latency and max-redirects limits
in the browser.  How about "auth_pref" is optional and defaults to
"hmac-sha1", which all servers must support.  If you send an auth_pref, a
server can choose to recognize it and use it.  If your auth_pref line is
missing "hmac-sha1", it's still implied as the least preferred option.  So
you can say:

   openid.auth_pref = "hmac-tiger"

And get back "hmac-sha1".

It's capabilities, which is how I want to do versioning anyway.

> I've updated the spec to include these latest changes, and added dumb
> consumer mode.

Cool.

> How will you move to the new protocol? Should the code that implements
> the new protocol attempt to be backward compatible with existing
> servers/consumers?  It's certainly possible to write backwards
> compatible code, but I'd be inclined to set a cutoff date after which LJ
> won't support the old protocol and support will be removed from the CPAN
> modules, to make sure people don't assume it will be around forever.

No love for backwards compatibility.

LifeWiki.net is the most useful app using this so far, and Junior can
upgrade any minute.

Old protocol mode will be immediately removed from the CPAN code when new
code is added.  (have we actually decided on this new protocol?  is DSA
out?  I'm feeling like it is?)

- Brad