Proposal: IdP-supported delegation

Dick Hardt dick at sxip.com
Fri Sep 22 00:44:59 UTC 2006


The "enter your identifier URL"  (EYIU) presumes the protocol is used  
for SSO and the user wants to not have a unique identifier for  
certain types of sites. Many sites are asking for profile data, but  
are not looking to register me, so a unique identifier is not needed.

EYIU model has the user identify themselves before their IdP has had  
an opportunity to assist the user in deciding if they want to  
interact with that RP.

The Homesite model is well suited for Rich Client IdPs.

If the IdP is clueless, then all bets are off regardless of model.

A shady RP bouncing a user to MySpace will likely have the MySpace  
IdP ask the user WTF do you want to do with this RP.

... and If the major IdP on the internet is Myspace, we will have  
failed!

Was there a change you were suggesting?

-- Dick

On 20-Sep-06, at 12:56 PM, Brad Fitzpatrick wrote:

> I don't like the "enter your homesite" model as much as "enter your
> identifier URL" because in the former case, I can imagine:
>
>   -- everybody being on MySpace (or the next popular site)
>
>   -- that IdP being clueless, or having clueless users who will click
>      on anything
>
>   -- a slightly-shady RP that doesn't ask people for their homesite
>      because they just guess it's MySpace and start the auth flow
>      assuming user had typed that.
>
> Or variations on the above.
>
> But if things only work if you enter your full identifer, there's no
> incentive for those shady RPs to try and guess who you are because now
> there's millions of possibilities, not seven (or one popular one).
>
> Brad
>
>
> On Wed, 20 Sep 2006, Drummond Reed wrote:
>
>> Josh,
>>
>> Having reviewed your proposal at
>> http://openid.net/pipermail/specs/2006-September/000002.html, and  
>> read the
>> messages on the list (including Dick's below), what's the current  
>> status of
>> this proposal?
>>
>> I'm increasingly believing that to community consensus on this  
>> issue is
>> essential not just to accommodate the SXIP concept of "homesite"
>> identifiers, but to harmonize the whole way OpenID handles identifier
>> "delegation" with how XRI handles identifier "synonyms". (As you  
>> know, XRI
>> architecture uses the latter term because the term "delegation"  
>> has a very
>> well-defined meaning in the context of identifiers, particularly  
>> DNS.)
>>
>> It's important from multiple perspectives:
>>
>>  * Terminology
>>  * User experience and understanding of OpenID identifier choices
>>  * Identifier persistence and portability
>>  * XRDS document construction and service endpoint provisioning
>>  * Protocol flow
>>  * Privacy
>>
>> Net net: to get OpenID Autentication 2.0 right, I think it is  
>> vital to get
>> this right.
>>
>> Perhaps we need a "summit" focusing expressly on this issue?
>>
>> =Drummond
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net]  
>> On Behalf
>> Of Dick Hardt
>> Sent: Wednesday, September 06, 2006 1:13 AM
>> To: Josh Hoyt
>> Cc: specs at openid.net
>> Subject: Re: Proposal: IdP-supported delegation
>>
>>
>> On 4-Sep-06, at 1:00 PM, Josh Hoyt wrote:
>>
>>> Hello, specs list!
>>>
>>> Here is an OpenID 2.0 spec proposal, prompted by Martin's message[1]
>>> to the Yadis list about delegation and IdP-driven identifier
>>> selection.
>>>
>>> Problem
>>> =======
>>>
>>> One annoying hole in the OpenID 2.0 draft 8 specification[2] is that
>>> IdP-driven identifier selection does not work with delegation.
>>> Delegated identifiers are not be available to be chosen by the  
>>> IdP if
>>> the user initiates IdP-driven identifier selection, since the IdP  
>>> may
>>> not even be aware that a user is using delegation.
>>
>> In IdP-driven identifier selection, the IdP needs to know the
>> delegate identifier in advance. The IdP knows the user owns the URL
>> since the user is inserting a user specific delegate URL into the
>> document at a URL they control. The solution is for the user to tell
>> the IdP, hey, I would like to use this URL when prompted.
>>
>> An advantage of the current design is that the user does not have to
>> tell the IdP that they are using delegation.
>>
>>>
>>> Proposal
>>> ========
>>>
>>> This problem would go away if the protocol messages always sent the
>>> identifier that was being confirmed to the IdP. Currently, when  
>>> using
>>> delegation, that identifier must be remembered by the relying party,
>>> and is never sent to the IdP.
>>
>> But the identifier being confirmed would not be sent in an IdP-driven
>> identifier selection, which was your problem statement above.
>>
>>>
>>> When an IdP receives a request for an identifier that it does not
>>> recognize, it can perform discovery on the identifier and read the
>>> delegate information itself. Its response would be about the  
>>> requested
>>> identifier, not the delegate.
>>>
>>> A request for a delegated identifier and a request for a non- 
>>> delegated
>>> identifier would be the same for the relying party, and the final,
>>> verified identifier would always be included in the request/ 
>>> response.
>>>
>>> Delegation becomes a portable way to register an identifier with an
>>> IdP, and does not need to show up on the wire anymore.
>>>
>>> Benefits
>>> --------
>>>
>>> * The identifier in question is always in the protocol message. This
>>> makes debugging and implementation easier.
>>>
>>> * The relying party does not need to keep the originally requested
>>> identifier in session state, since it's always included in the
>>> message.
>>
>> If state is needing to be preserved, adding another item is nominal.
>> Have we managed to remove any state dependancy?
>>
>>>
>>> * Since the IdP needs to be able to do discovery and support the
>>> delegate tag, it can offer delegate identifiers for IdP-driven
>>> identifier selection.
>>
>> The IdP needs to be told what those are.
>>
>>>
>>> * The same markup works for both the existing delegation  
>>> mechanism and
>>> this new proposal, so it does not increase end-user complexity, even
>>> if the identifier supports both OpenID 1.X and 2.0.
>>
>> nice
>>
>>>
>>> * The IdP can confirm that an identifier meets security  
>>> requirements,
>>> even when delegation is used. (e.g. is served over SSL using
>>> encryption and a certificate that is signed by a known authority)
>>
>> good point -- but the user is choosing their URL anyway, the IdP
>> can't control that.
>>
>>>
>>> Drawbacks
>>> ---------
>>>
>>> * An additional discovery step may need to be done by the IdP
>>>
>>> * The user-entered identifier is disclosed to the IdP.
>>>
>>> I think that disclosing the identifier to the *IdP* is a non-issue.
>>> The only potential issue is that some IdP may choose not to support
>>> delegation in order to lock in users.
>>
>> I saw this as a big feature. The IdP does not know my real identifier
>> that I am using. Big increase in privacy.
>>
>> I think the privacy advantages outweigh the other advantages.
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>




More information about the specs mailing list