Proposal: IdP-supported delegation

Thu Sep 21 00:03:23 UTC 2006

Brad,

Valid points all. So are you taking issue with the whole "IdP-Driven
Identifier Selection" section of
http://www.lifewiki.net/openid/OpenIDChanges**, or suggesting that it should
be narrowed down in some way, or...?

=Drummond 

**Note to OpenID wiki gardener: it would be great to have table-of-contents
functions on the wiki pages so subheads can be linked directly -- see
http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 for an example.

-----Original Message-----
From: Brad Fitzpatrick [mailto:brad at danga.com] 
Sent: Wednesday, September 20, 2006 12:56 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; specs at openid.net
Subject: RE: Proposal: IdP-supported delegation

I don't like the "enter your homesite" model as much as "enter your
identifier URL" because in the former case, I can imagine:

  -- everybody being on MySpace (or the next popular site)

  -- that IdP being clueless, or having clueless users who will click
     on anything

  -- a slightly-shady RP that doesn't ask people for their homesite
     because they just guess it's MySpace and start the auth flow
     assuming user had typed that.

Or variations on the above.

But if things only work if you enter your full identifer, there's no
incentive for those shady RPs to try and guess who you are because now
there's millions of possibilities, not seven (or one popular one).

Brad

On Wed, 20 Sep 2006, Drummond Reed wrote:

> 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
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>