Proposal: IdP-supported delegation

Dick Hardt dick at
Wed Sep 6 08:13:05 UTC 2006

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.


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

More information about the specs mailing list