<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: Delegation discussion summary</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
h1
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:16.0pt;
font-family:Arial;
font-weight:bold;}
h2
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:14.0pt;
font-family:Arial;
font-weight:bold;
font-style:italic;}
h3
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:12.0pt;
font-family:Arial;
font-weight:bold;}
h4
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:10.0pt;
font-family:"Times New Roman";
font-weight:bold;
font-style:italic;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
{margin:0in;
margin-bottom:.0001pt;
border:none;
padding:0in;
font-size:10.0pt;
font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
{margin:0in;
margin-bottom:.0001pt;
border:none;
padding:0in;
font-size:10.0pt;
font-family:Arial;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
{margin-top:0in;
margin-right:0in;
margin-bottom:9.0pt;
margin-left:0in;
text-align:center;
font-size:16.0pt;
font-family:Arial;
font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
{margin-top:0in;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
p.MsoSubtitle, li.MsoSubtitle, div.MsoSubtitle
{margin-top:0in;
margin-right:0in;
margin-bottom:.25in;
margin-left:0in;
text-align:center;
font-size:12.0pt;
font-family:Arial;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
p.Quote, li.Quote, div.Quote
{margin-top:0in;
margin-right:.5in;
margin-bottom:6.0pt;
margin-left:.5in;
font-size:12.0pt;
font-family:"Times New Roman";
font-style:italic;}
p.Wiki, li.Wiki, div.Wiki
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.Graphic, li.Graphic, div.Graphic
{margin-top:0in;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
text-align:center;
font-size:10.0pt;
font-family:Arial;
font-style:italic;}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
/* Page Definitions */
@page
{mso-endnote-separator:url("cid:header.htm\@01C6EE51.C90B7210") es;
mso-endnote-continuation-separator:url("cid:header.htm\@01C6EE51.C90B7210") ecs;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:-132;
mso-list-type:simple;
mso-list-template-ids:-1328661930;}
@list l0:level1
{mso-level-tab-stop:1.25in;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l1
{mso-list-id:-131;
mso-list-type:simple;
mso-list-template-ids:-909054546;}
@list l1:level1
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
margin-left:1.0in;
text-indent:-.25in;}
@list l2
{mso-list-id:-130;
mso-list-type:simple;
mso-list-template-ids:531935922;}
@list l2:level1
{mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l3
{mso-list-id:-129;
mso-list-type:simple;
mso-list-template-ids:2046339550;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:-128;
mso-list-type:simple;
mso-list-template-ids:82112870;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.25in;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l5
{mso-list-id:-127;
mso-list-type:simple;
mso-list-template-ids:-1405587484;}
@list l5:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
margin-left:1.0in;
text-indent:-.25in;
font-family:Symbol;}
@list l6
{mso-list-id:-126;
mso-list-type:simple;
mso-list-template-ids:828961842;}
@list l6:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l7
{mso-list-id:-125;
mso-list-type:simple;
mso-list-template-ids:1053828088;}
@list l7:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l8
{mso-list-id:-120;
mso-list-type:simple;
mso-list-template-ids:-2021464228;}
@list l8:level1
{mso-level-tab-stop:.25in;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;}
@list l9
{mso-list-id:-119;
mso-list-type:simple;
mso-list-template-ids:445916746;}
@list l9:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.25in;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>+1 to getting it done. This area of
terminology is more a usability/marketing issue at this point. I agree we need to
converge on good, simple user-facing terms for describing OpenID in ways ordinary
Web users can easily understand. Although I have great respect for Dick &
Sxip’s pioneering work in this area, I don’t believe terms that use
the word “site” are the right metaphor, and the concept of “membersite”,
while good for the context Sxip originally used it, would send the wrong
message about OpenID.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>But I suggest we move that terminology
discussion to the marketing list.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>=Drummond <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
specs-bounces@openid.net [mailto:specs-bounces@openid.net] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Recordon, David<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, October 12, 2006
9:04 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Gabe Wachob; Graves, Michael;
specs@openid.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: Delegation discussion
summary</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>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 <st1:place w:st="on">Graves</st1:place>, 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></span></font><o:p></o:p></p>
</div>
</body>
</html>