RE: XRI confusion
Dick, you are right that there are usability challenges with i-numbers and XDI.org and the i-broker community is working to address them. Although persistent identifiers are used everywhere in local systems (directories, databases, object stores, etc.), and the concept has been around at the Internet level since the late '90s in the form of URNs (http://en.wikipedia.org/wiki/Uniform_Resource_Name), the need to integrate them into a digital identity layer is only just emerging. As with each new Internet layer, there's some stuff that just has to get figured out ;-) =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 9:26 AM To: Drummond Reed Cc: 'Recordon, David'; 'Martin Atkins'; specs@openid.net Subject: Re: XRI confusion That provides clarity on the process, thanks. If the user knows that their i-name has been changed, then when you write here: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal Summary of Motivations: ... 4. Enable RPs to take advantage of XRI CanonicalDs to protect End-Users from ever having their Portable Identifier reassigned (and thus their identity taken over). ... his is just in case they don't get alerted to their i-name being changed? btw: I have no idea what my i-numbers are, and it was not clear to me that I had them when I got them. I think there are some real usability issues here, but this is likely not the place to address those. :-) -- Dick On 19-Oct-06, at 8:12 AM, Drummond Reed wrote: > Exactly. An i-name being reassigned is very similar to a domain > name being > reassigned -- the previous owner is going to know they no longer > own it. > > For example, if you register blame.ca, you're going to receive > multiple > notices from your DNS registrar that you need to renew it, and if > you don't, > you know it is almost certain to be reassigned. The same is true > for i-name > registrants. > > With regard to i-numbers, every registrant is notified of their i- > number, > and their i-broker retains a record of the i-number. Because an i- > number is > NEVER reassigned, if a registrant chooses not to renew an i-name, they > ALWAYS have their i-number. > > Note that since the i-name and i-number are directly synonymous, > i.e., the > i-number resolves the same XRDS as the i-name, if a registrant know > their > i-number, they can always use it to login at any OpenID RP at which > they had > previously used any i-name synonym for that i-number. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Recordon, David > Sent: Thursday, October 19, 2006 4:09 AM > To: Dick Hardt; Martin Atkins > Cc: specs@openid.net > Subject: RE: XRI confusion > > How would Alice buy =foo when Bob already owns it? > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Thursday, October 19, 2006 3:58 AM > To: Martin Atkins > Cc: specs@openid.net > Subject: Re: XRI confusion > > > On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: > >> Dick Hardt wrote: >>> >>> How would a user ever learn what their CanonicalID is? >> >> The user doesn't need to know his i-number. The system discovers that >> for him. >> >>> If there Portable Identifier (i-name) is reassigned, then they will >>> be sent to an IdP for the new Canonical ID is, expecting credentials >>> from the new owner. The user will never make it back to the RP, and >>> they will have no easy way of proving they are the owner of the >>> CanonicalID. >> >> I don't really understand this paragraph, but when the i-name is >> reassigned it'll cease to point at the same XRDS and will thus not >> point at the IdP anymore - unless the new owner also has an account >> with that IdP, of course. But they have a different i-number, so the >> IdP can distinguish them. > > Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does > not > know this. Bob goes to an RP, enters =foo and gets sent somewhere he > cannot authenticate since =foo resolves somewhere else. > > Bob does not know what to do. =foo does not resolve to his i-number > any > more. How does he find out what it is so that he can get a his i- name > to point to it? > >> >>> Additionally, in the proposal, the i-name is not sent from the RP to >>> the IdP, so how does the IdP know which i-name to address the user >>> as? >> >> I would hope that an IdP, given that I've already established a >> relationship with it, can find something better to address me with >> than a URI. It should be calling me "Martin". > > Perhaps, although I would like my IdP to let me know which > Identifier I > am going to present to the RP. > > -- Dick > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
There have been several long threads in the past about using email addresses as OpenID identifiers. The conclusion each time has been to avoid it. I don't remember all the arguments, but among them are: * Privacy: the last thing many users want to give a website is their email address. * Reassignability: email addresses are not only reassignable, but for some domains, they are notoriously short-lived identifiers. * Non-portability: unless you own the top-level domain, they aren't portable. Food for thought... =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 6:46 PM To: specs@openid.net Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers In meeting with a large service provider this week, an issue around end user usability came up. The concern they expressed was that users are know how to enter usernames or email addresses to initiate the login process. While directed identity allows the user to enter "example.com", they feel that it still is a bit of a stretch at this time for any major deployment of OpenID. The proposal we came up with was within the spec describing what to do if someone were to enter "[EMAIL PROTECTED]" in a Relying Party's OpenID login form. The idea is that the RP splits the string on the "@" and then treats "example.com" as the IdP Identifier. This thus doesn't actually require any changes to the protocol itself. Any Relying Party can do this today, but they desire to see this as part of the specification itself so they wouldn't be doing anything special. Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal proposal, in case one, openid.identity would be set to "http://openid.net/identifier_select/2.0"; and then instead of openid.portable being empty, in this case "[EMAIL PROTECTED]" would be sent to the IdP. While not perfectly mapping to the definition of the openid.portable field, it doesn't seem like that much of a hack to do this. While I certainly am not looking to re-kindle the "Why a URI?" debate, http://[EMAIL PROTECTED] is also technically a valid URI. It is used in many cases by browsers to provide a username when making a web request. So while this is a little funky, I really think the increased usability offered by describing what a RP should do when a string like this is entered seems to outweigh the potential conceptual confusion. Thoughts? --David ___ 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: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Chris, I'm a little slow here, please bear with me. What's the reasoning for "without accessing other resources"? I am with you if you said "we can't ask a user agent to first do a MIME type of XRDS". But what's the difference between adding a new ad- hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP header? On Oct 19, 2006, at 19:44, Chris Drake wrote: Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: OpenID Login Page Link Tag
I initially agreed as well. But to play devil's advocate, the link-to-XRDS option could actually be pretty efficient. Any HTML page could simply advertise the availability of its Yadis XRDS file using an XRDS link in the header. Assuming that many or all of the pages on a site would be covered by the same XRDS file, the browser would only need to download it once to cover the entire site. The XRDS would expire (using the same cache control that XRI resolvers use) and be refreshed as needed. This is the architecture that P3P used (http://www.w3.org/TR/P3P/#ref_syntax). The XRDS file could provide discovery of multiple services representing the RP, not just the login page. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 8:24 PM To: Chris Drake; Johannes Ernst Cc: specs@openid.net Subject: RE: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenIDFormClarification (A.4)) I think I'd have to agree. Been thinking about this a lot recently and the overhead within Yadis seems unreasonable for a browser to perform against a RP. Technically the RP could not have anything in the HTML meaning the browser would have to do Yadis on every page view. I'd be inclined to use a link tag, at least for the time being, to discover relying parties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Thursday, October 19, 2006 10:45 PM To: Johannes Ernst Cc: specs@openid.net Subject: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID FormClarification (A.4)) Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> Martin, I agree with Dick, this is a fascinating idea. P3P had the >> same idea >> notion for a site advertising the location of the P3P privacy >> policy: it >> defined a standard HTML/XHTML link tag that could be put on any >> page of a >> site that told the browser where to locate the P3P policy document >> for the >> site (or for any portion of the site). >> >> http://www.w3.org/TR/P3P/#ref_syntax >> >> Are you proposing the same thing for OpenID login? >> >> (Kewl!) >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf >> Of Dick Hardt >> Sent: Thursday, October 19, 2006 12:53 AM >> To: Martin Atkins >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> >> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >> >>> Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. >>> >>> I think it'd be better to implement this as either a META or a LINK >>> element alongside a standard protocol for communicating with the >>> nominated URL. >>> >>> This way the site can declare on *all pages*, rather than on the >>> forms-based login page, that it accepts OpenID auth. This allows the >>> user to go to the RP's home page (or any other page) and click the >>> "OpenID Login" button on the browser's toolbar and have it work. >> >> That is an interesting idea. Would you like to take a stab at more >> specifics? >> >> -- Dick >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> 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: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID FormClarification (A.4))
I think I'd have to agree. Been thinking about this a lot recently and the overhead within Yadis seems unreasonable for a browser to perform against a RP. Technically the RP could not have anything in the HTML meaning the browser would have to do Yadis on every page view. I'd be inclined to use a link tag, at least for the time being, to discover relying parties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Thursday, October 19, 2006 10:45 PM To: Johannes Ernst Cc: specs@openid.net Subject: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID FormClarification (A.4)) Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> Martin, I agree with Dick, this is a fascinating idea. P3P had the >> same idea >> notion for a site advertising the location of the P3P privacy >> policy: it >> defined a standard HTML/XHTML link tag that could be put on any >> page of a >> site that told the browser where to locate the P3P policy document >> for the >> site (or for any portion of the site). >> >> http://www.w3.org/TR/P3P/#ref_syntax >> >> Are you proposing the same thing for OpenID login? >> >> (Kewl!) >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf >> Of Dick Hardt >> Sent: Thursday, October 19, 2006 12:53 AM >> To: Martin Atkins >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> >> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >> >>> Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. >>> >>> I think it'd be better to implement this as either a META or a LINK >>> element alongside a standard protocol for communicating with the >>> nominated URL. >>> >>> This way the site can declare on *all pages*, rather than on the >>> forms-based login page, that it accepts OpenID auth. This allows the >>> user to go to the RP's home page (or any other page) and click the >>> "OpenID Login" button on the browser's toolbar and have it work. >> >> That is an interesting idea. Would you like to take a stab at more >> specifics? >> >> -- Dick >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
On Oct 19, 2006, at 14:56, Josh Hoyt wrote: I'm in favor of keeping the OpenID Authentication Protocol specification as small as possible, with as few restrictions as possible to get useful behavior. Fully agree. The genius of HTTP and RSS and mass-market protocols like them was not in what they included, but what they left out. There are some lessons that we can learn here. The more we can reduce the scope, the more likely it is that we can develop a tight, usable specification that does not hold anyone back and is easy to implement. Exactly. There are a couple of different insights that are common to OpenID, SXIP, LID, and the myriad other URL-based single-sign-on solutions that are out there. I want to codify the things that we all agree on and allow innovation around the things that we do not. Hey, Josh, what happened, you are taking the words out of my mouth today!! ;-) I do not feel strongly about this particular issue, but I do feel strongly that if possible, we should REDUCE the scope as much as possible. Yes yes and more Yes. If there is a way to accomplish your goal without changing OpenID, then DON'T CHANGE OPENID. It's easy to put stuff in the next revision, but it's hard to take stuff out. OpenID has been successful because its scope was intentionally extremely narrow. Lets keep it that way. Absolutely. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> Martin, I agree with Dick, this is a fascinating idea. P3P had the >> same idea >> notion for a site advertising the location of the P3P privacy >> policy: it >> defined a standard HTML/XHTML link tag that could be put on any >> page of a >> site that told the browser where to locate the P3P policy document >> for the >> site (or for any portion of the site). >> >> http://www.w3.org/TR/P3P/#ref_syntax >> >> Are you proposing the same thing for OpenID login? >> >> (Kewl!) >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf >> Of Dick Hardt >> Sent: Thursday, October 19, 2006 12:53 AM >> To: Martin Atkins >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> >> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >> >>> Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. >>> >>> I think it'd be better to implement this as either a META or a LINK >>> element alongside a standard protocol for communicating with the >>> nominated URL. >>> >>> This way the site can declare on *all pages*, rather than on the >>> forms-based login page, that it accepts OpenID auth. This allows the >>> user to go to the RP's home page (or any other page) and click the >>> "OpenID Login" button on the browser's toolbar and have it work. >> >> That is an interesting idea. Would you like to take a stab at more >> specifics? >> >> -- Dick >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID FormClarification (A.4))
In this case the link tag just points to the RP's OpenID login page, which enables a browser to have a button that initiates OpenID login at the site (provided you've been there before). However the RP could have its own Yadis XRDS file, and the link tag could point to that to discover this same info. That would work even when you're not at the site. Is that what you mean? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Thursday, October 19, 2006 5:34 PM To: specs@openid.net Subject: Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID FormClarification (A.4)) Isn't this a case where the Yadis infrastructure should be used instead of Yet Another Link Tag? On Oct 19, 2006, at 8:21, Drummond Reed wrote: > Martin, I agree with Dick, this is a fascinating idea. P3P had the > same idea > notion for a site advertising the location of the P3P privacy > policy: it > defined a standard HTML/XHTML link tag that could be put on any > page of a > site that told the browser where to locate the P3P policy document > for the > site (or for any portion of the site). > > http://www.w3.org/TR/P3P/#ref_syntax > > Are you proposing the same thing for OpenID login? > > (Kewl!) > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Dick Hardt > Sent: Thursday, October 19, 2006 12:53 AM > To: Martin Atkins > Cc: specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > > On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: > >> Dick Hardt wrote: >>> >>> In order for the RUA to detect that a site supports OpenID, it >>> sees a >>> form with a single input with a "name" of openid_identiifier. The >>> RUA >>> can then look at the action and post the data directly to the RP. >>> >> >> I think it'd be better to implement this as either a META or a LINK >> element alongside a standard protocol for communicating with the >> nominated URL. >> >> This way the site can declare on *all pages*, rather than on the >> forms-based login page, that it accepts OpenID auth. This allows the >> user to go to the RP's home page (or any other page) and click the >> "OpenID Login" button on the browser's toolbar and have it work. > > That is an interesting idea. Would you like to take a stab at more > specifics? > > -- Dick > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ > 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Back at the dawn of the Web I made the mistake of thinking that the address bar was the place you type a URI. We now know that it is the place you type a search term that may be a URL in canonical form or may be a domain name or may be a search term to be thrown at a search engine. It was one of the principle innovations in Netscape over Mosaic. Any identifier can be represented as a URI. Just stick SCHEME: in front. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David > Sent: Thursday, October 19, 2006 9:46 PM > To: specs@openid.net > Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > In meeting with a large service provider this week, an issue > around end user usability came up. The concern they > expressed was that users are know how to enter usernames or > email addresses to initiate the login process. While > directed identity allows the user to enter "example.com", > they feel that it still is a bit of a stretch at this time > for any major deployment of OpenID. > > The proposal we came up with was within the spec describing > what to do if someone were to enter "[EMAIL PROTECTED]" in a > Relying Party's OpenID login form. The idea is that the RP > splits the string on the "@" and then treats "example.com" as > the IdP Identifier. This thus doesn't actually require any > changes to the protocol itself. Any Relying Party can do > this today, but they desire to see this as part of the > specification itself so they wouldn't be doing anything special. > > Within the > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal > proposal, in case one, openid.identity would be set to > "http://openid.net/identifier_select/2.0"; and then instead of > openid.portable being empty, in this case "[EMAIL PROTECTED]" > would be sent to the IdP. While not perfectly mapping to the > definition of the openid.portable field, it doesn't seem like > that much of a hack to do this. > > While I certainly am not looking to re-kindle the "Why a > URI?" debate, http://[EMAIL PROTECTED] is also technically a > valid URI. It is used in many cases by browsers to provide a > username when making a web request. > > So while this is a little funky, I really think the increased > usability offered by describing what a RP should do when a > string like this is entered seems to outweigh the potential > conceptual confusion. > > Thoughts? > > --David > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
In meeting with a large service provider this week, an issue around end user usability came up. The concern they expressed was that users are know how to enter usernames or email addresses to initiate the login process. While directed identity allows the user to enter "example.com", they feel that it still is a bit of a stretch at this time for any major deployment of OpenID. The proposal we came up with was within the spec describing what to do if someone were to enter "[EMAIL PROTECTED]" in a Relying Party's OpenID login form. The idea is that the RP splits the string on the "@" and then treats "example.com" as the IdP Identifier. This thus doesn't actually require any changes to the protocol itself. Any Relying Party can do this today, but they desire to see this as part of the specification itself so they wouldn't be doing anything special. Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal proposal, in case one, openid.identity would be set to "http://openid.net/identifier_select/2.0"; and then instead of openid.portable being empty, in this case "[EMAIL PROTECTED]" would be sent to the IdP. While not perfectly mapping to the definition of the openid.portable field, it doesn't seem like that much of a hack to do this. While I certainly am not looking to re-kindle the "Why a URI?" debate, http://[EMAIL PROTECTED] is also technically a valid URI. It is used in many cases by browsers to provide a username when making a web request. So while this is a little funky, I really think the increased usability offered by describing what a RP should do when a string like this is entered seems to outweigh the potential conceptual confusion. Thoughts? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Isn't this a case where the Yadis infrastructure should be used instead of Yet Another Link Tag? On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > If you want that to happen, then you have to spec out that the RP is > verifying the IdP-specific identifier and portable identifier binding > when it receives it. That is not in the current proposal. If that is not in there, then the proposal *is* worse than one-identifier and needs to be fixed. I guess I need to read it more closely. The primary reason that I prefer two-identifier is that the relying party is more strict about what it's accepting. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 11:18 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> reread the attack. The portable identifier and the IdP do >> match. > > In fact, this makes me think of an attack that *would* succeed if the > IdP-specific identifer was not in the response: > > when she has control, she initiates a log-in, but traps the response > (it's valid, but never gets submitted to the relying party). The trapped response would only be valid for a short period of time since the RP checks that the response is not stale by looking at the nonce, otherwise this attack could be used in many other places. > > After you regain control, she has a valid response for your identifier > and you have no way to invalidate it. If the IdP-specific identifier > was in the response, changing that would invalidate the response. If you want that to happen, then you have to spec out that the RP is verifying the IdP-specific identifier and portable identifier binding when it receives it. That is not in the current proposal. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Recordon, David wrote: Combining this with the fact that there is no viable way to enforce sections 8.1 or A.4 being MUSTs, I do not believe that they should be changed from SHOULDs. The only conceivable way I could see of enforcing something like this is telling a Relying Party that they cannot use OpenID Authentication if they don't follow these non-essential markup requirements; that is not something I am willing to do. "Be liberal in what you accept, be conservative in what you send." Enforcement is not a requirement. Having said that, I think I agree with you: SHOULD is probably strong enough to ensure that those who can, will. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote: > I think it's there for convenience because no practices document > existed when that was inserted. I think Josh was considering removing > it anyway, though. I'm in favor of keeping the OpenID Authentication Protocol specification as small as possible, with as few restrictions as possible to get useful behavior. I think this kind of thing could go in another, companion specification, so that if people want to experiment, they can, without having to re-invent the parts that work. This is similar to my response to Dick in which I said that ideally identifier discovery and verification would be in another specification. The more we can reduce the scope, the more likely it is that we can develop a tight, usable specification that does not hold anyone back and is easy to implement. There are a couple of different insights that are common to OpenID, SXIP, LID, and the myriad other URL-based single-sign-on solutions that are out there. I want to codify the things that we all agree on and allow innovation around the things that we do not. I do not feel strongly about this particular issue, but I do feel strongly that if possible, we should REDUCE the scope as much as possible. If there is a way to accomplish your goal without changing OpenID, then DON'T CHANGE OPENID. It's easy to put stuff in the next revision, but it's hard to take stuff out. OpenID has been successful because its scope was intentionally extremely narrow. Lets keep it that way. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL: OpenID Form Clarification (A.4)
Yes, section 8.1 is legacy from OpenID Auth 1.x as no best practices document existed at the time, nor does one exist today separate from the spec. If one did exist, I'd imagine that sections 8.1 and A.4 would reference it saying Relying Parties SHOULD follow it. Looking at ftp://ftp.isi.edu/in-notes/rfc2119.txt: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. To me, that is the correct level of force for all of section 8.1 and A.4. The RFC goes on to say: > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for In no case does the non-existence of anything described in 8.1 or A.4 cause the protocol, as described by the specification, to no longer interoperate, between End Users, Relying Parties, and Identity Providers, nor does it limit behavior as described by the specification. This would certainly be different if this was an OpenID Rich Client specification. I'm certainly not saying it should actively try to limit development atop it, but we must be pragmatic or we'll end up shooting ourselves in the foot. Combining this with the fact that there is no viable way to enforce sections 8.1 or A.4 being MUSTs, I do not believe that they should be changed from SHOULDs. The only conceivable way I could see of enforcing something like this is telling a Relying Party that they cannot use OpenID Authentication if they don't follow these non-essential markup requirements; that is not something I am willing to do. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Thursday, October 19, 2006 5:37 PM To: Pete Rowley Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # A procedural point: If it is out of scope why is 8.1, and in # particular that line, in the spec? I submit that it evidently _is_ # in scope since it is there. I think it's there for convenience because no practices document existed when that was inserted. I think Josh was considering removing it anyway, though. -- Jonathan Daugherty JanRain, 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
# A procedural point: If it is out of scope why is 8.1, and in # particular that line, in the spec? I submit that it evidently _is_ # in scope since it is there. I think it's there for convenience because no practices document existed when that was inserted. I think Josh was considering removing it anyway, though. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Jonathan Daugherty wrote: # This is true only if you never consider use cases for your protocol # which cover usability. That would be unwise. I don't think I know of # a protocol that was developed without regard to how it would be # used. I have said before that the form element name proposal is a good one, and I don't think anyone else disagrees that having a consistent name would be good for usability. Regardless, this design choice is out of scope for the OpenID 2.0 authentication spec. A procedural point: If it is out of scope why is 8.1, and in particular that line, in the spec? I submit that it evidently _is_ in scope since it is there. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
# This is true only if you never consider use cases for your protocol # which cover usability. That would be unwise. I don't think I know of # a protocol that was developed without regard to how it would be # used. I have said before that the form element name proposal is a good one, and I don't think anyone else disagrees that having a consistent name would be good for usability. Regardless, this design choice is out of scope for the OpenID 2.0 authentication spec. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Jonathan Daugherty wrote: # we already know that browser-chrome plugins will be supporting # OpenID - as soon as an RP picks some other field name, he'll get a # flood of complains from users who can't log in to his site. And that has nothing to do with the *protocol*. Put it in a Best Practices document instead. Or create an OpenID Rich Client specification. This is true only if you never consider use cases for your protocol which cover usability. That would be unwise. I don't think I know of a protocol that was developed without regard to how it would be used. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Josh Hoyt <[EMAIL PROTECTED]> wrote: > when she has control Sorry that I didn't put this all in one message, but: I think it's worthwhile to be aware of what might happen in scenarios where your identifier has been stolen, but it should not have much bearing on which proposal gets accepted, since the attacker will have been able to inflict much greater harm elsewhere. I doubt that the protocol can offer much protection if someone actually gets control of your identifier. For instance, some RPs will offer a way to transition an account from one identifier to another (for e.g. domain names expiring). The attacker can just transition those accounts to an identifier of hers. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: rename Identity Provider to OpenID Provider
Martin Atkins wrote: Granqvist, Hans wrote: Why not simply call the idp "idp", and prefix it "OpenID idp" if context or clarification is needed, all referencing an OpenID spec def of "OpenID idp"? While I guess I agree with your objection, I don't like the redundant "ID" in "OpenID IdP". It makes it awkward to say out loud, if nothing else. Perhaps we can say its full name is "OpenID Authentication Provider", but shorten it to just "OpenID Provider" when the context is obvious? (or just call it an AP and have done with it?) I was thinking OpenID Authenticator since you don't really provide authentication, it's something you do. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 19-Oct-06, at 10:23 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I like your proposal. I would tweak the name: >> >> http://my.rp.com/openid/blah.cgi";> > > This is what Yadis was designed for. Since OpenID already requires > Yadis, this should be implemented as a Service entry in the Yadis > document for any page on which you want that information. Just to clarify then, you would suggest that the RP include a meta tag with a reference to the RPs Yadis document? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport
Andy, I think it is incredibly useful in showing the technology needed to help protect users with systems like this. I'd love to see it as part of the Heraldry project, you are already a committer, assuming you'd be willing to contribute it. --David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, October 18, 2006 11:44 PMTo: Digital Identity ExchangeCc: Digital Identity Exchange; specs@openid.net; [EMAIL PROTECTED]Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport I'd be interested to hear if people think the ph-off plugin is useful or not If not why not? If people think it's useful then I will happily extend it and make it more usable and I will put it into whatever open source project would like to house it. I built it as a proof of concept that it _could_ be done... Now the question of _should_ it be done :-) http://chile.ootao.com/phoff/ Andy DaleooTao, Inc.Phone: 877-213-7935Fax: 877-213-7935i-name: =Andy.Dalehttp://xri.net/=andy.dale***If you don't have an i-name yet use this link to visit one of our partners and buy one: http://www.ezibroker.net/partners.html*** Chris Drake <[EMAIL PROTECTED]> 10/18/2006 07:20 PM Please respond toDigital Identity Exchange To Scott Kveton <[EMAIL PROTECTED]> cc specs@openid.net, [EMAIL PROTECTED], Mike Glover <[EMAIL PROTECTED]>, Digital Identity Exchange Subject Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support Hi Scott,All solutions for client-based MITM and phishing prevention can easilybe built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.We can then leave these people to build their tools and protectionhowsoever they like, safe in the knowledge that when it's *done*,there will be a range of new plugins that will immediately work withall OpenID 2.0 enabled sites - and best of all - it does not have tohold up the OpenID 2.0 development in the meantime.The only thing we need to give to these tools is a way to get thelogin process started - that is - OpenIDHTTPAuth: the downloadedplugin needs to be able to get an entry point for the OpenID CGI codeon the web site.---Here is a copy of my vote to include the above proposal, whichcontains more info abut it too:Hi,Why's this proposal "depreciated" ?( http://www.lifewiki.net/openid/OpenIDProposals )I'm casting my vote here:+1 to [PROPOSAL] bare response / bare requestBesides the listed uses, it also allows IdPs to layer privacy anddelegation easily on top of OpenID, as well as permitting cool futurefeatures (like letting a user change something at their IdP, and havethat change be "pushed out" to all relevant RPs).This is a small and simple to implement "hook" which I believe will bethe dominating bit of OpenID protocol use in future.Alternatively - if we can standardize a way for the OpenIDHTTPAuthproposed extension to discover the RP's OpenID "entry point" [so as toreliably eliminate the "optional" first step proposed herehttp://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a goodworking alterative way to accommodate the "bare response" part that weneed.So...+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- ---Kind Regards,Chris DrakeThursday, October 19, 2006, 6:07:08 AM:>> It is vulnerable to a man in the middle attack - the RP, instead of>> redirecting to the IdP redirects to itself or some other site in>> cahoots, then proxies the conversation between the user and the IdP>> thereby compromising the users (global) credentials as they pass through.SK> Right, we've known about this for quite some time unfortunately there hasn'tSK> be a particularly easy solution to it and I classify this as one of thoseSK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't doSK> anything about it I just think the right solution that mixesSK> ease-of-implementation and user need hasn't been found yet.>> There really needs to be user-agent support to avoid that - either>> something CardSpace like, or browser plugin that only ever presents a>> pre-authenticated user.SK> I think we're headed in this direction. However, we have to crawl before weSK> can walk. At least solving a big chunk
Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support
I'd be interested to hear if people think the ph-off plugin is useful or not If not why not? If people think it's useful then I will happily extend it and make it more usable and I will put it into whatever open source project would like to house it. I built it as a proof of concept that it _could_ be done... Now the question of _should_ it be done :-) http://chile.ootao.com/phoff/ Andy Dale ooTao, Inc. Phone: 877-213-7935 Fax: 877-213-7935 i-name: =Andy.Dale http://xri.net/=andy.dale *** If you don't have an i-name yet use this link to visit one of our partners and buy one: http://www.ezibroker.net/partners.html *** Chris Drake <[EMAIL PROTECTED]> 10/18/2006 07:20 PM Please respond to Digital Identity Exchange To Scott Kveton <[EMAIL PROTECTED]> cc specs@openid.net, [EMAIL PROTECTED], Mike Glover <[EMAIL PROTECTED]>, Digital Identity Exchange Subject Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support Hi Scott, All solutions for client-based MITM and phishing prevention can easily be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal. We can then leave these people to build their tools and protection howsoever they like, safe in the knowledge that when it's *done*, there will be a range of new plugins that will immediately work with all OpenID 2.0 enabled sites - and best of all - it does not have to hold up the OpenID 2.0 development in the meantime. The only thing we need to give to these tools is a way to get the login process started - that is - OpenIDHTTPAuth: the downloaded plugin needs to be able to get an entry point for the OpenID CGI code on the web site. --- Here is a copy of my vote to include the above proposal, which contains more info abut it too: Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- --- Kind Regards, Chris Drake Thursday, October 19, 2006, 6:07:08 AM: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass through. SK> Right, we've known about this for quite some time unfortunately there hasn't SK> be a particularly easy solution to it and I classify this as one of those SK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't do SK> anything about it I just think the right solution that mixes SK> ease-of-implementation and user need hasn't been found yet. >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. SK> I think we're headed in this direction. However, we have to crawl before we SK> can walk. At least solving a big chunk of the use cases, getting some SK> momentum behind the platform and solving a specific problem for users SK> *today* is better than trying to build the perfect tool. We can talk and SK> talk on these lists but we really don't know how users are going to use this SK> stuff (or abuse it for that matter) until its out there and working in the SK> wild. SK> I can't emphasize more the fact that with every passing day that we don't SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific SK> user problems that are solved in the existing specification. SK> - Scott SK> ___ SK> general mailing list SK> [EMAIL PROTECTED] SK> http://openid.net/mailman/listinfo/general ___ dix mailing list dix@ietf.org https://ww
Re: [PROPOSAL] bare response / bare request
Dick Hardt wrote: > Motivating Use Case > > The IdP would like to allow the user to click a link on the IdP to > login to an RP. This requires a bare response to be able to be sent. > A Trusted Party, acting as an RP would like to store a value at the > IdP, but does not need the IdP to send the user back, a bare request > is needed. > > > Proposed Implementation > --- > bare request: if the openid.return_to parameter is missing or blank, > then the IdP will not send the user back to the RP > > bare response: sending a bare response is valid (not sure we need to > do anything more then say it is OK to do) It sounds to me that this "bare response" thing is just a special case of the "rich clients" we're discussing right now in a separate thread. The IdP is just using redirects to make a dumb browser act like a rich client. If rich clients were implemented in the way I've been promoting [1], IdPs would then be able to make use of the same mechanism. [1] http://openid.net/pipermail/specs/2006-October/000596.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > reread the attack. The portable identifier and the IdP do match. In fact, this makes me think of an attack that *would* succeed if the IdP-specific identifer was not in the response: when she has control, she initiates a log-in, but traps the response (it's valid, but never gets submitted to the relying party). After you regain control, she has a valid response for your identifier and you have no way to invalidate it. If the IdP-specific identifier was in the response, changing that would invalidate the response. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 10:40 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> My head is a little moreclear this morning, so let me clarify. >> >> My key point is that the IdP cannot trust the discovery done by the >> RP since what the request is unsigned and may have been modified >> between the RP and the IdP. > > The IdP shouldn't trust the message from RP. It doesn't need to trust > the message from the RP. Trusting the message from the RP would be a > mistake, because the relying party is not the authority for the > information provided. Signing the request has no effect on this issue. > > The IdP does not need to trust the portable identifier given. An RP > will not honor a claim about an identifier whose discovery information > does not match, since it *must* check to make sure it matches *in any > case*. Even if bad information was sent in the request *and the IdP > did not verify it*, the relying party will reject the (bogus) > assertion from the IdP because it does not match the discovered > information for the portable identifier. > > Your attack fails. reread the attack. The portable identifier and the IdP do match. > >> I was showing a potential attack vector where even though I think I >> have resolved the issue, it is not resolved. > > I can't figure out what this means. Who has resolved which issue? > and how? Sorry. I was referring to the attack. I have discovered that someone has hacked my blog (not an uncommon thing for some people) and have fixed it. The IdP has a stale map between the portable identifier and the malicious user's IdP-specific identifier, so even though I have recovered control of my blog, the malicious user can still pretend to be my portable identifier. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Which is still described in the latest draft, see http://openid.net/specs/openid-authentication-2_0-10.html#anchor42. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 19, 2006 1:24 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I like your proposal. I would tweak the name: > > http://my.rp.com/openid/blah.cgi";> This is what Yadis was designed for. Since OpenID already requires Yadis, this should be implemented as a Service entry in the Yadis document for any page on which you want that information. 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: PROPOSAL: rename Identity Provider to OpenID Provider
Granqvist, Hans wrote: > > Why not simply call the idp "idp", and prefix it "OpenID idp" > if context or clarification is needed, all referencing an > OpenID spec def of "OpenID idp"? > While I guess I agree with your objection, I don't like the redundant "ID" in "OpenID IdP". It makes it awkward to say out loud, if nothing else. Perhaps we can say its full name is "OpenID Authentication Provider", but shorten it to just "OpenID Provider" when the context is obvious? (or just call it an AP and have done with it?) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Drummond Reed wrote: > Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea > notion for a site advertising the location of the P3P privacy policy: it > defined a standard HTML/XHTML link tag that could be put on any page of a > site that told the browser where to locate the P3P policy document for the > site (or for any portion of the site). > > http://www.w3.org/TR/P3P/#ref_syntax > > Are you proposing the same thing for OpenID login? > Yes, that is the idea. I don't have time at this moment to write out a full proposal, so I'll just quickly summarize/ramble... Right then. On any page of the RP, they can write: http://www.mysite.com/openid"; /> [1] Now, if we make to that URL the same kind of request that a return_to URL expects to receive, the RP has almost everything it needs to get going with the request. Unless I've missed something, all it's missing is the public identifier the user has selected — what he would have entered into the form under normal circumstances. So we define an extra parameter oirp.identifier to carry that. Now with only minimal changes to the RP we have an interface that a clever client can use to login without forms. This just leaves the rich client to IdP communication. As I noted in a similar message on the other mailing list, this doesn't actually *need* to be a standard at all — the IdP could just issue a plugin which works only with that IdP. That's a lot of duplication of work, however. So what we need is another standard protocol by which the rich client can request a signature; the input argument is the IdP Token, or claimed_identity as the auth spec calls it. Since there has thus far been no communication between RP and IdP, "dumb mode" must be used; the IdP returns a signature and a handle to the rich client, which it then sends on to openid.rp as described above. The RP can then resolve the presented identity to find the IdP and validate the signature. This is really just a variation on the HTTP auth proposal. The differences are: * Rich client passes args to RP via query string rather than WWW-Authenticate header. * We actually specify a protocol for the communication between the rich client and the IdP, unlike my HTTP auth proposal which left that out of scope. Note that HTTP auth can potentially make use of this protocol too. * There's a separation between the URL where you discover the OpenID support and the URL where you make use of it. With HTTP auth, you just make a request and get back a 401 Unauthorized, or you just "know" the URL ahead of time. Really, the above could use the HTTP auth protocol to talk to the RP's endpoint, but I selected the above because it makes the required RP changes much simpler — just support an extra argument in your return_to handler. [1] This is just an example. We'd probably use Yadis in practice, since that would give us versioning for free and the ability to add other services. However, this would make implementation marginally harder for plugin developers as they now need to do more than just grovel around in the DOM of each page as it is loaded, and it'll create an extra overhead for any page that has an X-Yadis-Location, regardless of whether this particular service is listed. I'll leave it to others to debate whether to use Yadis, a custom LINK REL, or some META element. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRI confusion
Dick Hardt wrote: > > Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does > not know this. Bob goes to an RP, enters =foo and gets sent somewhere > he cannot authenticate since =foo resolves somewhere else. > > Bob does not know what to do. =foo does not resolve to his i-number > any more. How does he find out what it is so that he can get a his i- > name to point to it? > This is up to the registrar (i-broker, I think?). Presumably they'll let Bob know that he's let his registration lapse and that it can now be registered by someone else. Bob will be unable to reclaim the i-name unless Alice is willing to release it to him. Bob's i-broker presumably knows what Bob's i-number is and so if he does re-obtain it they will point it on his behalf. This is just general administration stuff, out of scope of the protocols. It's not much different in principle to a hosting provider that sells you a domain name and a bundled website. You don't need to know the IP address of their web server because they set up that mapping for you. If you let your registration of the domain lapse, they'll presumably let you know. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > Just to clarify then, you would suggest that the RP include a meta > tag with a reference to the RPs Yadis document? Any URL that wants to have a login URL associated with it can use whichever of the mechanisms provided by Yadis to point to a Yadis document with the login information in it. Including a meta tag that points to a single, site-wide XRDS document is one valid instance of that. I would expect that most Web apps would prefer to send the "XRDS-Location" header if possible, and also support content-negotiation to obtain the XRDS document. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > My head is a little moreclear this morning, so let me clarify. > > My key point is that the IdP cannot trust the discovery done by the > RP since what the request is unsigned and may have been modified > between the RP and the IdP. The IdP shouldn't trust the message from RP. It doesn't need to trust the message from the RP. Trusting the message from the RP would be a mistake, because the relying party is not the authority for the information provided. Signing the request has no effect on this issue. The IdP does not need to trust the portable identifier given. An RP will not honor a claim about an identifier whose discovery information does not match, since it *must* check to make sure it matches *in any case*. Even if bad information was sent in the request *and the IdP did not verify it*, the relying party will reject the (bogus) assertion from the IdP because it does not match the discovered information for the portable identifier. Your attack fails. > I was showing a potential attack vector where even though I think I > have resolved the issue, it is not resolved. I can't figure out what this means. Who has resolved which issue? and how? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
Dick Hardt wrote: My key point is that the IdP cannot trust the discovery done by the RP since what the request is unsigned and may have been modified between the RP and the IdP. Yep. Though trusting RPs for _anything_ is a bad idea. Users necessarily need to trust IdP's, the IdP's should protect them from the RPs. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > Your attack fails. > > reread the attack. The portable identifier and the IdP do match. No the identifiers do not. It did at one time, but not at the time that the attack takes place. While she has control of your blog, she has control of your identifier. If you regain control (change it back), the RP will no longer let her log in, regardless of whether she can get an assertion from the RP. The relying party needs to verify the discovered information when it gets a response. Your attack fails. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I like your proposal. I would tweak the name: > > http://my.rp.com/openid/blah.cgi";> This is what Yadis was designed for. Since OpenID already requires Yadis, this should be implemented as a Service entry in the Yadis document for any page on which you want that information. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: RP identifier
Dick Hardt wrote: > > Agreed that it is desirable to have multiple RP endpoints for an RP. > Does openid.realm then uniquely identify an RP? ie. no other RP will > use the same Realm? > I'd say that if two endpoints are within the same realm that they are by definition part of the same RP. This does raise the question of what to do when one realm exists inside another, but I suppose the most obvious answer is to select the most specific of the available options — that is, the one with the least "wildcardy-ness"[1]. Someone probably should define precisely how the specificity of realms works if it isn't in the spec already. [1] Now *that* is a good word! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: rename Identity Provider to OpenID Provider
On 19-Oct-06, at 9:55 AM, Granqvist, Hans wrote: > -1 > > "OpenID provider" is too vague and makes little sense. What > is provided? OpenID? How do you provide a specification? The OpenID. The thing that iwantmyopenid.com is working to give the user! If you have a different, generic name for the identifier, then we could use that. > > Or... > > If I am a browser with built in OpenID 2.0 authn support, > am I then not 'providing OpenID' to the user, so in effect > I am too an "OpenID provider", but now as a client? yes, exactly ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP assisting user to present previous identifier
Does anyone NOT want to support these scenarios? On 19-Oct-06, at 8:40 AM, Drummond Reed wrote: > I agree the scenarios Dick proposes here make sense. However if the > IdP can > change an identifier parameter, it should be openid.portable, > since: a) > that's the one the RP is going to store, and b) that's the one the > IdP MUST > return with a different value anyway in the directed identity use > case (case > 1 at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). > > We need to carefully consider the security implications, but I > believe they > are covered by a simple rule: if the IdP returns a DIFFERENT > openid.portable > parameter value than the one sent by the RP, then the RP MUST > verify that > the IdP is authoritative for the new openid.portable identifier by > doing > discovery. If the RP finds that a different IdP is authoritiative, > it MUST > reinitiate login with that IdP. > > (Which essentially amounts to an "OpenID login redirect".) > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Dick Hardt > Sent: Thursday, October 19, 2006 12:19 AM > To: specs@openid.net > Subject: IdP assisting user to present previous identifier > > I expect I will have a number of OpenIDs, as well as lots of directed > identities. I would like my IdP to keep track of which identity I use > at what RP. I may forget which public identifier I used at a site, > and type in the wrong one, and end up creating a new account and be > confused. I may have used a directed identity, and forget and type in > a public one, and then once again be creating a new account and be > confused. > > I would like my IdP to be able to suggest which identifier I want to > be in situations where I am using a different one from what I used in > the past. This means that the following from: > > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal > > IdP Rules for Identifier Parameters > > 1. IdP MUST ALWAYS return the value of openid.identity sent by RP. > > > would need to be changed so that the IdP can send a different > identifier then what was sent by the RP. > > -- Dick > ___ > 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: Two Identifiers - no caching advantage
My head is a little moreclear this morning, so let me clarify. My key point is that the IdP cannot trust the discovery done by the RP since what the request is unsigned and may have been modified between the RP and the IdP. I was showing a potential attack vector where even though I think I have resolved the issue, it is not resolved. -- Dick On 19-Oct-06, at 8:27 AM, Drummond Reed wrote: > I don't have time this second to go into more detail, but a quick > high-level > observation about Dick's Cached Discovery Attack: if your blog (or the > target page of any portable OpenID identifier) can be hacked, > you've already > lost your identity. All the hacker has to do is point the link tag > at their > own XRDS file and their off to the races. They can spoof your portable > OpenID identifier anywhere and everywhere you've used it, because > from the > standpoint of an RP, all it looks like is that you've changed IdPs... > > ...which of course is the whole point of portable OpenID > identifiers ;-) > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Dick Hardt > Sent: Thursday, October 19, 2006 12:13 AM > To: specs@openid.net > Subject: Two Identifiers - no caching advantage > > After reading though: > > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal > > I have concluded there is no caching advantage > > Specifically if you look at these two sections: > > > > RP Rules for Identifier Parameters > > Case 3: URL WITH IdP-Specific Identifier > > If Portable Identifier is a URL that DOES map to a IdP-Specific > Identifier, the values are: > > openid.identity = IdP-Specific Identifier > openid.portable = Portable Identifier > > IdP Rules for Identifier Parameters > > 3. If openid.identity = Portable Identifier that IdP does not > recognize, IdP MUST to discovery to obtain the IdP-Specific > Identifier. > > > > I conclude the following: > > *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier > and the Portable Identifier, so the RP sending both does may save the > IdP effort, but leaves a potential security issue. (see Cached > Discovery Attack below) > > *** the RP is using the Portable Identifier to identify the user, and > does nothing with the IdP-Specific Identifier, so there is no value > in the IdP sending both the Portable Identifier and the IdP-Specific > Identifier. Note that the RP either maintains state that the IdP is > bound to the Portable Identifier, or needs to do discover again. > > => The only reason for the RP to send the openid.identity to the IdP > is for backward compatibility with OpenID 1.x, similarly the only > reason for the IdP to send openid.identity to the RP is for OpenID > 1.x compatibility. There are no caching advantages. > > > > Cached Discovery Attack: > > A malicious user takes over my blog, opens an account at the same IdP > I use, inserts her IdP-Specific Identifier into my blog, and then > uses my blog URL. The IdP will see the blog URL and the IdP-Specific > Identifier don't match, do discovery on the blog URL, and then map my > blog URL (Portable Identifier) to her IdP-Specific Identifier. > > I discover that my blog URL has been hacked, and restore my IdP- > Specific Identifier. > > The malicious user goes to an RP, that providing her blog URL that > contains her IdP-Specific Identifier. She captures the message from > the RP, and changes the Portable Identifier to be my blog URL. The > IdP still thinks the Portable Identifier is mapped to her IdP- > Specific Identifier, and allows her to login to the RP as me. > > Solutions: > > 1) The IdP does discovery on the blog URL each time it is used. > 2) The IdP has complex logic to ... > > > ___ > 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: PROPOSAL: OpenID Form Clarification (A.4)
# we already know that browser-chrome plugins will be supporting # OpenID - as soon as an RP picks some other field name, he'll get a # flood of complains from users who can't log in to his site. And that has nothing to do with the *protocol*. Put it in a Best Practices document instead. Or create an OpenID Rich Client specification. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hey Chris, I like your proposal. I would tweak the name: http://my.rp.com/openid/blah.cgi";> Perhaps you can write it up and put a link on David's proposal wiki at: http://www.lifewiki.net/openid/OpenIDProposals I think I chewed through my proposal quota a while ago. ;-) -- Dick On 19-Oct-06, at 9:45 AM, Chris Drake wrote: > Hi David, > > Besides other DIX lurkers, we know for sure that Dick, Andy, and > myself are all building "chrome" extensions and/or rich-clients, so I > think you'll have no problems getting a "consensus" on this. > > My personal vote is for something like this:- > http://my.rp.com/openid/blah.cgi";> > either on the page with the login , or even every page on an > OpenID 2.0 enabled site. > > Browser agents and IdP's alike can use this information not just for > facilitating chrome etc, but also for privacy protection, *true* > single-signon, identifier selection, and a range of other things. > > Kind Regards, > Chris Drake > > > Thursday, October 19, 2006, 3:33:31 PM, you wrote: > > RD> This isn't worth me standing in the way. If you can get general > RD> consensus of those actively participating in the spec process > then I > RD> won't stand in the way of the community, in fact if this > happens I'd be > RD> happy to make the change to the spec. > > RD> There seems to be other ways to deal with this though, since > you're > RD> going to have to deal with the case of a RP not having this > markup. > RD> Giving the rich client an icon like the SSL padlock which > lights up when > RD> the user visits a RP that supports it and then the user > clicking it, or > RD> submitting the form, to start the flow seems like one viable entry > RD> point. To deal with a RP with no markup, the user would not > see the > RD> icon illuminate, position their cursor within the OpenID field, > and then > RD> click the icon which would indicate to the client that this > actually is > RD> a RP as well as let it capture the field within the DOM to > interact > RD> with. > > RD> --David > > RD> -Original Message- > RD> From: Dick Hardt [mailto:[EMAIL PROTECTED] > RD> Sent: Thursday, October 19, 2006 1:04 AM > RD> To: Recordon, David > RD> Cc: Jonathan Daugherty; specs@openid.net > RD> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > RD> Unfortunate that was not captured in the notes. When I said > that we > RD> needed tags to detect, there was consensus that was not a problem. > > RD> We are building a rich client. It will be available in the not- > too- > RD> distant-future. > > RD> We are working on what it will take to implement, and have > figured out > RD> how to make it all work, but need to detect that the site is an > RP. > > RD> Lack of clarity on what MUST happen adding many, many lines of > code to > RD> the early browsers. It would be good to not repeat that mistake. > > RD> I really don't see how making this a MUST instead of SHOULD > would slow > RD> specs or implementation as I am sure most people will just do > it anyway. > > RD> I've made my case and will let it rest. > > RD> -- Dick > > > RD> On 18-Oct-06, at 9:55 PM, Recordon, David wrote: > >>> Here are notes from the June meeting, which we all looked over >>> before >>> I sent them out. All I see in relation to rich clients is that DIX >>> supported them, though I don't remember any decision being made >>> that a > >>> requirement of OpenID Authentication was every relying party >>> enabling >>> the use of a rich client. >>> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >>> >>> I don't think this should be a MUST as it adds one more requirement >>> which we can't even effectively enforce. If/when rich client >>> software > >>> gets out there and is being actively used, I'd be much more inclined >>> to change this to a MUST. Right now I think we should just get this >>> spec done, get people using it, and see what develops and thus >>> how it >>> needs to evolve! >>> >>> --David >>> >>> -Original Message- >>> From: Dick Hardt [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, October 19, 2006 12:44 AM >>> To: Recordon, David >>> Cc: Jonathan Daugherty; specs@openid.net >>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>> >>> That is news to me that supporting Rich Clients is not a >>> requirement. >>> Rich client support was a discussion point back in July at the >>> meeting > >>> in VeriSign, and there was consensus to support Rich Clients then >>> >>> Would you point me to the list of requirements so that we can all >>> get >>> on the same page on what they are? >>> >>> I am really confused why you would not want this to be a MUST. >>> >>> -- Dick >>> >>> On 18-Oct-06, at 9:35 PM, Recordon, David wrote: >>> The spec is an authentication spec which does not discuss rich clients >>> anywhere. As I've said, and I'd think others would agree, it is not a requirement of the spec to enable rich clien
RE: PROPOSAL: rename Identity Provider to OpenID Provider
-1 "OpenID provider" is too vague and makes little sense. What is provided? OpenID? How do you provide a specification? Or... If I am a browser with built in OpenID 2.0 authn support, am I then not 'providing OpenID' to the user, so in effect I am too an "OpenID provider", but now as a client? Why not simply call the idp "idp", and prefix it "OpenID idp" if context or clarification is needed, all referencing an OpenID spec def of "OpenID idp"? Hans > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt > Sent: Wednesday, October 18, 2006 10:05 PM > To: specs@openid.net > Subject: PROPOSAL: rename Identity Provider to OpenID Provider > > (writing this up so that it can go in David's proposal wiki :-) > > Motivation: > > * Liberty specifications use the term Identity Provider (IdP) > to refer to a site that provides any kind of identity > assertion about the user, and this term has come to have that > general meaning in the market. Since OpenID IdP only asserts > that a user has an OpenID, this leads to confusion about what > an OpenID IdP actually does. > > * When asserting parties are introduced into the OpenID > specifications at a later time, they will also be IdPs, but > will need a different name since they are not doing what an > IdP does in OpenID. > > Proposal: > > Rename Identity Provider to OpenID Provider in the spec > > Pros: > + clarity on what the IdP in the protocol does > + will provide clarity in future > > Cons: > - some simple search and replace needs to be done on the spec > - people in the OpenID Community are used to using the term IdP > > > ___ > 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[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi David, Besides other DIX lurkers, we know for sure that Dick, Andy, and myself are all building "chrome" extensions and/or rich-clients, so I think you'll have no problems getting a "consensus" on this. My personal vote is for something like this:- http://my.rp.com/openid/blah.cgi";> either on the page with the login , or even every page on an OpenID 2.0 enabled site. Browser agents and IdP's alike can use this information not just for facilitating chrome etc, but also for privacy protection, *true* single-signon, identifier selection, and a range of other things. Kind Regards, Chris Drake Thursday, October 19, 2006, 3:33:31 PM, you wrote: RD> This isn't worth me standing in the way. If you can get general RD> consensus of those actively participating in the spec process then I RD> won't stand in the way of the community, in fact if this happens I'd be RD> happy to make the change to the spec. RD> There seems to be other ways to deal with this though, since you're RD> going to have to deal with the case of a RP not having this markup. RD> Giving the rich client an icon like the SSL padlock which lights up when RD> the user visits a RP that supports it and then the user clicking it, or RD> submitting the form, to start the flow seems like one viable entry RD> point. To deal with a RP with no markup, the user would not see the RD> icon illuminate, position their cursor within the OpenID field, and then RD> click the icon which would indicate to the client that this actually is RD> a RP as well as let it capture the field within the DOM to interact RD> with. RD> --David RD> -Original Message- RD> From: Dick Hardt [mailto:[EMAIL PROTECTED] RD> Sent: Thursday, October 19, 2006 1:04 AM RD> To: Recordon, David RD> Cc: Jonathan Daugherty; specs@openid.net RD> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) RD> Unfortunate that was not captured in the notes. When I said that we RD> needed tags to detect, there was consensus that was not a problem. RD> We are building a rich client. It will be available in the not-too- RD> distant-future. RD> We are working on what it will take to implement, and have figured out RD> how to make it all work, but need to detect that the site is an RP. RD> Lack of clarity on what MUST happen adding many, many lines of code to RD> the early browsers. It would be good to not repeat that mistake. RD> I really don't see how making this a MUST instead of SHOULD would slow RD> specs or implementation as I am sure most people will just do it anyway. RD> I've made my case and will let it rest. RD> -- Dick RD> On 18-Oct-06, at 9:55 PM, Recordon, David wrote: >> Here are notes from the June meeting, which we all looked over before >> I sent them out. All I see in relation to rich clients is that DIX >> supported them, though I don't remember any decision being made that a >> requirement of OpenID Authentication was every relying party enabling >> the use of a rich client. >> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >> >> I don't think this should be a MUST as it adds one more requirement >> which we can't even effectively enforce. If/when rich client software >> gets out there and is being actively used, I'd be much more inclined >> to change this to a MUST. Right now I think we should just get this >> spec done, get people using it, and see what develops and thus how it >> needs to evolve! >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:44 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> That is news to me that supporting Rich Clients is not a requirement. >> Rich client support was a discussion point back in July at the meeting >> in VeriSign, and there was consensus to support Rich Clients then >> >> Would you point me to the list of requirements so that we can all get >> on the same page on what they are? >> >> I am really confused why you would not want this to be a MUST. >> >> -- Dick >> >> On 18-Oct-06, at 9:35 PM, Recordon, David wrote: >> >>> The spec is an authentication spec which does not discuss rich >>> clients >> >>> anywhere. >>> >>> As I've said, and I'd think others would agree, it is not a >>> requirement of the spec to enable rich clients. It is great to have >>> them and great for it to enable them. Whether the spec says this is >>> a >> >>> MUST or not you'll still have to tell users that not all relying >>> parties will support the use of the rich client. It seems >>> presumptuous for us to think that by making this a MUST we'll be able >>> to force every relying party into doing it, when to them not doing it >>> doesn't actually break anything within the authentication protocol. >>> >>> Six months from now this may be a different story, but for now I >>> guess >> >>> we just don't see eye to eye on the issue. :-\ >>> >>> --David
Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi Jonathan, I vote for MUST. The opinion of unenforcability isn't a justification for SHOULD, and I disagree with that opinion anyhow: we already know that browser-chrome plugins will be supporting OpenID - as soon as an RP picks some other field name, he'll get a flood of complains from users who can't log in to his site. Kind Regards, Chris Drake Thursday, October 19, 2006, 5:27:02 PM, you wrote: JD> # Why SHOULD rather then MUST? [1] JD> # JD> # What valid reason is there for an RP to not have that field name? JD> The simple reason is that one can't enforce a MUST in this case. (And JD> even if one ammends the spec to make the field name a prerequisite for JD> OpenID, I question whether that is a good design choice.) JD> I agree that it would be extremely useful to have a consistent form JD> field name for just the reasons you cited, and the current spec JD> reflects that. If the spec is the place one would put preferences, JD> then they should be RECOMMENDEDs or SHOULDs: not MUSTs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP assisting user to present previous identifier
On 19-Oct-06, at 8:40 AM, Drummond Reed wrote: > I agree the scenarios Dick proposes here make sense. However if the > IdP can > change an identifier parameter, it should be openid.portable, > since: a) > that's the one the RP is going to store, and b) that's the one the > IdP MUST > return with a different value anyway in the directed identity use > case (case > 1 at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). > > We need to carefully consider the security implications, but I > believe they > are covered by a simple rule: if the IdP returns a DIFFERENT > openid.portable > parameter value than the one sent by the RP, then the RP MUST > verify that > the IdP is authoritative for the new openid.portable identifier by > doing > discovery. If the RP finds that a different IdP is authoritiative, Which is what happens in directed identity. > it MUST > reinitiate login with that IdP. > > (Which essentially amounts to an "OpenID login redirect".) Not sure that should be automatic. I think the user should be given the choice about what to do then. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRI confusion
That provides clarity on the process, thanks. If the user knows that their i-name has been changed, then when you write here: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal Summary of Motivations: ... 4. Enable RPs to take advantage of XRI CanonicalDs to protect End-Users from ever having their Portable Identifier reassigned (and thus their identity taken over). ... his is just in case they don't get alerted to their i-name being changed? btw: I have no idea what my i-numbers are, and it was not clear to me that I had them when I got them. I think there are some real usability issues here, but this is likely not the place to address those. :-) -- Dick On 19-Oct-06, at 8:12 AM, Drummond Reed wrote: > Exactly. An i-name being reassigned is very similar to a domain > name being > reassigned -- the previous owner is going to know they no longer > own it. > > For example, if you register blame.ca, you're going to receive > multiple > notices from your DNS registrar that you need to renew it, and if > you don't, > you know it is almost certain to be reassigned. The same is true > for i-name > registrants. > > With regard to i-numbers, every registrant is notified of their i- > number, > and their i-broker retains a record of the i-number. Because an i- > number is > NEVER reassigned, if a registrant chooses not to renew an i-name, they > ALWAYS have their i-number. > > Note that since the i-name and i-number are directly synonymous, > i.e., the > i-number resolves the same XRDS as the i-name, if a registrant know > their > i-number, they can always use it to login at any OpenID RP at which > they had > previously used any i-name synonym for that i-number. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Recordon, David > Sent: Thursday, October 19, 2006 4:09 AM > To: Dick Hardt; Martin Atkins > Cc: specs@openid.net > Subject: RE: XRI confusion > > How would Alice buy =foo when Bob already owns it? > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Thursday, October 19, 2006 3:58 AM > To: Martin Atkins > Cc: specs@openid.net > Subject: Re: XRI confusion > > > On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: > >> Dick Hardt wrote: >>> >>> How would a user ever learn what their CanonicalID is? >> >> The user doesn't need to know his i-number. The system discovers that >> for him. >> >>> If there Portable Identifier (i-name) is reassigned, then they will >>> be sent to an IdP for the new Canonical ID is, expecting credentials >>> from the new owner. The user will never make it back to the RP, and >>> they will have no easy way of proving they are the owner of the >>> CanonicalID. >> >> I don't really understand this paragraph, but when the i-name is >> reassigned it'll cease to point at the same XRDS and will thus not >> point at the IdP anymore - unless the new owner also has an account >> with that IdP, of course. But they have a different i-number, so the >> IdP can distinguish them. > > Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does > not > know this. Bob goes to an RP, enters =foo and gets sent somewhere he > cannot authenticate since =foo resolves somewhere else. > > Bob does not know what to do. =foo does not resolve to his i-number > any > more. How does he find out what it is so that he can get a his i- name > to point to it? > >> >>> Additionally, in the proposal, the i-name is not sent from the RP to >>> the IdP, so how does the IdP know which i-name to address the user >>> as? >> >> I would hope that an IdP, given that I've already established a >> relationship with it, can find something better to address me with >> than a URI. It should be calling me "Martin". > > Perhaps, although I would like my IdP to let me know which > Identifier I > am going to present to the RP. > > -- Dick > ___ > 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 assisting user to present previous identifier
I agree the scenarios Dick proposes here make sense. However if the IdP can change an identifier parameter, it should be openid.portable, since: a) that's the one the RP is going to store, and b) that's the one the IdP MUST return with a different value anyway in the directed identity use case (case 1 at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). We need to carefully consider the security implications, but I believe they are covered by a simple rule: if the IdP returns a DIFFERENT openid.portable parameter value than the one sent by the RP, then the RP MUST verify that the IdP is authoritative for the new openid.portable identifier by doing discovery. If the RP finds that a different IdP is authoritiative, it MUST reinitiate login with that IdP. (Which essentially amounts to an "OpenID login redirect".) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:19 AM To: specs@openid.net Subject: IdP assisting user to present previous identifier I expect I will have a number of OpenIDs, as well as lots of directed identities. I would like my IdP to keep track of which identity I use at what RP. I may forget which public identifier I used at a site, and type in the wrong one, and end up creating a new account and be confused. I may have used a directed identity, and forget and type in a public one, and then once again be creating a new account and be confused. I would like my IdP to be able to suggest which identifier I want to be in situations where I am using a different one from what I used in the past. This means that the following from: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal IdP Rules for Identifier Parameters 1. IdP MUST ALWAYS return the value of openid.identity sent by RP. would need to be changed so that the IdP can send a different identifier then what was sent by the RP. -- Dick ___ 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: Two Identifiers - no caching advantage
I don't have time this second to go into more detail, but a quick high-level observation about Dick's Cached Discovery Attack: if your blog (or the target page of any portable OpenID identifier) can be hacked, you've already lost your identity. All the hacker has to do is point the link tag at their own XRDS file and their off to the races. They can spoof your portable OpenID identifier anywhere and everywhere you've used it, because from the standpoint of an RP, all it looks like is that you've changed IdPs... ...which of course is the whole point of portable OpenID identifiers ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:13 AM To: specs@openid.net Subject: Two Identifiers - no caching advantage After reading though: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal I have concluded there is no caching advantage Specifically if you look at these two sections: RP Rules for Identifier Parameters Case 3: URL WITH IdP-Specific Identifier If Portable Identifier is a URL that DOES map to a IdP-Specific Identifier, the values are: openid.identity = IdP-Specific Identifier openid.portable = Portable Identifier IdP Rules for Identifier Parameters 3. If openid.identity = Portable Identifier that IdP does not recognize, IdP MUST to discovery to obtain the IdP-Specific Identifier. I conclude the following: *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier and the Portable Identifier, so the RP sending both does may save the IdP effort, but leaves a potential security issue. (see Cached Discovery Attack below) *** the RP is using the Portable Identifier to identify the user, and does nothing with the IdP-Specific Identifier, so there is no value in the IdP sending both the Portable Identifier and the IdP-Specific Identifier. Note that the RP either maintains state that the IdP is bound to the Portable Identifier, or needs to do discover again. => The only reason for the RP to send the openid.identity to the IdP is for backward compatibility with OpenID 1.x, similarly the only reason for the IdP to send openid.identity to the RP is for OpenID 1.x compatibility. There are no caching advantages. Cached Discovery Attack: A malicious user takes over my blog, opens an account at the same IdP I use, inserts her IdP-Specific Identifier into my blog, and then uses my blog URL. The IdP will see the blog URL and the IdP-Specific Identifier don't match, do discovery on the blog URL, and then map my blog URL (Portable Identifier) to her IdP-Specific Identifier. I discover that my blog URL has been hacked, and restore my IdP- Specific Identifier. The malicious user goes to an RP, that providing her blog URL that contains her IdP-Specific Identifier. She captures the message from the RP, and changes the Portable Identifier to be my blog URL. The IdP still thinks the Portable Identifier is mapped to her IdP- Specific Identifier, and allows her to login to the RP as me. Solutions: 1) The IdP does discovery on the blog URL each time it is used. 2) The IdP has complex logic to ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> In order for the RUA to detect that a site supports OpenID, it sees a >> form with a single input with a "name" of openid_identiifier. The RUA >> can then look at the action and post the data directly to the RP. >> > > I think it'd be better to implement this as either a META or a LINK > element alongside a standard protocol for communicating with the > nominated URL. > > This way the site can declare on *all pages*, rather than on the > forms-based login page, that it accepts OpenID auth. This allows the > user to go to the RP's home page (or any other page) and click the > "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ 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: XRI confusion
Exactly. An i-name being reassigned is very similar to a domain name being reassigned -- the previous owner is going to know they no longer own it. For example, if you register blame.ca, you're going to receive multiple notices from your DNS registrar that you need to renew it, and if you don't, you know it is almost certain to be reassigned. The same is true for i-name registrants. With regard to i-numbers, every registrant is notified of their i-number, and their i-broker retains a record of the i-number. Because an i-number is NEVER reassigned, if a registrant chooses not to renew an i-name, they ALWAYS have their i-number. Note that since the i-name and i-number are directly synonymous, i.e., the i-number resolves the same XRDS as the i-name, if a registrant know their i-number, they can always use it to login at any OpenID RP at which they had previously used any i-name synonym for that i-number. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 4:09 AM To: Dick Hardt; Martin Atkins Cc: specs@openid.net Subject: RE: XRI confusion How would Alice buy =foo when Bob already owns it? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 3:58 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: XRI confusion On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> How would a user ever learn what their CanonicalID is? > > The user doesn't need to know his i-number. The system discovers that > for him. > >> If there Portable Identifier (i-name) is reassigned, then they will >> be sent to an IdP for the new Canonical ID is, expecting credentials >> from the new owner. The user will never make it back to the RP, and >> they will have no easy way of proving they are the owner of the >> CanonicalID. > > I don't really understand this paragraph, but when the i-name is > reassigned it'll cease to point at the same XRDS and will thus not > point at the IdP anymore - unless the new owner also has an account > with that IdP, of course. But they have a different i-number, so the > IdP can distinguish them. Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does not know this. Bob goes to an RP, enters =foo and gets sent somewhere he cannot authenticate since =foo resolves somewhere else. Bob does not know what to do. =foo does not resolve to his i-number any more. How does he find out what it is so that he can get a his i- name to point to it? > >> Additionally, in the proposal, the i-name is not sent from the RP to >> the IdP, so how does the IdP know which i-name to address the user >> as? > > I would hope that an IdP, given that I've already established a > relationship with it, can find something better to address me with > than a URI. It should be calling me "Martin". Perhaps, although I would like my IdP to let me know which Identifier I am going to present to the RP. -- Dick ___ 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: Pre-Draft 11
Hi Prasanta, That section shows as an example how to encode the two keys, mode and error, in both Key-Value Form encoding as well as x-www-urlencoded encoding as POST and GET arguments. Thus when Key-Value encoding you delimit between keys and values with a colon, though in url encoding you use an equals sign just like other query string arguments. What can we do to make that section more clear? Thanks, --David -Original Message- From: Prasanta Behera [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 11:37 AM To: Recordon, David; specs@openid.net Subject: RE: Pre-Draft 11 The example in section 4.1.3 does not match. mode:error error:This is an example message openid.mode=error&openid.err Should it be openid.mode:error? (Ouch!) I think "=" instead of ":" is better. Thanks, /Prasanta -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Tuesday, October 17, 2006 3:24 AM To: specs@openid.net Subject: Pre-Draft 11 Over the past few days I've gone through and done a lot of cleanup on the draft to add clarity and reword awkward paragraphs. No actual content changes should have been made between Draft 10 and this draft. Figure this is a better benchmark when looking at the remaining proposals than Draft 10. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] bare response / bare request
Hi Chris, It seems Dick marked it as deprecated when he made a new proposal (http://openid.net/pipermail/specs/2006-October/000430.html). I'd love to see the OpenIDHTTPAuth proposal standardized. I think it would enable a lot of interesting things. Want to lead that with Mart? I'm happy to help you guys get it in the XML format and up on the website. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Tuesday, October 17, 2006 2:50 PM To: specs@openid.net Subject: [PROPOSAL] bare response / bare request Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- http://my.rp.com/openid/blah.cgi";> Kind Regards, Chris Drake Saturday, October 7, 2006, 9:52:36 AM, you wrote: KT> On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote: >> Let me play the dumb customer here and say: >> >> * A whole lot of real-world users would love OpenID-enabled bookmarks. >> * A whole lot of websites would love to offer them. >> * A whole lot of IdPs would love to provide them. KT> Okay Customer, if both websites and IdPs would love it, is it okay KT> if it's something that websites + IdPs can layer on top of the core? KT> If some sites chose not to, and the IdP said "login bookmark not KT> available for this site", would that be okay? KT> ___ KT> specs mailing list KT> specs@openid.net KT> 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: HTTP response code
I SVN blame Carl and Josh. :P 379 23 9/28/2006 7:33:55 PM j3h A server receiving a properly formed request MUST send a 380 23 9/28/2006 7:33:55 PM j3h response with an HTTP status code of 200. 381 89/5/2006 4:33:52 PM chowells 382 89/5/2006 4:33:52 PM chowells 383 89/5/2006 4:33:52 PM chowells 384 89/5/2006 4:33:52 PM chowells 385 89/5/2006 4:33:52 PM chowells 386 89/5/2006 4:33:52 PM chowells If a request is malformed or contains invalid arguments, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Bufu Sent: Wednesday, October 18, 2006 2:26 PM To: specs@openid.net Subject: HTTP response code I was reviewing draft 10 to make sure our implementation complies with all MUSTs, and I believe I've spotted an issue with the wording in sections 5.1.2.1 and 5.1.2.2, specifically: "5.1.2.1. Successful Responses A server receiving a properly formed request MUST send a response with an HTTP status code of 200. 5.1.2.2. Error Responses If a request is malformed or contains invalid arguments, the server MUST send a response with a status code of 400." Given that any message is either properly formed or malformed (and nothing beside), the two MUSTs above cannot be satisfied in the case of a properly formed message, but containing invalid arguments. Draft 9 had the wording as "valid request" vs "malformed or containing invalid arguments" (sections 6.1.2.1 and 6.1.2.2). Thanks, Johnny ___ 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: XRI confusion
How would Alice buy =foo when Bob already owns it? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 3:58 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: XRI confusion On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> How would a user ever learn what their CanonicalID is? > > The user doesn't need to know his i-number. The system discovers that > for him. > >> If there Portable Identifier (i-name) is reassigned, then they will >> be sent to an IdP for the new Canonical ID is, expecting credentials >> from the new owner. The user will never make it back to the RP, and >> they will have no easy way of proving they are the owner of the >> CanonicalID. > > I don't really understand this paragraph, but when the i-name is > reassigned it'll cease to point at the same XRDS and will thus not > point at the IdP anymore - unless the new owner also has an account > with that IdP, of course. But they have a different i-number, so the > IdP can distinguish them. Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does not know this. Bob goes to an RP, enters =foo and gets sent somewhere he cannot authenticate since =foo resolves somewhere else. Bob does not know what to do. =foo does not resolve to his i-number any more. How does he find out what it is so that he can get a his i- name to point to it? > >> Additionally, in the proposal, the i-name is not sent from the RP to >> the IdP, so how does the IdP know which i-name to address the user >> as? > > I would hope that an IdP, given that I've already established a > relationship with it, can find something better to address me with > than a URI. It should be calling me "Martin". Perhaps, although I would like my IdP to let me know which Identifier I am going to present to the RP. -- Dick ___ 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: XRI confusion
On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> How would a user ever learn what their CanonicalID is? > > The user doesn't need to know his i-number. The system discovers that > for him. > >> If there Portable Identifier (i-name) is reassigned, then they will >> be sent to an IdP for the new Canonical ID is, expecting credentials >> from the new owner. The user will never make it back to the RP, and >> they will have no easy way of proving they are the owner of the >> CanonicalID. > > I don't really understand this paragraph, but when the i-name is > reassigned it'll cease to point at the same XRDS and will thus not > point > at the IdP anymore — unless the new owner also has an account with > that > IdP, of course. But they have a different i-number, so the IdP can > distinguish them. Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does not know this. Bob goes to an RP, enters =foo and gets sent somewhere he cannot authenticate since =foo resolves somewhere else. Bob does not know what to do. =foo does not resolve to his i-number any more. How does he find out what it is so that he can get a his i- name to point to it? > >> Additionally, in the proposal, the i-name is not sent from the RP to >> the IdP, so how does the IdP know which i-name to address the user >> as? > > I would hope that an IdP, given that I've already established a > relationship with it, can find something better to address me with > than > a URI. It should be calling me "Martin". Perhaps, although I would like my IdP to let me know which Identifier I am going to present to the RP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> In order for the RUA to detect that a site supports OpenID, it sees a >> form with a single input with a "name" of openid_identiifier. The RUA >> can then look at the action and post the data directly to the RP. >> > > I think it'd be better to implement this as either a META or a LINK > element alongside a standard protocol for communicating with the > nominated URL. > > This way the site can declare on *all pages*, rather than on the > forms-based login page, that it accepts OpenID auth. This allows the > user to go to the RP's home page (or any other page) and click the > "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: RP identifier
On 19-Oct-06, at 12:29 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> The IdP needs a unique identifier for the RP. >> openid.realm is a wild card that could match multiple RPs. > > This was by design. An RP that is exposing multiple "RP endpoints" > within the same realm is explicitly saying that it needs/wants them > all > to be treated the same. > > Part of this design is the ability for the RP to move the "RP > endpoint" > to a different URL without breaking all existing relationships, > which is > an important requirement in the real world where people often expose > their underlying architecture in their URLs and then have to break the > URLs when the architecture changes. > > The realm (assuming that this is what used to be called trust_root) is > what you should be using, and *allowing* that to match multiple RP > endpoints is okay and desirable. Agreed that it is desirable to have multiple RP endpoints for an RP. Does openid.realm then uniquely identify an RP? ie. no other RP will use the same Realm? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: rename Identity Provider to OpenID Provider
Dick Hardt wrote: > > Rename Identity Provider to OpenID Provider in the spec > +1 Agreed. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRI confusion
Dick Hardt wrote: > > How would a user ever learn what their CanonicalID is? The user doesn't need to know his i-number. The system discovers that for him. > If there Portable Identifier (i-name) is reassigned, then they will > be sent to an IdP for the new Canonical ID is, expecting credentials > from the new owner. The user will never make it back to the RP, and > they will have no easy way of proving they are the owner of the > CanonicalID. I don't really understand this paragraph, but when the i-name is reassigned it'll cease to point at the same XRDS and will thus not point at the IdP anymore — unless the new owner also has an account with that IdP, of course. But they have a different i-number, so the IdP can distinguish them. > Additionally, in the proposal, the i-name is not sent from the RP to > the IdP, so how does the IdP know which i-name to address the user > as? I would hope that an IdP, given that I've already established a relationship with it, can find something better to address me with than a URI. It should be calling me "Martin". ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Dick Hardt wrote: > > In order for the RUA to detect that a site supports OpenID, it sees a > form with a single input with a "name" of openid_identiifier. The RUA > can then look at the action and post the data directly to the RP. > I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: RP identifier
Dick Hardt wrote: > > The IdP needs a unique identifier for the RP. > openid.realm is a wild card that could match multiple RPs. This was by design. An RP that is exposing multiple "RP endpoints" within the same realm is explicitly saying that it needs/wants them all to be treated the same. Part of this design is the ability for the RP to move the "RP endpoint" to a different URL without breaking all existing relationships, which is an important requirement in the real world where people often expose their underlying architecture in their URLs and then have to break the URLs when the architecture changes. The realm (assuming that this is what used to be called trust_root) is what you should be using, and *allowing* that to match multiple RP endpoints is okay and desirable. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
# Why SHOULD rather then MUST? [1] # # What valid reason is there for an RP to not have that field name? The simple reason is that one can't enforce a MUST in this case. (And even if one ammends the spec to make the field name a prerequisite for OpenID, I question whether that is a good design choice.) I agree that it would be extremely useful to have a consistent form field name for just the reasons you cited, and the current spec reflects that. If the spec is the place one would put preferences, then they should be RECOMMENDEDs or SHOULDs: not MUSTs. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Question: multiple IdPs?
Dick Hardt wrote: > Forgive my lack of Yadis configuration expertise, but is this > something that your average blogger can add to their WP or MT blog? > As long as the user's IdP is explicitly setting openid:Delegate in their Yadis document, they should simply be able to point their X-Yadis-Location at, say http://user.livejournal.com/data/yadis [1] and have things work without having to write a Yadis document. Of course, their WP or MT blog will then inherit all of the service declarations exposed by the IdP, some of which might not be as easily "delegatable" as OpenID is. (This cross-domain linking is another reason why openid:Delegate should be required, incidentally.) [1] LiveJournal doesn't actually explicitly set openid:Delegate, so it is perhaps a bad example. This can be fixed if it proves worthwhile, though. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
IdP assisting user to present previous identifier
I expect I will have a number of OpenIDs, as well as lots of directed identities. I would like my IdP to keep track of which identity I use at what RP. I may forget which public identifier I used at a site, and type in the wrong one, and end up creating a new account and be confused. I may have used a directed identity, and forget and type in a public one, and then once again be creating a new account and be confused. I would like my IdP to be able to suggest which identifier I want to be in situations where I am using a different one from what I used in the past. This means that the following from: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal IdP Rules for Identifier Parameters 1. IdP MUST ALWAYS return the value of openid.identity sent by RP. would need to be changed so that the IdP can send a different identifier then what was sent by the RP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Two Identifiers - no caching advantage
After reading though: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal I have concluded there is no caching advantage Specifically if you look at these two sections: RP Rules for Identifier Parameters Case 3: URL WITH IdP-Specific Identifier If Portable Identifier is a URL that DOES map to a IdP-Specific Identifier, the values are: openid.identity = IdP-Specific Identifier openid.portable = Portable Identifier IdP Rules for Identifier Parameters 3. If openid.identity = Portable Identifier that IdP does not recognize, IdP MUST to discovery to obtain the IdP-Specific Identifier. I conclude the following: *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier and the Portable Identifier, so the RP sending both does may save the IdP effort, but leaves a potential security issue. (see Cached Discovery Attack below) *** the RP is using the Portable Identifier to identify the user, and does nothing with the IdP-Specific Identifier, so there is no value in the IdP sending both the Portable Identifier and the IdP-Specific Identifier. Note that the RP either maintains state that the IdP is bound to the Portable Identifier, or needs to do discover again. => The only reason for the RP to send the openid.identity to the IdP is for backward compatibility with OpenID 1.x, similarly the only reason for the IdP to send openid.identity to the RP is for OpenID 1.x compatibility. There are no caching advantages. Cached Discovery Attack: A malicious user takes over my blog, opens an account at the same IdP I use, inserts her IdP-Specific Identifier into my blog, and then uses my blog URL. The IdP will see the blog URL and the IdP-Specific Identifier don't match, do discovery on the blog URL, and then map my blog URL (Portable Identifier) to her IdP-Specific Identifier. I discover that my blog URL has been hacked, and restore my IdP- Specific Identifier. The malicious user goes to an RP, that providing her blog URL that contains her IdP-Specific Identifier. She captures the message from the RP, and changes the Portable Identifier to be my blog URL. The IdP still thinks the Portable Identifier is mapped to her IdP- Specific Identifier, and allows her to login to the RP as me. Solutions: 1) The IdP does discovery on the blog URL each time it is used. 2) The IdP has complex logic to ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
