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

Dick Hardt dick at sxip.com
Mon Oct 23 04:44:40 UTC 2006


On 22-Oct-06, at 9:04 PM, George Fletcher wrote:

>
>
> Dick Hardt wrote:
>>
>> 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.
> I agree it is the user's choice to pick a "trust worthy" IDP.   
> However, if "un-trust worthy" IDPs exist, and users choose them,  
> then the RP (in order to protect itself) has to determine which  
> IDPs it considers "trust worthy".  Hence both the user and the RP  
> "have to know" which IDPs are "trust worthy" and which are not.

What is the RP needing to protect itself from?
How does the RP protect itself from users that pick bad passwords or  
post them on sticky notes on their computer or walk away from their  
computer while logged in?

>>
>>>> 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?
> No, not really.  Though in most cases today the RP is also the IDP  
> so relying on "some other party" to do the authentication doesn't  
> happen too often (except within certain closely related services).   
> There is nothing stopping the RP from looking at the URI for the  
> IDP and not accepting it as a valid IDP.

agreed, just  like an RP can look at an IP address and decide not to  
accept it.

>>
>>>
>>> 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.
> I believe that there is also a need for the RP to "trust" the IdP  
> to not allow impersonation.
>>
>> 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.
> A RP provides a personal finance service that allows users to  
> manage portfolio information online.  It also supports online bill  
> pay services.  This RP requires a set of information for the  
> "account" to be created at the RP.  With the current specs that RP  
> can accept the authenticated OpenID URI and request the additional  
> required information.  Nothing different here. The issue come in  
> the form of liability for the RP.  Is the RP liable if someone gets  
> access to someone else's information?  In today's world this is the  
> case partly because the RP is doing its own authentication.  If the  
> RP is "trusting" an IDP to do the authentication (plain, strong,  
> second factor, etc) then who is liable?  I suspect the RP is,  
> though they might be able to "go after" the IdP.  Thus the RP needs  
> to know which IdPs are "trust worthy" in order to protect its  
> liability exposure.

One of the key innovations of user-centric identity is that the RP  
and IdP do not need to trust each other. This is initially a tough  
concept to accept for people that have worked in the security industry.

If an RP wants strong authentication, then the RP will request a  
strong authentication claim, and yes, the RP will need to trust the  
entity that made that claim. Note that the strong authentication may  
be claimed by a trusted vendor of strong auth rather then the IdP.

Now here is the interesting observation about liability, if the RP  
*is* deciding which IdPs the user can use, *then* the RP has  
liability. If the IdP selection is completely left to the user, then  
if the user's account is compromised, the RP can move all liability  
to the user.

Now in your example of a financial service, a prudent RP may suggest  
that the user select an IdP with strong authentication, bust still  
leave the choice up to the user.

Of course, your liability mileage may vary, but hopefully you get the  
idea.

-- Dick



More information about the specs mailing list