Delegation discussion summary

Graves, Michael MGraves at verisign.com
Fri Oct 13 00:00:22 UTC 2006


Josh, et al,

I believe the first of your options --  "Both portable and IdP-specific
identifiers" -- is the superior choice here. It preserves OpenID 1
semantics, and unambiguously makes room for portable identifiers. I
don't see the added burden carried by relying party code for this option
viz. portable identifiers only as being significant. Recommend we
proceed with the "both" strategy.

Also, this may be throwing a wrench in the gears here, but I'd like to
toss in the idea of using this point in time to pivot on our terminology
and look at adopting Dick Hardt's terminology here. Portable identifiers
are a powerful upgrade in and of themselves, and get us off the "IDP
lock-in" hook that I've been hung up with customers on now a couple
times. But as we move away from explicit IdP-specific URLs as the only
identifier, I think that the Sxip "homesite" model becomes more
important to consider as well. I very much like the idea of entiring in
my "homesite" URL at a participating "membersite" (OpenID relying
party), say "http://myidmanager.com" and during the authentication
process, being able to choose from one of n available personae managed
for me by myidmanager.com. So my "final" identifier may be
"http://myidmanager.com/73648729" or even "http://graves.isnuts.com". 

I won't delve into where we are with respect to that capability here,
but want to suggest that maybe as we move to OpenID 2.0, and now offer
portable IDs (as well as run-time chosen IDs selected at auth-time?), we
may be wise to just make the jump to using "homesite" and "membersite"
across the board, rather than "IdP" and "relying party", both of which
are technically problematic for our framework.

Anyway, that's a bit off topic, but something to consider. 

In any case, the "both" option below gets my vote.

Good work Josh!

-Mike


-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Josh Hoyt
Sent: Thursday, October 12, 2006 12:29 PM
To: specs at openid.net
Subject: Delegation discussion summary

Hello, list,

I'm sure that another message in your inbox with "delegation" in the
title makes most of you cringe, so I'm sorry for that.I hope that this
one gets us closer to resolving this issue.

I have attempted to summarize the proposed delegation mechanisms, as
well as the currently-specified delegation mechanism in a single
document. I have glossed over some issues and left out some of the
discussion, but I hope that I captured most of the important stuff.
After reviewing the discussion, I think that we are actually pretty
close to consensus on a course of action.

I have added one new thing in this write-up, which is that I have
started calling "delegation" "portable identifier support", which gives
rise to the term "portable identifier" for what is currently called a
"delegated identifier." I think that this terminology is a little easier
to understand and less loaded than calling it "delegation."

My write-up follows.

Josh

OpenID portable identifier support
##################################

Portable identifier support allows an IdP to do authentication for an
identifier that was not issued by that IdP. It has two motivating use
cases [1]_:

  * allow users to use any identifier with any IdP

  * allow users to move an identifier between IdPs (prevent IdP lock-in)

Each portable identifiers has an IdP-specific identifier tied to it.
This identifier allows the IdP to know what credentials to require
before issuing an authentication response even though the IdP does not
control the portable identifier.

Throughout this discussion, I will assume that there is a portable
identifier called "http://my.portable.url/" that uses an IdP-specific
identifier called "http://my.idp.specific.url/".


Current implementation
======================

OpenID 1 [2]_ calls portable identifier support "delegation." In this
implementation, the IdP-specific identifier is the only identifier that
is communicated between the relying party and the IdP. When a relying
party discovers that it is requesting authentication for a portable
identifier, it must keep that state available for processing the
response, since the response message does not contain the portable
identifier at all.

Request and response messages for this mechanism both use the following
field::

  openid.identity = http://my.idp.specific.url/

This mechanism has a few drawbacks:

 * The relying party must manage state information for the duration of
   the transaction.

 * The authentication messages are potentially confusing, since the
   authentication response is not meaningful without the context of
   the initiation, and the IdP-specific identifier does not even have
   to be a valid OpenID identifier.

  * The IdP *cannot* be aware that it is using a portable identifier,
   so the IdP cannot assist the user in making decisions for different
   identifiers. For example, a user might wish to be prompted for
   confirmation each time he used one identifier, but allow automatic
   approval for another.

  * IdP-driven identifier selection in the OpenID 2.0 specification (up
   to draft 9) cannot return assertions for portable identifiers,
   because the verification algorithm will fail.

  * Portable identifiers must be treated differently from IdP-issued
   identifiers by the code running on the relying party


Proposed changes
================

All of the changes to delegation that have been proposed retain the
important features of portable identifier support. Additionally, they
all retain the same basic structure, where the IdP-specific identifier
is available from the standard discovery process. Primarily, the
proposals change what data is available in the protocol messages, the
relationship of the request to the response, and/or the party who is
responsible for discovering the IdP-specific identifier for the portable
identifier.

Both of the proposed changes to the response messages include the
portable identifier in the authentication response. Changing the
response to contain the portable identifier removes the burden of
maintaining that state from the relying party. Removing this dependency
on transaction state enables portable identifiers to be used in both
IdP-driven identifier selection and IdP-initiated authentication ("bare
response") [3]_.

Neither proposal outlined here changes the protocol unless a portable
identifier is used.


Both portable and IdP-specific identifiers
------------------------------------------

Include both the portable identifier and the IdP-specific identifier in
the request and response ([4]_ and
[5]_)::

  openid.identity = http://my.idp.specific.url/
  openid.portable = http://my.portable.url/

The relying party is still responsible for checking to make sure that
the IdP-specific identifier that is returned matches what is discovered
from the portable identifier, but since it is included in the
authentication response, it is not necessary for the relying party to
maintain this state, and an authentication response is meaningful
without the context of the request.

The messages in this proposal are very explicit about what is going on.
The only way in which this differs from OpenID 1 is that the portable
identifier is also included in the response. The meaning of the
"openid.identity" parameter is identical to its meaning in the OpenID 1
protocol (the IdP-specific identifier).


Portable identifier only
------------------------

Include only the portable identifier in the request and response ([6]_
and [7]_)::

  openid.identity = http://my.portable.url/

In this proposal, the relying party does not use the IdP-specific fields
that are available during discovery. The IdP must do discovery on the
supplied identifier to determine what IdP-specific identifier has been
specified.

This proposal simplifies relying party behavior. The messages that are
passed have an obvious meaning and are easy to verify. The meaning of
the "openid.identity" parameter is different from its meaning in the
OpenID 1 protocol.


References
==========

.. [1] "openid.delegate explained."

       Brad Fitzpatrick, 3 October 2006

       http://openid.net/pipermail/specs/2006-October/000182.html



.. [2] "OpenID Authentication 1.1"

       David Recordon, Brad Fitzpatrick, May 2006

       http://openid.net/specs/openid-authentication-1_1.html



.. [3] "[PROPOSAL] bare response / bare request"

       Dick Hardt, 30 September 2006

       http://openid.net/pipermail/specs/2006-September/000142.html



.. [4] "cachability of delegated identity URLs"

       Brad Fitzpatrick, 8 June 2006

       http://lists.danga.com/pipermail/yadis/2005-June/000676.html



.. [5] "Delegation Proposal Amendment"

       Josh Hoyt, 6 October 2006

       http://openid.net/pipermail/specs/2006-October/000269.html



.. [6] "Proposal: IdP-supported delegation"

       Josh Hoyt, 4 September 2006

       http://openid.net/pipermail/specs/2006-September/000002.html



.. [7] "PROPOSAL: OpenID Authentication Flow and how delegate fits in"

       Dick Hardt, 9 October 2006

       http://openid.net/pipermail/specs/2006-October/000310.html
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list