Proposal: IdP-supported delegation

Johannes Ernst jernst+openid.net at netmesh.us
Mon Sep 4 19:43:10 PDT 2006


Hi Josh,

nicely written proposal ...

It appears that the OpenID privacy properties might change with this  
proposal? Currently, only the RP knows that a user used a particular  
identifier with that RP; not the IdP. While a web search might be  
able to reveal all identifiers of that user, it'd be rather hard to  
do in practice, in particular if delegates are hidden behind an XRI- 
style Yadis document lookup via mime type.

I haven't thought through how much or little this matters; I just  
wanted to bring up that there are privacy ramifications.

Cheers,


Johannes.


On Sep 4, 2006, at 13:00, 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.
>
> 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.
>
> 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.
>
> * 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 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.
>
> * 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)
>
> 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.
>
> Example
> -------
>
> Identifier: http://myvanitydomain.com/
> OpenID IdP Endpoint: http://www.myopenid.com/server
> Delegate: http://someone.myopenid.com/
>
> Currently specified flow
> ........................
>
> OpenID 1.X and 2.0 up to draft 9
>
> 1. Relying party does discovery on the identifier and obtains the
> identifier, endpoint URL and delegate.
>
> 2. Relying party makes an OpenID checkid_ request to the IdP endpoint
> asking to verify that the current user controls
> *http://someuser.myopenid.com/*
>
> 3. IdP verifies that the user can and wishes to verify
> *http://someuser.myopenid.com/*
>
> 4. Relying party receives response that the user does control
> *http://someuser.myopenid.com/* but authenticates the user as
> *http://myvanitydomain.com/*
>
> Proposed flow
> .............
>
> 1. Relying party does discovery on the identifier and obtains the
> identifier and endpoint URL.
>
> 2. Relying party makes an OpenID checkid_ request to the IdP endpoint
> asking to verify that the current user controls
> *http://myvanitydomain.com/*
>
> 3. IdP does discovery on http://myvanitydomain.com/, finds delegate
> http://someuser.myopenid.com/ and verifies that the user does control
> the delegate identifier.
>
> 4. Relying party receives response that the user does control
> *http://myvanitydomain.com/* and authenticates the user as such.
>
> Thoughts?
>
> Josh
>
> 1. http://lists.danga.com/pipermail/yadis/2006-September/002947.html
> 2. http://openid.net/specs/openid-authentication-2_0-08.txt
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://openid.net/pipermail/specs/attachments/20060904/58bfd06e/attachment.gif 
-------------- next part --------------
  http://netmesh.info/jernst






More information about the specs mailing list