Proposal: IdP-supported delegation

Recordon, David drecordon at verisign.com
Fri Sep 29 18:41:29 UTC 2006


Just a recap, my understanding is that this will not be built into
OpenID Authentication 2.0.  Is this an incorrect understanding on my
part?

--David 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Josh Hoyt
Sent: Monday, September 04, 2006 1:01 PM
To: specs at openid.net
Subject: Proposal: IdP-supported delegation

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




More information about the specs mailing list