parameters and response format

[Mario Salzer]

I'd like to revive the former discussion on the protocol/exchange
format, and while I'm at it express my grieve over some parameter
and data representations within, because the current proposal looks
a bit inconsistent IMO.


First I still don't understand why responses should be packaged
into "name:value\n" pairs. Implementations are eased pretty little
by this - the only difference to -www-form-urlencoded is the use
of ":" and "\n" instead of just "=" and "&" as delimiters. Granted,
there would also be URL-decoding required consumer-side if this was
the resonse format (- unless non-alphanumeric chars were forbidden
in openid.handle as well).

But then, it is unlikely that there is a plattform, which supports
SHA1 hashing but no way to decipher URL-escaped strings. And the
"name:value\n" format is structurally not different enough to
significantly simplify the protocol, yet introduces inconsistency
with standard GET/POST requests.

If the :\n format is kept, then I'd like to see at least a saner
MIME type used. "text/plain" is not only inappropriate for non-
human readable data exchanges, but could also be broken up by
proxies (to sanitize line lengths). A more descriptive type like
"text/x-openid", "text/prs.fitzpatrick.openid" or "text/directory"
would furthermore allow interested parties better protocol checking
and signaling with HTTP error codes.


Second point: date/time formats. I'm also not sure why the ISO/w3c-
format is used instead of timestamps. I don't see the need to have
the openid protocol requests and responses human-readable, if it
is inter-application logic. The data-format provides little benefit
over numeric timestamps, especially since the w3c format is trimmed
at the seconds and only the GMT timezone allowed.

I'm not aware of a single programming language or environment, which
uses this as the native format (compare to timestamps) and their
textual format could only raise the desire to use extended (but for
good reasons here forbidden) representations.


I also don't really like the "btwoc()" encoding. Base64 is nice for
transferring binary content and the only viable solution for the
final signature, but for passing the DH keys this looks unneeded,
because the "keys" are just numbers and could be easily left in
their decimals representation.

Sure, the octets-transformation could very likely be the native
representation of large integers on many plattforms and languages
and it made back conversion faster and less insecure than a string
of decimals, but btwoc() here seems to be used as "compression"
feature. I have no calc at hand, but a 1024bit key is not more than
300 decimals - and so the need for btwoc() not all too urgent. If
the responses and requests were too lengthy, then the specification
should mandate HTTP content-coding instead.

That btwoc() is already used for the final hash and key encryption,
shouldn't influence its reuse for parameter passing. But OTH my
personal dislike for its use here is probably just the multipled
encoding (decimal-string to byte-octets to b64-string), and so
this point is probably less important nit-picking.