<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: Delegation discussion summary</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>I'd have to agree with Gabe about this, let's get it done! :)<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Gabe Wachob [<A HREF="mailto:gabe.wachob@amsoft.net">mailto:gabe.wachob@amsoft.net</A>]<BR>
Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time<BR>
To: Graves, Michael; specs@openid.net<BR>
Subject: RE: Delegation discussion summary<BR>
<BR>
*If* we are going to open up the terminology discussion, for me the terms<BR>
"authenticating party" (formerly the "IDP") and "accepting party" (formerly<BR>
the "relying party") seem more descriptive. The authenticating party issues<BR>
authentication assertions in the form of special HTTP request/responses with<BR>
the other party, who then accepts these assertions and decides whether or<BR>
not they are good enough to let a user do something.<BR>
<BR>
As far as Dick's terminology, I'm not sure how "membersite" makes sense<BR>
here. Perhaps it's a matter of history or perspective that I haven't been<BR>
enlightened on.<BR>
<BR>
In any case, I'd rather get openid 2.0 out sooner than have a long<BR>
discussion on terminology, so I won't push this any further unless someone<BR>
else really thinks its valuable.<BR>
<BR>
Gabe<BR>
<BR>
> -----Original Message-----<BR>
> From: specs-bounces@openid.net [<A HREF="mailto:specs-bounces@openid.net">mailto:specs-bounces@openid.net</A>] On Behalf<BR>
> Of Graves, Michael<BR>
> Sent: Thursday, October 12, 2006 5:00 PM<BR>
> To: specs@openid.net<BR>
> Subject: RE: Delegation discussion summary<BR>
><BR>
> Josh, et al,<BR>
><BR>
> I believe the first of your options -- "Both portable and IdP-specific<BR>
> identifiers" -- is the superior choice here. It preserves OpenID 1<BR>
> semantics, and unambiguously makes room for portable identifiers. I<BR>
> don't see the added burden carried by relying party code for this option<BR>
> viz. portable identifiers only as being significant. Recommend we<BR>
> proceed with the "both" strategy.<BR>
><BR>
> Also, this may be throwing a wrench in the gears here, but I'd like to<BR>
> toss in the idea of using this point in time to pivot on our terminology<BR>
> and look at adopting Dick Hardt's terminology here. Portable identifiers<BR>
> are a powerful upgrade in and of themselves, and get us off the "IDP<BR>
> lock-in" hook that I've been hung up with customers on now a couple<BR>
> times. But as we move away from explicit IdP-specific URLs as the only<BR>
> identifier, I think that the Sxip "homesite" model becomes more<BR>
> important to consider as well. I very much like the idea of entiring in<BR>
> my "homesite" URL at a participating "membersite" (OpenID relying<BR>
> party), say "<A HREF="http://myidmanager.com">http://myidmanager.com</A>" and during the authentication<BR>
> process, being able to choose from one of n available personae managed<BR>
> for me by myidmanager.com. So my "final" identifier may be<BR>
> "<A HREF="http://myidmanager.com/73648729">http://myidmanager.com/73648729</A>" or even "<A HREF="http://graves.isnuts.com">http://graves.isnuts.com</A>".<BR>
><BR>
> I won't delve into where we are with respect to that capability here,<BR>
> but want to suggest that maybe as we move to OpenID 2.0, and now offer<BR>
> portable IDs (as well as run-time chosen IDs selected at auth-time?), we<BR>
> may be wise to just make the jump to using "homesite" and "membersite"<BR>
> across the board, rather than "IdP" and "relying party", both of which<BR>
> are technically problematic for our framework.<BR>
><BR>
> Anyway, that's a bit off topic, but something to consider.<BR>
><BR>
> In any case, the "both" option below gets my vote.<BR>
><BR>
> Good work Josh!<BR>
><BR>
> -Mike<BR>
><BR>
><BR>
> -----Original Message-----<BR>
> From: specs-bounces@openid.net [<A HREF="mailto:specs-bounces@openid.net">mailto:specs-bounces@openid.net</A>] On<BR>
> Behalf Of Josh Hoyt<BR>
> Sent: Thursday, October 12, 2006 12:29 PM<BR>
> To: specs@openid.net<BR>
> Subject: Delegation discussion summary<BR>
><BR>
> Hello, list,<BR>
><BR>
> I'm sure that another message in your inbox with "delegation" in the<BR>
> title makes most of you cringe, so I'm sorry for that.I hope that this<BR>
> one gets us closer to resolving this issue.<BR>
><BR>
> I have attempted to summarize the proposed delegation mechanisms, as<BR>
> well as the currently-specified delegation mechanism in a single<BR>
> document. I have glossed over some issues and left out some of the<BR>
> discussion, but I hope that I captured most of the important stuff.<BR>
> After reviewing the discussion, I think that we are actually pretty<BR>
> close to consensus on a course of action.<BR>
><BR>
> I have added one new thing in this write-up, which is that I have<BR>
> started calling "delegation" "portable identifier support", which gives<BR>
> rise to the term "portable identifier" for what is currently called a<BR>
> "delegated identifier." I think that this terminology is a little easier<BR>
> to understand and less loaded than calling it "delegation."<BR>
><BR>
> My write-up follows.<BR>
><BR>
> Josh<BR>
><BR>
> OpenID portable identifier support<BR>
> ##################################<BR>
><BR>
> Portable identifier support allows an IdP to do authentication for an<BR>
> identifier that was not issued by that IdP. It has two motivating use<BR>
> cases [1]_:<BR>
><BR>
> * allow users to use any identifier with any IdP<BR>
><BR>
> * allow users to move an identifier between IdPs (prevent IdP lock-in)<BR>
><BR>
> Each portable identifiers has an IdP-specific identifier tied to it.<BR>
> This identifier allows the IdP to know what credentials to require<BR>
> before issuing an authentication response even though the IdP does not<BR>
> control the portable identifier.<BR>
><BR>
> Throughout this discussion, I will assume that there is a portable<BR>
> identifier called "<A HREF="http://my.portable.url/">http://my.portable.url/</A>" that uses an IdP-specific<BR>
> identifier called "<A HREF="http://my.idp.specific.url/">http://my.idp.specific.url/</A>".<BR>
><BR>
><BR>
> Current implementation<BR>
> ======================<BR>
><BR>
> OpenID 1 [2]_ calls portable identifier support "delegation." In this<BR>
> implementation, the IdP-specific identifier is the only identifier that<BR>
> is communicated between the relying party and the IdP. When a relying<BR>
> party discovers that it is requesting authentication for a portable<BR>
> identifier, it must keep that state available for processing the<BR>
> response, since the response message does not contain the portable<BR>
> identifier at all.<BR>
><BR>
> Request and response messages for this mechanism both use the following<BR>
> field::<BR>
><BR>
> openid.identity = <A HREF="http://my.idp.specific.url/">http://my.idp.specific.url/</A><BR>
><BR>
> This mechanism has a few drawbacks:<BR>
><BR>
> * The relying party must manage state information for the duration of<BR>
> the transaction.<BR>
><BR>
> * The authentication messages are potentially confusing, since the<BR>
> authentication response is not meaningful without the context of<BR>
> the initiation, and the IdP-specific identifier does not even have<BR>
> to be a valid OpenID identifier.<BR>
><BR>
> * The IdP *cannot* be aware that it is using a portable identifier,<BR>
> so the IdP cannot assist the user in making decisions for different<BR>
> identifiers. For example, a user might wish to be prompted for<BR>
> confirmation each time he used one identifier, but allow automatic<BR>
> approval for another.<BR>
><BR>
> * IdP-driven identifier selection in the OpenID 2.0 specification (up<BR>
> to draft 9) cannot return assertions for portable identifiers,<BR>
> because the verification algorithm will fail.<BR>
><BR>
> * Portable identifiers must be treated differently from IdP-issued<BR>
> identifiers by the code running on the relying party<BR>
><BR>
><BR>
> Proposed changes<BR>
> ================<BR>
><BR>
> All of the changes to delegation that have been proposed retain the<BR>
> important features of portable identifier support. Additionally, they<BR>
> all retain the same basic structure, where the IdP-specific identifier<BR>
> is available from the standard discovery process. Primarily, the<BR>
> proposals change what data is available in the protocol messages, the<BR>
> relationship of the request to the response, and/or the party who is<BR>
> responsible for discovering the IdP-specific identifier for the portable<BR>
> identifier.<BR>
><BR>
> Both of the proposed changes to the response messages include the<BR>
> portable identifier in the authentication response. Changing the<BR>
> response to contain the portable identifier removes the burden of<BR>
> maintaining that state from the relying party. Removing this dependency<BR>
> on transaction state enables portable identifiers to be used in both<BR>
> IdP-driven identifier selection and IdP-initiated authentication ("bare<BR>
> response") [3]_.<BR>
><BR>
> Neither proposal outlined here changes the protocol unless a portable<BR>
> identifier is used.<BR>
><BR>
><BR>
> Both portable and IdP-specific identifiers<BR>
> ------------------------------------------<BR>
><BR>
> Include both the portable identifier and the IdP-specific identifier in<BR>
> the request and response ([4]_ and<BR>
> [5]_)::<BR>
><BR>
> openid.identity = <A HREF="http://my.idp.specific.url/">http://my.idp.specific.url/</A><BR>
> openid.portable = <A HREF="http://my.portable.url/">http://my.portable.url/</A><BR>
><BR>
> The relying party is still responsible for checking to make sure that<BR>
> the IdP-specific identifier that is returned matches what is discovered<BR>
> from the portable identifier, but since it is included in the<BR>
> authentication response, it is not necessary for the relying party to<BR>
> maintain this state, and an authentication response is meaningful<BR>
> without the context of the request.<BR>
><BR>
> The messages in this proposal are very explicit about what is going on.<BR>
> The only way in which this differs from OpenID 1 is that the portable<BR>
> identifier is also included in the response. The meaning of the<BR>
> "openid.identity" parameter is identical to its meaning in the OpenID 1<BR>
> protocol (the IdP-specific identifier).<BR>
><BR>
><BR>
> Portable identifier only<BR>
> ------------------------<BR>
><BR>
> Include only the portable identifier in the request and response ([6]_<BR>
> and [7]_)::<BR>
><BR>
> openid.identity = <A HREF="http://my.portable.url/">http://my.portable.url/</A><BR>
><BR>
> In this proposal, the relying party does not use the IdP-specific fields<BR>
> that are available during discovery. The IdP must do discovery on the<BR>
> supplied identifier to determine what IdP-specific identifier has been<BR>
> specified.<BR>
><BR>
> This proposal simplifies relying party behavior. The messages that are<BR>
> passed have an obvious meaning and are easy to verify. The meaning of<BR>
> the "openid.identity" parameter is different from its meaning in the<BR>
> OpenID 1 protocol.<BR>
><BR>
><BR>
> References<BR>
> ==========<BR>
><BR>
> .. [1] "openid.delegate explained."<BR>
><BR>
> Brad Fitzpatrick, 3 October 2006<BR>
><BR>
> <A HREF="http://openid.net/pipermail/specs/2006-October/000182.html">http://openid.net/pipermail/specs/2006-October/000182.html</A><BR>
><BR>
><BR>
><BR>
> .. [2] "OpenID Authentication 1.1"<BR>
><BR>
> David Recordon, Brad Fitzpatrick, May 2006<BR>
><BR>
> <A HREF="http://openid.net/specs/openid-authentication-1_1.html">http://openid.net/specs/openid-authentication-1_1.html</A><BR>
><BR>
><BR>
><BR>
> .. [3] "[PROPOSAL] bare response / bare request"<BR>
><BR>
> Dick Hardt, 30 September 2006<BR>
><BR>
> <A HREF="http://openid.net/pipermail/specs/2006-September/000142.html">http://openid.net/pipermail/specs/2006-September/000142.html</A><BR>
><BR>
><BR>
><BR>
> .. [4] "cachability of delegated identity URLs"<BR>
><BR>
> Brad Fitzpatrick, 8 June 2006<BR>
><BR>
> <A HREF="http://lists.danga.com/pipermail/yadis/2005-June/000676.html">http://lists.danga.com/pipermail/yadis/2005-June/000676.html</A><BR>
><BR>
><BR>
><BR>
> .. [5] "Delegation Proposal Amendment"<BR>
><BR>
> Josh Hoyt, 6 October 2006<BR>
><BR>
> <A HREF="http://openid.net/pipermail/specs/2006-October/000269.html">http://openid.net/pipermail/specs/2006-October/000269.html</A><BR>
><BR>
><BR>
><BR>
> .. [6] "Proposal: IdP-supported delegation"<BR>
><BR>
> Josh Hoyt, 4 September 2006<BR>
><BR>
> <A HREF="http://openid.net/pipermail/specs/2006-September/000002.html">http://openid.net/pipermail/specs/2006-September/000002.html</A><BR>
><BR>
><BR>
><BR>
> .. [7] "PROPOSAL: OpenID Authentication Flow and how delegate fits in"<BR>
><BR>
> Dick Hardt, 9 October 2006<BR>
><BR>
> <A HREF="http://openid.net/pipermail/specs/2006-October/000310.html">http://openid.net/pipermail/specs/2006-October/000310.html</A><BR>
> _______________________________________________<BR>
> specs mailing list<BR>
> specs@openid.net<BR>
> <A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
><BR>
> _______________________________________________<BR>
> specs mailing list<BR>
> specs@openid.net<BR>
> <A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
<BR>
_______________________________________________<BR>
specs mailing list<BR>
specs@openid.net<BR>
<A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>