[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