Problems with OpenID and TAG httpRange-14

Kevin Turner kevin at janrain.com
Wed Mar 19 02:54:20 UTC 2008


Here's the change most likely to get accepted.  Amend the specification
to say:

        A request for an OpenID Identifier SHALL NOT issue a 303
        response.

and, if you're feeling ambitious, pick one -- or two? -- of the assorted
30x redirect codes that an OP may use for particular cases, and clearly
enumerate them.

The change you are proposing is not backwards compatible -- an RP that's
decided your identifier is example.com/about would then decide it's
example.com/ as soon as it upgrades to the new version, and that
wouldn't be good for existing users.

The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a
mechanism to publish discovery information at a URL which does not have
HTML content.

The code path you are are requiring the implementations to change
(OpenID discovery and normalization) is, with the combination of
different identifier types, protocol versions, and discovery schemes,
already one of the most tangled chunks of code involved.  I acknowledge
that your proposed change, in isolation, seems simple enough, but that
code *really* doesn't need another branching condition in it.

I appreciate the spirit of your suggestion.  It's a terrible thing to
say "oh, we follow standard X, except in the cases outlined in appendix
B, which you will have to modify your X-implementation to be aware of."
But, practically speaking, the use case is not compelling enough to
overcome the cost of change.  And it's not like you have an RP
implementation that *almost* works except not quite because the
libhttp-follow-redirects-
and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case-
return-the-intermediate-url function in your web framework is returning
something incompatible with OpenID.  (Or, if it is, I really want to
hear about what HTTP client implementation you're using.)

I know that *you* think the semantics are clear, but the fact that
knowledgeable people have been haggling over it for weeks on the list
suggests that it may not be.

So, IMHO, the best way to make this problem go away is to just say that
303s are an invalid way of telling an RP where discovery information is.
RPs will continue to work the way they do now, for
backwards-compatibility purposes, and anyone publishing OpenID
identifiers in the future will be able to find a clear statement about
it in the spec.





More information about the specs mailing list