Which vocabulary would you suggest we use? The Identity Gang, IETF, OASIS, Liberty, InfoCard?
btw: Philip, perhaps you can configure your GoodLink Wireless Handheld to send messages in plain text? ;-) On 13-Oct-06, at 7:35 AM, Hallam-Baker, Phillip wrote: > There is an established vocabulary, it should be used. > > Sent from my GoodLink Wireless Handheld (www.good.com) > > -----Original Message----- > From: Recordon, David [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 12, 2006 09:04 PM Pacific Standard Time > To: Gabe Wachob; Graves, Michael; firstname.lastname@example.org > Subject: RE: Delegation discussion summary > > I'd have to agree with Gabe about this, let's get it done! :) > > > -----Original Message----- > From: Gabe Wachob [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time > To: Graves, Michael; email@example.com > Subject: RE: Delegation discussion summary > > *If* we are going to open up the terminology discussion, for me the > terms > "authenticating party" (formerly the "IDP") and "accepting > party" (formerly > the "relying party") seem more descriptive. The authenticating > party issues > authentication assertions in the form of special HTTP request/ > responses with > the other party, who then accepts these assertions and decides > whether or > not they are good enough to let a user do something. > > As far as Dick's terminology, I'm not sure how "membersite" makes > sense > here. Perhaps it's a matter of history or perspective that I > haven't been > enlightened on. > > In any case, I'd rather get openid 2.0 out sooner than have a long > discussion on terminology, so I won't push this any further unless > someone > else really thinks its valuable. > > Gabe > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf > > Of Graves, Michael > > Sent: Thursday, October 12, 2006 5:00 PM > > To: firstname.lastname@example.org > > Subject: RE: Delegation discussion summary > > > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Josh Hoyt > > Sent: Thursday, October 12, 2006 12:29 PM > > To: email@example.com > > 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 _: > > > > * 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 _ 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") _. > > > > 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 (_ and > > _):: > > > > 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 > (_ > > and _):: > > > > 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 > > ========== > > > > ..  "openid.delegate explained." > > > > Brad Fitzpatrick, 3 October 2006 > > > > http://openid.net/pipermail/specs/2006-October/000182.html > > > > > > > > ..  "OpenID Authentication 1.1" > > > > David Recordon, Brad Fitzpatrick, May 2006 > > > > http://openid.net/specs/openid-authentication-1_1.html > > > > > > > > ..  "[PROPOSAL] bare response / bare request" > > > > Dick Hardt, 30 September 2006 > > > > http://openid.net/pipermail/specs/2006-September/000142.html > > > > > > > > ..  "cachability of delegated identity URLs" > > > > Brad Fitzpatrick, 8 June 2006 > > > > http://lists.danga.com/pipermail/yadis/2005-June/000676.html > > > > > > > > ..  "Delegation Proposal Amendment" > > > > Josh Hoyt, 6 October 2006 > > > > http://openid.net/pipermail/specs/2006-October/000269.html > > > > > > > > ..  "Proposal: IdP-supported delegation" > > > > Josh Hoyt, 4 September 2006 > > > > http://openid.net/pipermail/specs/2006-September/000002.html > > > > > > > > ..  "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 > > firstname.lastname@example.org > > http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > specs mailing list > > email@example.com > > http://openid.net/mailman/listinfo/specs > > _______________________________________________ > specs mailing list > firstname.lastname@example.org > http://openid.net/mailman/listinfo/specs > > > _______________________________________________ > specs mailing list > email@example.com > http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs