brad at danga.com
Sun Jun 5 15:47:16 PDT 2005
On Sun, 5 Jun 2005, Paul Crowley wrote:
> OK. What format do we use for the replies from servers to consumers
> about server secrets? We should probably use the same format as that
> for the signatures. I was thinking x-www-form-urlencoded there, but as
> you say that might be hard for consumers to parse when it's part of the
> reply rather than part of the request.
You'll hear every debate. Some people will say text/line-based protocol
is easiest. Some will want x-www-form-urlencoded encoding, and some will
actually prefer XML, as it's built into their language/envifornemnt.
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.
> I'm keeping a Wiki page up to date with the latest proposed specification:
* What format is p, g, and gx/gy? Hex, decimal?
* What is dh.q (order)?
* You don't have the check_auth mode for dumb consumers on there?
* 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.
* 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"
* In the interest of URL space savings, let's cut down the verbosity
- encryption -> enc
- generate -> gen
- ... eh, can discuss it later.
Not that we're in trouble now, but for layers later, maybe. (though
I imagine the big data will be out-of-band and/or referred to by
More information about the yadis