[PROPOSAL] Handle "http://user at example.com" Style Identifiers

[Dick Hardt]

On 22-Oct-06, at 7:00 PM, George Fletcher wrote:

>
>
> Dick Hardt wrote:
>> With OpenID, there is a presumption the user has selected a trust
>> worthy IdP that  will only present the user's identifiers when it
>> really is the user.
>>
> Doesn't this imply that both the user and RP have to know which IdP's
> are "trust worthy"?

It is a choice by the user. Just like the user chooses with ISP to  
move their data, which browser to run, which OS to run. IN general,  
those are not dictated by the RP.

>> Actually, idp.spammers.com cannot do that. The URL has metadata that
>> states which IdP(s) are authoritative. What idp.spammers.com can  
>> do is
>> flood an RP with a bunch of identifiers. But this is no different  
>> then
>> a script creating new accounts on a system and is defended using the
>> same mechanisms such as throttling and captchas.
>>
> So why can't idp.spammers.com allow anyone to enter a URI of
> http://idp.spammers.com/<name> that resolves to a valid XRDS document.
> The RP then follows the IdP service link back to
> https://idp.spammers.com and does the association exchange.  Now  
> the RP
> re-directs the user to https://idp.spammers.com for the login page,
> which just re-directs the user back to the RP with the valid  
> "assertion"
> fields. idp.spammers.com does not have to ask the user for
> authentication credentials (that is out of scope for the spec).  For
> commenting on blogs this would be similar to "bugmenot" for web
> subscription services.
>
> So of course, the RP just needs to "blacklist" idp.spammers.com.  But
> now we are back in the same situation we have today where its a race
> between spammers setting up "IdPs" and RPs "black-listing" them.

I don't understand why the RP needs to do that ... is the RP wanting  
to do something it can't do today?

>
> Fundamentally, "trust worthiness" is paramount to making the system
> work.  For now, this means RPs will likely have some sort of ACL  
> (black
> or white) for the IdPs that they deal with.

The "trust" I am referring to is the user "trusting" the IdP to not  
let someone else impersonate them.

George: would you explain what problem you are wanting to solve so  
that we can deal with a concrete example? There are use cases OpenID  
solves today, and others require additional features that currently  
are not in the specification.

-- Dick