Problems with OpenID and TAG httpRange-14

[Noah Slater]

On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
> A request for an OpenID Identifier SHALL NOT issue a 303 response.

This is even worse and also backwards incompatible. All the OpenIDs that
currently use 303 redirects, including mine, will all break.

Given two backwards incompatible changes I hardly see how one which breaks
existing OpenIDs is favourable to one which changes how some are handled.

> 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.

I think it should behove the OpenID group to actually estimate how many people
might be using 303 redirects in conjunction with an OpenID such as I am before
concluding that the change should not be made.

I have a sneaking suspicion that I may be the only person.

If that is that case, I am happy to inform you that I don't mind the change.

> 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.

Sure, but that doesn't help me and my use case.

> 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.

Arguing the complexity of the implementation is just wand waving without some
concrete evidence to suggest that this would be a complex change.

Most HTTP libraries should offer simple hooks into the redirect chain.

> 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.

Again, I don't think you have provided any specifics about the cost of change.

We don't know how many people use 303 redirects with OpenID and we don't know
exactly how complex a change to the OpenID libraries would be.

> 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.)

Well, many HTTP clients provide clear hooks into redirect chain.

> 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.

Well, from my perspective it seems like eventually most people on the list
agreed that it was an issue as outlined by my use case. In any case, the
simplest things are often discussed at great length, if for not other reason
than the colour of the bikeshed, so this is a non sequitur.

> 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.

As I mentioned above, instead of altering how all the existing 303d OpenIDs
(again, perhaps I am the only one using OpenID like this) are handled, you would
break them all, permanently.

> RPs will continue to work the way they do now, for backwards-compatibility
> purposes

How are you so sure? Perhaps they will just stop working one day.

> and anyone publishing OpenID identifiers in the future will be able to find a
> clear statement about it in the spec.

This makes no sense. The current specification clearly tells me why my 303
redirect doesn't work, but that offers no comfort for me in the same way as
future explanation explaining why my 303 no longer works will also offer no
comfort.

Thanks,

--
Noah Slater <http://bytesexual.org/>