that ess in 'https'

[David Strauss]

Jonathan Daugherty wrote:
>> I thought we were trying to decide whether we should adopt the
>> convention that pairs of URLs like the following two URLs, when used
>> as identity URLs, are equivalent: identify the same persona.
>>
>>    http://joaquin.net
>>    https://joaquin.net
> 
> I've said this before: whether these identity URLs are equivalent is a decision
> best left up to the parties serving and / or controlling both URLs.  If you
> want one URL to be equivalent to the other -- at least in OpenID land -- you
> set up a redirect.

That would work *if* the Relying Parties were all capable of pulling
https pages. They're not. If I set up http://getopenid.com/david to
redirect to https://getopenid.com/david, it wouldn't work on a number of
sites.

My suggestions have been in the spirit of OpenID's reluctance to ever
require SSL support by any party. We need to either require SSL support
by RPs or always allow insecure fallback.

> If you're using an identity provider that supports both, fine; you set up a
> redirect from http:// to https:// and feel free to use either.  If you only
> support https://, even better.  If a user enters a URL with no scheme, then you
> define some way to try them in a sane order (e.g. https:// and fall back to
> http:// if necessary).

This "fallback" is precisely what I'd like to standardize, and it can
only be standardized on the Relying Party side. The Server cannot
control how the RP falls back from pages that may not even exist or that
the RP is incapable of pulling.

> But these are not the same URL, even if they *do* refer to the same person,
> persona, dog, or constellation.  If you want that equivalence to manifest on a
> case-by-case basis, then implement it as such, and not as some protocol kludge
> that abandons standard URL interpretation.  No offense. :)

OpenID already has such a "kludge" when a user enters an incomplete URL
in the signon box. getopenid.com/david gets automatically transformed
into http://getopenid.com/david in seemingly 100% of cases. The bad part
is that this "kludge" is unstandardized. Server developers have no way
to know how user-inputted URLs will become converted into a real URLs.
Yet, each user I've done usability testing with *excludes* the http and
https when he or she is typing his or her OpenID.

Such user behavior combined with the lack of established URL
standardization methods is a *very* bad thing. It makes OpenID signons
potentially inconsistent across sites.

The spec only says "A consumer must canonicalize the URL, following
redirects and noting the final URL." What canonicalization means is
undefined.

> (Of course, if schemes were necessary on input URLs, some of this would be a
> non-issue, but that's a usability issue of its own...)

Indeed. OpenID 1.0/1.1 opened the floodgates to this issue when it
didn't require a scheme and allowed RP sites to add one themselves. It's
not a bad floodgate that's been opened, but it's one that must be addressed.

David Strauss
Four Kitchen Studios
GetOpenID.com