Proposal: IdP-supported delegation

[Drummond Reed]

Josh,

Having reviewed your proposal at
http://openid.net/pipermail/specs/2006-September/000002.html, and read the
messages on the list (including Dick's below), what's the current status of
this proposal?

I'm increasingly believing that to community consensus on this issue is
essential not just to accommodate the SXIP concept of "homesite"
identifiers, but to harmonize the whole way OpenID handles identifier
"delegation" with how XRI handles identifier "synonyms". (As you know, XRI
architecture uses the latter term because the term "delegation" has a very
well-defined meaning in the context of identifiers, particularly DNS.)

It's important from multiple perspectives:

 * Terminology
 * User experience and understanding of OpenID identifier choices
 * Identifier persistence and portability
 * XRDS document construction and service endpoint provisioning
 * Protocol flow
 * Privacy

Net net: to get OpenID Autentication 2.0 right, I think it is vital to get
this right.

Perhaps we need a "summit" focusing expressly on this issue?

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
Sent: Wednesday, September 06, 2006 1:13 AM
To: Josh Hoyt
Cc: specs at openid.net
Subject: Re: Proposal: IdP-supported delegation


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.

nice

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

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs