Proposal: IdP-supported delegation

Josh Hoyt josh at janrain.com
Mon Sep 4 13:00:58 PDT 2006


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


More information about the specs mailing list