[OpenID] RPs accepting https:// identifiers

[Andrew Arnott]

Of course, XRIs have most of these problems already solved.  :)

On Tue, Aug 12, 2008 at 6:09 AM, Gerald Beuchelt <beuchelt at sun.com> wrote:

> 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
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080812/a2cb6fbd/attachment-0001.htm>