Problems with OpenID and TAG httpRange-14

Manger, James H James.H.Manger at team.telstra.com
Thu Mar 20 01:42:45 UTC 2008


As confusing as HTTP redirect semantics might be, I am confident that
you will not find anyone that deliberately chooses to return a 303 See Other
without explicitly wanting to keep the original URL as the "identity" and
the new URL as merely a (stable, cachable) location for the current response
(eg current OP details). I am confident this will be true for any web
content, not just OpenID.

[Aside: Browsers displaying the new URL in the address bar after a
303 See Other is not a counter-example. The new URL is the address of the
displayed response. It is NOT the address that will be reused if the
original request (eg an HTML form submission) is retried.]

The ability to serve discovery details from a location that is different
from the claimed_id is desired functionality:
1* You can achieve it using X-XRDS-Location (HTTP header or <meta> element),
but only if you deliver other content (eg HTML) at the claimed_id;
2* You can achieve it using an i-name (by the abstract nature of those ids
and the various synonyms explicitly defined for those ids);
3* You can achieve it via "directed identity" if your OP cooperates,
and with a very extra request/response pairs;
4* You CANNOT achieve it using standard HTTP (with 303 See Other).

The question is whether OpenID wants to bother supporting #4.

In adding support for XRI/XRDS/i-names OpenID 2.0 made HTTP URIs
somewhat second-class citizens by offering some functionality only
when XRI/XRDS is used, even when sensible HTTP mechanisms
were also available. Two examples are: supporting X-XRDS-Location but not
303 See Other; and indicating an OP Identifier with a special XRDS <Type>,
but not with a special openid2.identifier value.

For a true-believer in i-names, not offering an HTTP-way for some
functionality is not important (perhaps even helpful for promoting i-names).
For a true-believer in HTTP (less enthused by i-names), the lack of an
HTTP-way is a problem.

Kevin Turner said:
"Amend the specification to say:
    A request for an OpenID Identifier SHALL NOT issue a 303 response."

Thankyou Kevin, for a lateral "solution".
It is not the fix I want (proper HTTP-style support for 303 See Other),
but at least it explicitly tells people that OpenID 2 does not support
303 semantics. That should allow proper 303 support to be added later
without big backward compatibility issues.

[Aside: In practice, OpenID RP libraries would probably not be changed
to explicitly reject 303s -- particularly as your major argument is that
that sort of change makes the code too complex. Rejecting or interpreting
303s both require explicitly handling redirect codes, as opposed to setting
the "follow redirects automatically" option of the HTTP client library.]

Objections to proper support for 303s don't say the proposal is wrong.
They just imply it is not worth the effort: "code too complex", "do not have
to obey HTTP", "work arounds available", "2.0 is finished".
Not surprisingly, these judgements are not convincing to some
HTTP true-believers.


Perhaps I will add a note to the OpenID 2.0 errata page stating
HTTP 303 See Other semantics are not currently supported so they should
be avoided when hosting OpenIDs.


More information about the specs mailing list