[OpenID] RPs accepting https:// identifiers

[Gerald Beuchelt]

Martin Atkins wrote:
> 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.
>
>   
    Yes, I do mostly look at this issue from the OP/IdP site.
> 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.
>
>   
    Which is a huge problem, IMHO.
> 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.
>
>   
    As I said, I would most likely prefer a solution like that; at the 
same time it seems easier to me to only allow a simple mapping between 
http and https versions. I'd rather have a quick and dirty solution to 
problem that can be ultimately extended to a more graceful solution, 
than engineer the problem for 6 months and leave the security hole open. 
Nevertheless, a generic identifier re-association would probably be the 
best solution.
> 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.
>
>   
    Yes. IMHO, for *any* future version of the protocol or its 
extensions, secure discovery should be REQUIRED--everything else leave 
the door open to more vulnerabilities.

Best,

Gerald