Realm spoofing spec patch

[Allen Tom]

Hi Josh,

Having the OP verify the realm/return_to as part of the Authentication
Request is fine. OPs should cache the verifcation status to reduce
latency for RPs that send many users to the OP.

At least from my perspective, it always seemed odd that the Association
Request is just an interface for OPs to return shared secrets and
association handles without knowing anything about the requestor, except
for the IP address. I always thought that RPs should pass some
information about themselves to the OP when requesting association so
that an OP can bind an association handle with an RP.

Anyway, I don't think there's any pressing need to change the
association request interface at this time.

Thanks!
Allen




> Allen,
> 
> On 5/29/07, Allen Tom <openid at allentom.com> wrote:
> > 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.
> 
> Were you concerned about implementation complexity or the time it
> could take to do discovery while the user is waiting?
> 
> At association time, the provider does not know who the relying party
> is. Are you proposing that the realm be included in the association
> request? In that case we'd have to include the discovery URL, in the
> case of a wildcard realm.
> 
> I see two potential problems:
> 
>  1. If the discovery happens during the association request, a
>     single-threaded relying party might not respond to the
>     verification request. This wouldn't come up too frequently in
>     production, but it would raise the bar for example and prototype
>     code.
> 
>  2. If the form of a return_to URL changes (and the relying party
>     updates the discovery information to match) it would be good if
>     the provider could attempt verification again, so that a valid
>     request could complete successfully.
> 
> (2) requires the same flow as the proposed implementation
> (verification during the course of the request), and so I think it's
> simpler to just leave it in-band. I suppose that the specification
> could remain silent on *when* to perform the verification, since it
> doesn't really matter from a security perspective, which would leave
> both channels open, as long as the pertinent information was added to
> the association request.
> 
> Josh
> 
>