Proposal: IdP-supported delegation

Josh Hoyt josh at
Tue Sep 5 18:35:07 UTC 2006

On 9/5/06, Johannes Ernst < at> wrote:
> Your motivation for the proposal says it is "IdP-driven identifier
> selection". [...] But that isn't the protocol flow that you outline
> because the delegate URL isn't even known in that case. I'm
> confused ... how does this relate to "IdP-driven identifier selection"?

You're right, the proposed solution did not describe IdP-driven
selection, and so didn't not really describe how it overcomes the
problem (or even what the problem really is).

With OpenID 1.X delegation, the IdP cannot return an authentication
response with an identifier that has a delegate, because the RP
expects the *delegate* to appear in the response. Because of this,
delegated identifiers will not work with IdP-driven identifier

> Also: would there be an alternate way of solving the problem, without
> protocol changes, by requiring the user to register
> "" with the IdP, from where the user could select
> it if she so chose?

With my proposal, delegation *becomes* the standard way of registering
an identifier with an IdP. Having a standard way of doing it keeps the
control in the hands of the user, as well as being
backwards-compatible with OpenID 1.X.

With the proposed delegation mechanism, an IdP could, for example,
allow a user to add identifiers at any time, including in the middle
of an authentication request, and it could use standard OpenID
discovery to do so.

An alternate solution is to change the specification so that the
authentication response can contain either the delegate *or* the
user's identifier. I think my original proposal is less confusing to
understand and implement, although it's a bigger change.


More information about the specs mailing list