[OpenID] RPs accepting https:// identifiers
Martin Atkins
mart at degeneration.co.uk
Mon Aug 11 23:01:18 UTC 2008
Gerald Beuchelt wrote:
> Martin -
>
> Thank you for the advise. Once we have migrated a significant number
> of our user population, we are quite determined to redirect.
>
> However, this does not solve the initial RP-side normalization to
> HTTP based identifiers. In my opinion, it is a necessary step, but not
> sufficient. But I would agree that performing a redirect on the HTTP
> port to HTTPS should be a highly recommended best practice.
>
I apologise for the fact that I misunderstood what you were doing in my
initial response; I thought you were coming at this from the RP's
perspective, not the OP's.
Really this is a specific form of the general problem of how to
automatically migrate from one identifier to another. Manually updating
all RPs you've used can be an arduous process, and some RPs don't even
allow the identifier(s) associated with an account to be changed.
However, I really don't like the idea of OpenID contradicting the
established rules for URI normalization. I think if RPs are going to
have to change anyway, it'd be better to introduce some explicit and
general mechanism for automatic identifier switching on login. However,
until most RPs are updated, neither approach is going to be very useful.
What we could really do with is a way to work around this where only the
OP would have to change. One approach could be to have the identifier
URL *not* redirect to the https: version, but have the OP UI give the
user the option of whether to use http: or https: for the eventual
assertion. Under OpenID 2.0, the OP is allowed to send an assertion to
and RP without an explicit request, so this would be permitted although
perhaps unexpected on the part of RPs. The OP could remember which sites
the user selected non-SSL for and make that the default next time. The
main downsite of this approach, of course, is that the discovery process
no longer has the protection of SSL, and is therefore vulnerable to
attacks such as the DNS one.
More information about the general
mailing list