Re: Changing Terminology (was RE: IdP term in spec (was RE: Delegation discussion summary))
On 10/17/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I think we should be open (pun intended) to making changes. > > I really like the OpenID Provider -> shortens to OP, and is very > specific on what it does. > I have always found IdP to be a misnomer, and have mentioned it in > the past. > Now we have a great candidate, that provides more clarity, and it > should be a simple search and replace, and does not affect any code. While I am resistant to changing the specification without a compelling reason and strong consensus, I am open to coming up with a better term for this. The term IdP is already different from the OpenID 1 terminology (OpenID server), and no official specification has used it. If people agree on a better term, I won't resist. +0 on OpenID Provider (that is, better than IdP, but not better enough for me to defend if anyone objects) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Changing Terminology (was RE: IdP term in spec (was RE: Delegation discussion summary))
I think we should be open (pun intended) to making changes. I really like the OpenID Provider -> shortens to OP, and is very specific on what it does. I have always found IdP to be a misnomer, and have mentioned it in the past. Now we have a great candidate, that provides more clarity, and it should be a simple search and replace, and does not affect any code. Agreed the user friendly terms may take some more discussion. -- Dick On 15-Oct-06, at 11:58 AM, Recordon, David wrote: > I'd really prefer not to change terminology in the spec right now. > Seems like something we should have thought about four months ago > versus > a week after we said it would be final. There is nothing saying user > friendly terms that map to spec terms can't be created for the time > being. I do however think there will need to be healthy discussion > around them, that takes longer than a week. :) > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Drummond Reed > Sent: Saturday, October 14, 2006 11:43 PM > To: 'Johannes Ernst'; specs@openid.net > Subject: IdP term in spec (was RE: Delegation discussion summary) > > Suggestion: sidestep the issue completely and in the spec -- and > everywhere else -- just call it OpenID provider. It's a simple > concatenation of "OpenID" and "service provider", so everyone gets it, > but nobody will associate it with SAML or federation or anything else. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Johannes Ernst > Sent: Saturday, October 14, 2006 11:37 PM > To: specs@openid.net > Subject: Re: Delegation discussion summary > > We call it "identity host" at NetMesh. It's close enough to "identity > provider" so people understand it quickly, but does not have the > "provider" part to it (duh). > > On Oct 14, 2006, at 20:46, Scott Kveton wrote: > >>> I would propose that the term "Homesite" be used when prompting the >>> user to type in their IdP. I think the term "Identity Provider" is >>> overloaded and not user friendly. >> >> As per my last email I feel the same way about "identity provider" >> as well >> ... I agree with Dick; too overloaded and not user friendly. >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > Johannes Ernst > NetMesh Inc. > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP term in spec (was RE: Delegation discussion summary)
Drummond Reed wrote: > Suggestion: sidestep the issue completely and in the spec -- and everywhere > else -- just call it OpenID provider. It's a simple concatenation of > "OpenID" and "service provider", so everyone gets it, but nobody will > associate it with SAML or federation or anything else. > This seems sensible. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Dick Hardt wrote: > > I don't think we actually need to have a specific name when talking > to users. it is a site that supports OpenID. I agree. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
After re-reading this, other messages, and Dick's latest post, I strongly feel that we should make the change to support both the portable and IdP-specific identifiers within the protocol. The two most compelling reasons to me are that it has the fewest conceptual changes from OpenID Auth 1.x and the messages are very verbose and explicit in both the request and response. In addition, I believe it will grant greater flexibility for extensions being built atop the protocol as well as it provides useful features when working with XRIs. I appreciate the simplicity the one identifier approach presents, though dislike changing the concept behind the protocol this late in the drafting process. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 10:29 AM To: specs@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 respon
Changing Terminology (was RE: IdP term in spec (was RE: Delegation discussion summary))
I'd really prefer not to change terminology in the spec right now. Seems like something we should have thought about four months ago versus a week after we said it would be final. There is nothing saying user friendly terms that map to spec terms can't be created for the time being. I do however think there will need to be healthy discussion around them, that takes longer than a week. :) --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Saturday, October 14, 2006 11:43 PM To: 'Johannes Ernst'; specs@openid.net Subject: IdP term in spec (was RE: Delegation discussion summary) Suggestion: sidestep the issue completely and in the spec -- and everywhere else -- just call it OpenID provider. It's a simple concatenation of "OpenID" and "service provider", so everyone gets it, but nobody will associate it with SAML or federation or anything else. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Saturday, October 14, 2006 11:37 PM To: specs@openid.net Subject: Re: Delegation discussion summary We call it "identity host" at NetMesh. It's close enough to "identity provider" so people understand it quickly, but does not have the "provider" part to it (duh). On Oct 14, 2006, at 20:46, Scott Kveton wrote: >> I would propose that the term "Homesite" be used when prompting the >> user to type in their IdP. I think the term "Identity Provider" is >> overloaded and not user friendly. > > As per my last email I feel the same way about "identity provider" > as well > ... I agree with Dick; too overloaded and not user friendly. > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
IdP term in spec (was RE: Delegation discussion summary)
Suggestion: sidestep the issue completely and in the spec -- and everywhere else -- just call it OpenID provider. It's a simple concatenation of "OpenID" and "service provider", so everyone gets it, but nobody will associate it with SAML or federation or anything else. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Saturday, October 14, 2006 11:37 PM To: specs@openid.net Subject: Re: Delegation discussion summary We call it "identity host" at NetMesh. It's close enough to "identity provider" so people understand it quickly, but does not have the "provider" part to it (duh). On Oct 14, 2006, at 20:46, Scott Kveton wrote: >> I would propose that the term "Homesite" be used when prompting the >> user to type in their IdP. I think the term "Identity Provider" is >> overloaded and not user friendly. > > As per my last email I feel the same way about "identity provider" > as well > ... I agree with Dick; too overloaded and not user friendly. > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
We call it "identity host" at NetMesh. It's close enough to "identity provider" so people understand it quickly, but does not have the "provider" part to it (duh). On Oct 14, 2006, at 20:46, Scott Kveton wrote: I would propose that the term "Homesite" be used when prompting the user to type in their IdP. I think the term "Identity Provider" is overloaded and not user friendly. As per my last email I feel the same way about "identity provider" as well ... I agree with Dick; too overloaded and not user friendly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 14-Oct-06, at 8:45 PM, Scott Kveton wrote: >>> I kinda get "homesite", but I don't understand the thinking behind >>> "membersite": What is this site supposed to be a "member" of? >> >> It was a member of the network of sites running the protocol. > > "Membersite" sounds too much like you have to join some club to > participate. > I feel the same way about "homesite". I'm all for finding more > consumer-friendly terminology for this but I've yet to hear > anything that > rings true. Just to clarify, I was providing where "Membersite" came from, not promoting we use the term. > > In the case of http you have "web server" which is served up by a > "web site" > ... Instead of "http provider" and "http destination" ... Maybe we > need to > make this even simpler than we are? Could it be as simple (and I'm > not > really suggesting these) as "login server" and "login site"? > > What does the wider community think? How do LiveJournal users > refer to this > concept today? fwiw; I think RP is fine for the spec. I don't think we actually need to have a specific name when talking to users. it is a site that supports OpenID. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
>> I kinda get "homesite", but I don't understand the thinking behind >> "membersite": What is this site supposed to be a "member" of? > > It was a member of the network of sites running the protocol. "Membersite" sounds too much like you have to join some club to participate. I feel the same way about "homesite". I'm all for finding more consumer-friendly terminology for this but I've yet to hear anything that rings true. In the case of http you have "web server" which is served up by a "web site" ... Instead of "http provider" and "http destination" ... Maybe we need to make this even simpler than we are? Could it be as simple (and I'm not really suggesting these) as "login server" and "login site"? What does the wider community think? How do LiveJournal users refer to this concept today? - Scott ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
> I would propose that the term "Homesite" be used when prompting the > user to type in their IdP. I think the term "Identity Provider" is > overloaded and not user friendly. As per my last email I feel the same way about "identity provider" as well ... I agree with Dick; too overloaded and not user friendly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 12-Oct-06, at 5:44 PM, Gabe Wachob wrote: > *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. The accepting party ALWAYS accepts valid assertions from an IdP. ie. there is no choice in deciding if the user is a given identifier. The RP can decide if they want to let that identifier have access to any resources. I would propose that the term "Homesite" be used when prompting the user to type in their IdP. I think the term "Identity Provider" is overloaded and not user friendly. The industry understands the term IdP from Liberty / SAML protocols. The role of an IdP in OpenID is quite different then it is in a Federation model. In the Federation model, there is an explicit trust relationship between the IdP and the RP. This is not the case in OpenID. In OpenID, the IdP is really an agent for the user, it is NOT making claims about the user, it is allowing the user to easily prove they are a particular entity. This is a subtle, but important difference. The OpenID IdP is NOT making any claims about the user. The URL presented to the RP has no meaning except for the RP to know it was the same user it saw before, and to link the user to other claiims / data. I think it would benefit the spec to use a different name then IdP if for no other reason then to clarify this difference between how OpenID and Federation work. I would propose Identity Agent, as it is acting on behalf of the user, and covers both a hosted and client implementation. my $0.02 -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Would you elaborate on those use cases? The current draft does not support this. -- Dick On 13-Oct-06, at 8:52 AM, Granqvist, Hans wrote: > I can see potential use-cases where Alice doesn't want the > idp to know what her portable URL is. This would not work > if the protocol requires "both" as per below. Can it be > solved by sending a hash of the portable identifier? > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt >> Sent: Thursday, October 12, 2006 10:29 AM >> To: specs@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 chang
Re: Delegation discussion summary
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; specs@openid.net > 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; specs@openid.net > 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: specs@openid.net > > 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:
Re: Delegation discussion summary
On 13-Oct-06, at 12:04 AM, Martin Atkins wrote: > Graves, Michael wrote: >> >> >> 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. >> > > I kinda get "homesite", but I don't understand the thinking behind > "membersite": What is this site supposed to be a "member" of? It was a member of the network of sites running the protocol. > > Personally, I quite liked the old OpenID term "consumer". :) That term was confusing when talking to consumer sites.. Are you referring to the user "consumer" or the site "consumer". -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote: Marius wrote: I was suggesting that portability can be resolved between the user and the IdP. I cannot see how the protocol can help this by passing two identifiers. And if only the portable identifier is passed then there is no need to mention the IdP-specific identifier. >>> >>> Marius, see the analysis at >>> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now >>> updated >>> to include Josh's lastest thinking from >>> http://openid.net/pipermail/specs/2006-October/000357.html. >>> >>> In sum, not being able to send the IdP-specific identifier: a) >>> forces the >>> IdP to redo resolution, which is unnecessary and slows performance, >>> and >> >> Not necessarily. When you register with the IdP most likely you will >> claim all your portable identifiers with this IdP, so the IdP knows >> about them. > > With XRI i-name/i-number infrastructure that's neither practical nor > desirable. With XRIs, users control their own synonyms, i.e., I can > register > a delegated i-name within a specific community (for example, at > @example.community I could register @example.community*drummond) > and then > point that at my personal i-name (=drummond.reed) and the IdP for > =drummond.reed will never know -- and doesn't need to know. I could > go to > any RP and login in as @example.community*drummond, the RP will > resolve this > to =drummond.reed (through the way XRI resolution automatically > handles > reference processing -- let me know if you want more info about > this), and > end out storing the CanonicalID i-number for =drummond.reed (which is > =!F83.62B1.44F.2813). I don't see the point if hiding some of your portable identifiers (@example.community*drumond) from your IdP and at the same time disclose it to all the RPs you deal with. If you are using a portable identifier and you have an IdP then it seems normal to me to trust your IdP to know your portable identifier. I would be more nervous about all the RP knowing my IdP issued identifier. What is not practical about registering your portable identifier with your IdP? > >>> b) prevents the protocol from being stateless. >> >> How? The RP deals only with the portable identifier and this is the >> only thing the IdP sends back. Why do you need state? > > It follows from the above. But this is so important that I'm going > to send a > separate message about it. I can't see it, sorry. If the RP is indexing your account based on your i-number then it could send your i-number to your IdP for authentication, but it can also send your i-name. I don't think it matters. The IdP should know both and it can lookup your account with any of them. What state must the RP save? The RP has both your i-name and i-number as well (unless you are registering), so when the response comes back it can look you up with any. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
>>> Marius wrote: >>> >>> I was suggesting that portability can be resolved between the user >>> and >>> the IdP. I cannot see how the protocol can help this by passing two >>> identifiers. And if only the portable identifier is passed then >>> there is >>> no need to mention the IdP-specific identifier. >> >> Marius, see the analysis at >> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now >> updated >> to include Josh's lastest thinking from >> http://openid.net/pipermail/specs/2006-October/000357.html. >> >> In sum, not being able to send the IdP-specific identifier: a) >> forces the >> IdP to redo resolution, which is unnecessary and slows performance, >> and > >Not necessarily. When you register with the IdP most likely you will >claim all your portable identifiers with this IdP, so the IdP knows >about them. With XRI i-name/i-number infrastructure that's neither practical nor desirable. With XRIs, users control their own synonyms, i.e., I can register a delegated i-name within a specific community (for example, at @example.community I could register @example.community*drummond) and then point that at my personal i-name (=drummond.reed) and the IdP for =drummond.reed will never know -- and doesn't need to know. I could go to any RP and login in as @example.community*drummond, the RP will resolve this to =drummond.reed (through the way XRI resolution automatically handles reference processing -- let me know if you want more info about this), and end out storing the CanonicalID i-number for =drummond.reed (which is =!F83.62B1.44F.2813). >> b) prevents the protocol from being stateless. > >How? The RP deals only with the portable identifier and this is the >only thing the IdP sends back. Why do you need state? It follows from the above. But this is so important that I'm going to send a separate message about it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Makes sense, but do you *have* to put delegation info in an XRDS document? I'd like to think if I were to use an RP that I trust not to 'collude' with the IDP, there would be no reason for the IDP to know potential delegation? That gives me true identity portability and an open choice of IDPs. Once an IDP knows of and starts tracking my vanity identifier (bound to happen) I cannot easily give up that identifier. > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Friday, October 13, 2006 9:11 AM > To: Granqvist, Hans; 'Josh Hoyt'; specs@openid.net > Subject: RE: Delegation discussion summary > > Hans, > > This has come up a few times and the mapping between the > portable identifier and the IdP-specific identifier is > available in public XRDS documents. So there's no point in > trying to hide that information from the IdP -- and it may > even be misleading to suggest to end-users that they could > try to do so. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans > Sent: Friday, October 13, 2006 8:52 AM > To: Josh Hoyt; specs@openid.net > Subject: RE: Delegation discussion summary > > I can see potential use-cases where Alice doesn't want the > idp to know what her portable URL is. This would not work if > the protocol requires "both" as per below. Can it be solved > by sending a hash of the portable identifier? > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt > > Sent: Thursday, October 12, 2006 10:29 AM > > To: specs@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/ > >
Re: Delegation discussion summary
On 12-Oct-06, at 11:47 PM, Drummond Reed wrote: >> Marius wrote: >> >> I was suggesting that portability can be resolved between the user >> and >> the IdP. I cannot see how the protocol can help this by passing two >> identifiers. And if only the portable identifier is passed then >> there is >> no need to mention the IdP-specific identifier. > > Marius, see the analysis at > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now > updated > to include Josh's lastest thinking from > http://openid.net/pipermail/specs/2006-October/000357.html. > > In sum, not being able to send the IdP-specific identifier: a) > forces the > IdP to redo resolution, which is unnecessary and slows performance, > and Not necessarily. When you register with the IdP most likely you will claim all your portable identifiers with this IdP, so the IdP knows about them. > b) > prevents the protocol from being stateless. How? The RP deals only with the portable identifier and this is the only thing the IdP sends back. Why do you need state? Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
>> But I suggest we move that terminology discussion to the marketing list. >> > > What marketing list? http://lists.iwantmyopenid.org/mailman/listinfo/marketing. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Hans, This has come up a few times and the mapping between the portable identifier and the IdP-specific identifier is available in public XRDS documents. So there's no point in trying to hide that information from the IdP -- and it may even be misleading to suggest to end-users that they could try to do so. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Friday, October 13, 2006 8:52 AM To: Josh Hoyt; specs@openid.net Subject: RE: Delegation discussion summary I can see potential use-cases where Alice doesn't want the idp to know what her portable URL is. This would not work if the protocol requires "both" as per below. Can it be solved by sending a hash of the portable identifier? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt > Sent: Thursday, October 12, 2006 10:29 AM > To: specs@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
RE: Delegation discussion summary
I can see potential use-cases where Alice doesn't want the idp to know what her portable URL is. This would not work if the protocol requires "both" as per below. Can it be solved by sending a hash of the portable identifier? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt > Sent: Thursday, October 12, 2006 10:29 AM > To: specs@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. > >
RE: Delegation discussion summary
Title: RE: Delegation discussion summary +1 -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 10:46 PM Pacific Standard Time To: 'Josh Hoyt'; 'Marius Scurtescu' Cc: specs@openid.net Subject: RE: Delegation discussion summary +1 to Josh's point. IMHO identifier portability is "sacred". If anyone disagrees, please post, can we assume we have consensus on this? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 8:56 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Delegation discussion summary On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The protocol does not need to touch on IdP-specific identifiers (aka > delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Title: RE: Delegation discussion summary 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; specs@openid.net 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; specs@openid.net 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: specs@openid.net > 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: specs@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 &
Re: Delegation discussion summary
Drummond Reed wrote: > +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. > > > > But I suggest we move that terminology discussion to the marketing list. > What marketing list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Graves, Michael wrote: > > > 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. > I kinda get "homesite", but I don't understand the thinking behind "membersite": What is this site supposed to be a "member" of? Personally, I quite liked the old OpenID term "consumer". :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
>Marius wrote: > >I was suggesting that portability can be resolved between the user and >the IdP. I cannot see how the protocol can help this by passing two >identifiers. And if only the portable identifier is passed then there is >no need to mention the IdP-specific identifier. Marius, see the analysis at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now updated to include Josh's lastest thinking from http://openid.net/pipermail/specs/2006-October/000357.html. In sum, not being able to send the IdP-specific identifier: a) forces the IdP to redo resolution, which is unnecessary and slows performance, and b) prevents the protocol from being stateless. Have the RP send both the portable identifier and the IdP-specific identifier solves both problems. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
+1 sacred. On Thu, 12 Oct 2006, Drummond Reed wrote: > +1 to Josh's point. IMHO identifier portability is "sacred". If anyone > disagrees, please post, can we assume we have consensus on this? > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Josh Hoyt > Sent: Thursday, October 12, 2006 8:56 PM > To: Marius Scurtescu > Cc: specs@openid.net > Subject: Re: Delegation discussion summary > > On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > > The protocol does not need to touch on IdP-specific identifiers (aka > > delegated identifiers) at all IMO. > > If there is a specified mechanism that must be supported for using a > portable identifier, all IdPs will support it, so identifiers will > actually be portable. You'd have a very difficult time trying to get > people here to remove portable identifier support from the OpenID > protocol. > > Josh > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
On Thu, 2006-12-10 at 22:47 -0700, Drummond Reed wrote: > +1 to Josh's point. IMHO identifier portability is "sacred". If anyone > disagrees, please post, can we assume we have consensus on this? Yes, portability is sacred. I was suggesting that portability can be resolved between the user and the IdP. I cannot see how the protocol can help this by passing two identifiers. And if only the portable identifier is passed then there is no need to mention the IdP-specific identifier. Marius > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Josh Hoyt > Sent: Thursday, October 12, 2006 8:56 PM > To: Marius Scurtescu > Cc: specs@openid.net > Subject: Re: Delegation discussion summary > > On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > > The protocol does not need to touch on IdP-specific identifiers (aka > > delegated identifiers) at all IMO. > > If there is a specified mechanism that must be supported for using a > portable identifier, all IdPs will support it, so identifiers will > actually be portable. You'd have a very difficult time trying to get > people here to remove portable identifier support from the OpenID > protocol. > > Josh > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Title: RE: Delegation discussion summary +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. But I suggest we move that terminology discussion to the marketing list. =Drummond From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 12, 2006 9:04 PM To: Gabe Wachob; Graves, Michael; specs@openid.net 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; specs@openid.net 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: specs@openid.net > 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: specs@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
RE: Delegation discussion summary
+1 to Josh's point. IMHO identifier portability is "sacred". If anyone disagrees, please post, can we assume we have consensus on this? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 8:56 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Delegation discussion summary On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The protocol does not need to touch on IdP-specific identifiers (aka > delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Title: 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; specs@openid.net 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: specs@openid.net > 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: specs@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." > >
Re: Delegation discussion summary
On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The protocol does not need to touch on IdP-specific identifiers (aka > delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote: > 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). Not sure why are both identifiers needed? The RP cares only about the portable one, right? Is backwards compatibility the only reason? > > > Portable identifier only > This option makes sense to me. The protocol does not need to touch on IdP-specific identifiers (aka delegated identifiers) at all IMO. This is really an IdP implementation detail. The only important point seems to be the fact that identifiers are portable and IdPs should allow users to move them around. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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: specs@openid.net > 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: specs@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 an
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: specs@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
RE: Delegation discussion summary
+1. Josh, you did a great job of not just distilling it down to the essence,
but also nailing the right semantics for the underlying feature, which is
identifier portability.
Nice work.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 10:29 AM
To: specs@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
--
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 res
