Realm spoofing spec patch

[Allen Tom]

Josh - thanks for writing this up!

David - Many OPs may choose not to let their users login into RPs that
can't be verified. For instance, in the case where a large corporation
like Sun issues their employees OpenIDs, the corporation may want to be
very selective as to which RPs they let their employees sign into.

An OP that is targeting mass market/consumer users may instead want to
sternly warn their users that the RP can't be verified, similar the
warning that browsers display when there are issues with the cert when
using HTTPS. 

I'd expect that if the realm spoofing patch is included in the core
protocol, and if large OPs were to implement RP endpoint discovery, then
most RPs have a very strong incentive to implement this in order to
supress the ugly warning. The solution discussed at IIW and proposed by
Josh should be trivial for all serious RPs to implement. If all serious
RPs and most of the others implment this, then the OP warning should
really be a very rare exception rather than the rule.

David - you are correct in that there is a larger problem around trust
between OPs and RPs, but this can probably be solved via out of band
pre-association. Unfortunately, this process would probably be very
heavyweight and not be easy to automate, and would probably be reserved
for parties that have some sort of business and contractual
relationship. There is no need to have something this heavyweight in the
spec as the process would probably be very proprietary and RP/OP specific.

In the interest of interoperability and ease of implementation, the
proposed solution is very lightweight and does seem to solve the
problem. It would be great if this patch be included in the core spec,
and not as an extension.

>From an implementation perspective, it might make sense for the OP to
verify the RP during the association request, so that the association
handle is only returned after the RP has been verified.

Thanks!
Allen


> It seems that this methodology only works if either:
>  1) Every site (RP or proxy) publishes their return_to endpoints or that
> they don't have any.
>  2) An OP refuses to let the user login to a RP which doesn't publish
> their return_to endpoint.
> 
> I'm unconvinced that either of those situations will actually become
> prevalent and thus worried about the effectiveness of this methodology.
> 
> Using the same example from IIW, I am logging into
> http://evilrp.com/return_to which is proxying itself through
> http://www.google.com/translate/.  If my OP were to prompt me, "We're
> unable to verify the site
> (http://www.google.com/translate/?http://evilrp.com/return_to) you're
> logging into, you should use caution when proceeding" I'm unsure how
> many users would actually not proceed, or rather see "google.com" and
> decide it is alright.
> 
> I guess since we're unable to fully resolve this issue from a technical
> perspective, and no I don't have a better technical solution, I'm
> wondering if this should actually be an extension to the core protocol
> versus seeming like a resolution to the problem when it really doesn't
> completely solve it.  In some senses I see this as a larger problem
> around trust of Relying Parties.