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

George Fletcher gffletch at aol.com
Mon Oct 23 04:04:28 UTC 2006



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.
>
>>> 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.
>
>>
>> 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.

Thanks,
George



More information about the specs mailing list