RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Friday, November 10, 2006 2:41 AM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > I provide email addresses to some of my friends, but I don't provide > them with corresponding OpenID identities. By an unfortunate twist of > fate, the domain I provide these addresses in is also my website, and > since my site doesn't require authentication the WWW-Authenticate header > is ignored. Consequently, http://[EMAIL PROTECTED]/ will end up > at *my* website, not the website of the person who uses > [EMAIL PROTECTED] > Ok, so (just to clarify) in your example we're talking about an email address '[EMAIL PROTECTED]' that maps to a url at an IdP, such that the mapped URL includes the username ('http://[EMAIL PROTECTED]') [** just to be clear, this is David R's proposal...my proposal ignores the userid in the email address **] So, in your example, if you have given someone an email address with a domain 'mydomain.com', and you choose not to offer OpenId services, then emails in your domain can't be used with OpenId. I don't see the problem, -- you own the domain, after all, and should control that decision. Additionally, your scenario is also true in the case of a regular Identity URL that you give out. If you provide an Identity URL 'http://someuser.mydomain.com', but you happen to support some other User Centric Identity standard (i.e., not OpenId), and your user tries to use the URL that you provided (with an OpenId RP), he'd get the same result. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
On Nov 8, 2006, at 23:42, Hallam-Baker, Phillip wrote: > What you are calling discovery is what I would term location. > > URL - Uniform Resource Locator > > The locator is completely self contained, no discovery necessary, > all the information you need to resolve is there. Gotta nitpick here, sorry about that: I don't think it does. For example, the URL does not tell me: - what HTTP version the server can speak - what representations of the resource it can return, e.g. MIME types - what HTTP methods it understands (e.g. WebDav) etc.etc. All the stuff that is in the HTTP headers beyond the URLs. One way of looking at XRDS is to add more meta-data to URLs just like certain HTTP fields add more meta-data. Theoretically, one could pack all of that meta-data into HTTP header extensions, but that's ... well, not so good. So the header adds a level of indirection from where that info can be retrieved. There's another problem with using DNS for this: DNS would have a very hard time returning 1000 different XRDS files (or equivalent) from 1000 different URLs hosted on the same server. Just think of identity-related services that the IdP/OP charges for: some users on the host will have bought other packages (e.g. voice auth vs. fob) than others, and thus their XRDS file changes -- and rather quickly, e.g. when they don't pay on time. >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, November 09, 2006 2:05 AM >> To: Johannes Ernst >> Cc: Hallam-Baker, Phillip; specs@openid.net; general >> Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] >> Handle "http://[EMAIL PROTECTED]" Style Identifiers) >> >> I agree with Johannes here. DNS is not user accessible (for >> good reason) Documents on a web server are relatively more >> accessible. >> >> wrt. DNS, I think DNSSEC could have a significant role in >> providing server to server discovery, specifically of key key >> material. >> >> -- Dick >> >> On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote: >> >>> Just commenting on the XRDS discovery from HTTP URLs bit. >>> >>> Using DNS as a mechanism, given a URL, to discover the >> location of, or >>> obtain the content or equivalent of, the XRDS file, was >> proposed back >>> then in Yadis 0.x days, and rejected. The reason being that >> any such >>> mechanism would require the system administrator in charge >> of the DNS >>> system to "configure XRDS" for any and all users in that domain. It >>> would give that system administrator an effective veto >> (exercised by >>> being lazy, for example) over whether or not users could >> use OpenID on >>> that domain, and in particular which services to reference >> from that >>> file (e.g. competitive services). There was general >> consensus that for >>> a "user-centric" identity system, that was not desirable, >> and that's >>> why we decided in favor of the HTTP header extension, its HTML >>> equivalent, and the shortcut via the MIME type. >>> >>> We felt on safe ground with respect to naming design, because it's >>> very much the same approach as, say, the reference of >> embedded GIFs or >>> CSS in HTML, or the use of URLs to identify DTDs in XML. >>> >>> >>> On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: >>> >>>> Quite a few years went into the design of DNS. >>>> >>>> The concern I have here is that to influence the wider >> network is a >>>> very serious challenge. >>>> >>>> Innovation in naming is the single hardest thing to do in >> a network >>>> protocol. I have seen UDDI, Realnames, X.500, so many proposals. >>>> >>>> >>>> When someone tells me a simple thing is too complex and >> then proposes >>>> to do the single hardest, most complex thing in computer >> networking I >>>> have concerns. >>>> >>>>> -Original Message- >>>>> From: Drummond Reed [mailto:[EMAIL PROTECTED] >>>>> Sent: Wednesday, November 08, 2006 7:42 PM >>>>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' >>>>> Cc: specs@openid.net; [EMAIL PROTECTED] >>>>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle >>>>> "http://[EMAIL PROTECTED]" Style Identifiers) >>>>> >>>>> Phillip, >>>>&
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Thursday, November 09, 2006 5:36 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Sometimes these things will be character-for-character identical to a > given email address by coincidence, but there's no way to enforce this > nor any guarantee that the user controlling http://[EMAIL PROTECTED]/ is > the same user that controls mailto:[EMAIL PROTECTED] > Can you provide an example (real or otherwise) of such a scenario? Do you really envision any domain owner giving 'http://[EMAIL PROTECTED]' to one person, whilst giving 'mailto:[EMAIL PROTECTED]' to a different user? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On Wed, Nov 08, 2006 at 11:16:41PM -0500, David Fuelling wrote: > Couldn't one make the opposite argument -- that most people's email address > NOT working when they plug it into the OpenId login field could actually be > a good thing? (especially in the beginning of OpenID) > Scenario #2 (WITH email allowed in the OpenId login form): User encounters > an "openid enabled" site, and decides they are curious about the new "way" > to login. If their email domain supports OpenId, then there's really no > reason for a novice user NOT to use OpenId -- it works with the email > address. > > On the other hand, if the RP determines that the specified email address > doesn't support OpenId, it (the RP) then comes back to the User with an > educational page explaining why the email doesn't work, perhaps with a "call > your email provider and encourage them to adopt openid...and here's why". This makes a lot of sense to me. What's appealing to me about OpenID is that it's a very easy (user- and admin- friendly) system for ad-hoc federation/assertions. Relying Parties don't need any special out-of-band pre-authentication setup with IdPs. Nor is there a need for new PKI infrastructures -- the PKI behind https suffices. For users, no special client software is needed. Why try to teach users this homesite/unique OpenID identifier "URL" concept when OpenID could use an identifier the user already understands & has, like an email address, for locating the user's IdP? -Peter > > -Original Message- > > From: Dick Hardt [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 5:06 PM > > To: David Fuelling > > Cc: specs@openid.net > > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > A Homesite is a new concept for users, so when they see a prompt for > > it, they will know they have one or not. They are not just typing in > > a random URL. > > > > Pretty much every user has an email address, so a prompt asking for > > an email would suggest to user that their email will work -- which of > > course hardly any will. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hi Martin, This is interesting. I guess your suggestion (see your msg below) deals with a sub-topic of the whole "should email be allowed in the OpenId login form" debate, which is this: "If email is allowed in the OpenId login form, should the mapping/normalization include the email Userid...OR, should OpenId ignore the email address userid, and map/normalize an email address to a specific IdP URL, allowing the IdP more flexibility in determining how to do login"? 1.) I'm not convinced that OpenId specifying a mapping/normalization scheme that maps email addresses to IdP/OP URL's is really so bad. We're already mapping/normalizing www.cnn.com to its correct http scheme equivalent (http://www.cnn.com). 2.) In Mozilla 2.0, if I type [EMAIL PROTECTED] into the URL bar, it normalizes that (behind the scenes) to http://beth:@google.com. Because google.com doesn't require user auth, I'm then redirected to http://google.com, which redirects to http://www.google.com. 3.) The voice-activated OpenId thread on these lists comes to mind - a Userid component of an email address may not be required, nor necessary in many cases if a user is identified on the IdP/OP by his/her voice (for example). I'm curious to hear yours (and everyone else's) thoughts on this. I don't think we want to couple OpenId too tightly (if at all) to an email address -- just provide an easy-to-use bridge between the two. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Thursday, November 09, 2006 12:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > One idea we came up with before was to specify that [EMAIL PROTECTED] > becomes http://[EMAIL PROTECTED]/ and the RP should try sending an > authenticate header for basic auth with base64 of "blah:" (empty password) > > This way it's (kinda) true to the meaning of that portion of the URL > scheme and it allows the IdP to distinguish between different users. > > We'd have to check to make sure that this never conflicts with Basic > auth implementations built into servers/frameworks, of course. > > > ___ > general mailing list > [EMAIL PROTECTED] > http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Phillip, Ok, now I understand what you're saying about "not using Http in this way". However, I'm not advocating doing anything with the username part of an email (this might be where we're missing each other). I'm saying that we just take the + of an email, normalize it per the OpenId spec, and use that Http URL that we get as the URL of our IdP. Let me elaborate. In a previous message, you wrote: > > > There are two issues here: > > > > > > 1) The user presentation of the identifier > > > 2) The machine presentation > > > > > > The two do not need to be the same. www.cnn.com works > > perfectly well > > > as a way to locate CNN. That is a perfectly acceptable user > > > presentation. It is not an acceptable machine presentation and > > > browsers SHOULD NOT accept href="www.cnn.com". If the "user presentation" value is an email (e.g., '[EMAIL PROTECTED]'), then what is wrong with the machine presentation (wrt OpenId) being 'http://example.com'? The OpenId spec is already doing this with URL's in section 8.2 (Normalization). We're mapping/normalizing 'www.cnn.com' to 'http://www.cnn.com', even though www.cnn.com is not (technically) a validly schemed Http url. Why not do the same with email addresses? > -Original Message- > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 4:37 PM > To: David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Please don't map to Http this way. > > It would be fine to define a fixed mapping from a user identifier to http. > But it has to respect the http scheme design and be crafted to avoid > operability concerns. > > http://example.com/user would be acceptable as meeting the scheme design. > It is absolutely critical to maintain left/right hierarchy. > > The username/password pieces in http were not well thought out and may > have to be eliminated. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
[re-sending in plain-text] Many sites allow users to register for services using an e-mail address. Often such sites require the user to verify ownership of the e-mail address by sending an e-mail to the just registered address, but not always. When a site allows such a registration they also request the user to create a password. So users can access "service" by providing e-mail/password -- my guess is that many users use the same password as required for their actual e-mail account, but I have no idea how many. People do this all the time. I know of at least one pretty large portal that allows it. If e-mail addresses could be used, sites could lookup the domain using whatever method is described by OpenId, find the OP and let that collect the id/password. If the domain isn't an OP, the site could handle it locally as a registered e-mail address/identity. Rich On 11/8/06 5:06 PM, Dick Hardt wrote the following: > Hi David > > A Homesite is a new concept for users, so when they see a prompt for > it, they will know they have one or not. They are not just typing in > a random URL. > > Pretty much every user has an email address, so a prompt asking for > an email would suggest to user that their email will work -- which of > course hardly any will. > > -- Dick > > On 8-Nov-06, at 10:51 AM, David Fuelling wrote: > >> Dick, >> >> It seems like the same problem exists if a user types an IdP URL. >> If that >> URL (e.g., example.com) isn't a valid OpenId IdP, then the user >> will still >> encounter a problem. >> >> Shouldn't the RP show an "educational page" if a >> Homesite/i-name/OpenId/email doesn't resolve to something that >> OpenID can >> use? >> >> David Fuelling >> >>> -Original Message- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> On Behalf >>> Of Dick Hardt >>> Sent: Sunday, October 22, 2006 12:26 PM >>> To: John Panzer >>> Cc: Kaliya *; specs@openid.net >>> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style >>> Identifiers >>> >>> ... >>> >>> If we support email addresses, then the prompt may look something >>> like this: >>> >>> "email | Homesite | i-name | OpenID" >>> >>> Now any user with an email address thinks they can type it into the >>> box and login. This of course is not going to be the case. >>> >> > > ___ > 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: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
What you are calling discovery is what I would term location. URL - Uniform Resource Locator The locator is completely self contained, no discovery necessary, all the information you need to resolve is there. > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 09, 2006 2:05 AM > To: Johannes Ernst > Cc: Hallam-Baker, Phillip; specs@openid.net; general > Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] > Handle "http://[EMAIL PROTECTED]" Style Identifiers) > > I agree with Johannes here. DNS is not user accessible (for > good reason) Documents on a web server are relatively more accessible. > > wrt. DNS, I think DNSSEC could have a significant role in > providing server to server discovery, specifically of key key > material. > > -- Dick > > On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote: > > > Just commenting on the XRDS discovery from HTTP URLs bit. > > > > Using DNS as a mechanism, given a URL, to discover the > location of, or > > obtain the content or equivalent of, the XRDS file, was > proposed back > > then in Yadis 0.x days, and rejected. The reason being that > any such > > mechanism would require the system administrator in charge > of the DNS > > system to "configure XRDS" for any and all users in that domain. It > > would give that system administrator an effective veto > (exercised by > > being lazy, for example) over whether or not users could > use OpenID on > > that domain, and in particular which services to reference > from that > > file (e.g. competitive services). There was general > consensus that for > > a "user-centric" identity system, that was not desirable, > and that's > > why we decided in favor of the HTTP header extension, its HTML > > equivalent, and the shortcut via the MIME type. > > > > We felt on safe ground with respect to naming design, because it's > > very much the same approach as, say, the reference of > embedded GIFs or > > CSS in HTML, or the use of URLs to identify DTDs in XML. > > > > > > On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: > > > >> Quite a few years went into the design of DNS. > >> > >> The concern I have here is that to influence the wider > network is a > >> very serious challenge. > >> > >> Innovation in naming is the single hardest thing to do in > a network > >> protocol. I have seen UDDI, Realnames, X.500, so many proposals. > >> > >> > >> When someone tells me a simple thing is too complex and > then proposes > >> to do the single hardest, most complex thing in computer > networking I > >> have concerns. > >> > >>> -Original Message- > >>> From: Drummond Reed [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, November 08, 2006 7:42 PM > >>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' > >>> Cc: specs@openid.net; [EMAIL PROTECTED] > >>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle > >>> "http://[EMAIL PROTECTED]" Style Identifiers) > >>> > >>> Phillip, > >>> > >>> Please don't shoot me -- I am just the messenger -- but a > year-long > >>> effort > >>> (Yadis) went into the design and deployment of XRDS > documents as the > >>> discovery infrastructure for OpenID. > >>> > >>> There are numerous reasons for this, but they boil down to > >>> this: the XRDS layer of identity is rooted at a higher layer than > >>> that of DNS. Users don't just have DNS names in OpenID; they have > >>> URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which > >>> perform mapping of URLs/XRIs to URI-identified service endpoints. > >>> These service endpoint URIs in turn map down to services > resolvable > >>> at the DNS layer (which then of course map down to > machine addresses > >>> at the IP layer). > >>> > >>> I fully understand that you "have seen so many attempts > to reinvent > >>> it" (the DNS). OpenID and URL/XRI-based identity is not > an attempt > >>> to reinvent it. It is the emergence of identity > infrastructure at a > >>> higher layer designed to take advantage of the abstractions > >>> available at that layer, including: > >>> > >>> * URI and XRI syntax (much rich
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
I agree with Johannes here. DNS is not user accessible (for good reason) Documents on a web server are relatively more accessible. wrt. DNS, I think DNSSEC could have a significant role in providing server to server discovery, specifically of key key material. -- Dick On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote: > Just commenting on the XRDS discovery from HTTP URLs bit. > > Using DNS as a mechanism, given a URL, to discover the location of, > or obtain the content or equivalent of, the XRDS file, was proposed > back then in Yadis 0.x days, and rejected. The reason being that any > such mechanism would require the system administrator in charge of > the DNS system to "configure XRDS" for any and all users in that > domain. It would give that system administrator an effective veto > (exercised by being lazy, for example) over whether or not users > could use OpenID on that domain, and in particular which services to > reference from that file (e.g. competitive services). There was > general consensus that for a "user-centric" identity system, that was > not desirable, and that's why we decided in favor of the HTTP header > extension, its HTML equivalent, and the shortcut via the MIME type. > > We felt on safe ground with respect to naming design, because it's > very much the same approach as, say, the reference of embedded GIFs > or CSS in HTML, or the use of URLs to identify DTDs in XML. > > > On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: > >> Quite a few years went into the design of DNS. >> >> The concern I have here is that to influence the wider network is a >> very serious challenge. >> >> Innovation in naming is the single hardest thing to do in a network >> protocol. I have seen UDDI, Realnames, X.500, so many proposals. >> >> >> When someone tells me a simple thing is too complex and then >> proposes to do the single hardest, most complex thing in computer >> networking I have concerns. >> >>> -Original Message- >>> From: Drummond Reed [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, November 08, 2006 7:42 PM >>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' >>> Cc: specs@openid.net; [EMAIL PROTECTED] >>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] >>> Handle "http://[EMAIL PROTECTED]" Style Identifiers) >>> >>> Phillip, >>> >>> Please don't shoot me -- I am just the messenger -- but a >>> year-long effort >>> (Yadis) went into the design and deployment of XRDS documents >>> as the discovery infrastructure for OpenID. >>> >>> There are numerous reasons for this, but they boil down to >>> this: the XRDS layer of identity is rooted at a higher layer >>> than that of DNS. Users don't just have DNS names in OpenID; >>> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS >>> documents, which perform mapping of URLs/XRIs to >>> URI-identified service endpoints. These service endpoint URIs >>> in turn map down to services resolvable at the DNS layer >>> (which then of course map down to machine addresses at the IP >>> layer). >>> >>> I fully understand that you "have seen so many attempts to >>> reinvent it" (the DNS). OpenID and URL/XRI-based identity is >>> not an attempt to reinvent it. It is the emergence of >>> identity infrastructure at a higher layer designed to take >>> advantage of the abstractions available at that layer, including: >>> >>> * URI and XRI syntax (much richer than DNS) >>> * HTTP and HTTPS protocols for discovery >>> * Extensible, XML-encoded resource description metadata >>> * Mapping of reassignable and persistent identifiers for >>> persistent identity >>> * Discovery of typed service endpoints >>> >>> I know you know my personal bias (anyone who would push the >>> XRI boulder this long uphill has got to have a few screws >>> loose), but at this point it seems like trying to push the >>> XRDS layer back down into DNS would be like trying to put the >>> genie back in the bottle. >>> >>> =Drummond >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip >>> Sent: Wednesday, November 08, 2006 3:01 PM >>> To: Recordon, David; David Fuelling >>> Cc: specs@openid.net; [EMAIL PROTECTED] >>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" >>&g
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hey Dick, Couldn't one make the opposite argument -- that most people's email address NOT working when they plug it into the OpenId login field could actually be a good thing? (especially in the beginning of OpenID) I say this because such scenarios (user enters email, and RP fails because the email doesn't yet support open id) might actually be a catalyst for more people to use OpenId, especially if users start barking at their ISP/email providers to support OpenId because their email isn't working correctly with certain sites they want to use. For example, consider the following two potential scenarios that might go through a new user's mind when they first encounter OpenId: Scenario #1 (WITHOUT email allowed in the OpenId login form): User encounters an "openid enabled" site (RP ==> example.com), and decides they are curious about this new "way" to login (simplifying, I know -- but we're talking about a simple user). The user pretty quickly realizes that they need to somehow secure an Identity URL. The typical user (my parents, e.g.) might be inclined to say: "all my other (non-openid) sites require my email address (usually) as a username. Plus, since example.com still supports email address based username+passwords anyway, why not just continue to use that?" Thus, the novice user who fails to see the benefits of OpenId might just decide against OpenId because of the perceived difficulties in using it, especially in the beginning when OpenId adoption will be gaining traction, but not the majority method used for site login. Scenario #2 (WITH email allowed in the OpenId login form): User encounters an "openid enabled" site, and decides they are curious about the new "way" to login. If their email domain supports OpenId, then there's really no reason for a novice user NOT to use OpenId -- it works with the email address. On the other hand, if the RP determines that the specified email address doesn't support OpenId, it (the RP) then comes back to the User with an educational page explaining why the email doesn't work, perhaps with a "call your email provider and encourage them to adopt openid...and here's why". Anyway, this might be a different perspective on whether or not the ["oops, your login didn't work"] is a bad thing. > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 5:06 PM > To: David Fuelling > Cc: specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Hi David > > A Homesite is a new concept for users, so when they see a prompt for > it, they will know they have one or not. They are not just typing in > a random URL. > > Pretty much every user has an email address, so a prompt asking for > an email would suggest to user that their email will work -- which of > course hardly any will. > > -- Dick > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
Just commenting on the XRDS discovery from HTTP URLs bit. Using DNS as a mechanism, given a URL, to discover the location of, or obtain the content or equivalent of, the XRDS file, was proposed back then in Yadis 0.x days, and rejected. The reason being that any such mechanism would require the system administrator in charge of the DNS system to "configure XRDS" for any and all users in that domain. It would give that system administrator an effective veto (exercised by being lazy, for example) over whether or not users could use OpenID on that domain, and in particular which services to reference from that file (e.g. competitive services). There was general consensus that for a "user-centric" identity system, that was not desirable, and that's why we decided in favor of the HTTP header extension, its HTML equivalent, and the shortcut via the MIME type. We felt on safe ground with respect to naming design, because it's very much the same approach as, say, the reference of embedded GIFs or CSS in HTML, or the use of URLs to identify DTDs in XML. On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: > Quite a few years went into the design of DNS. > > The concern I have here is that to influence the wider network is a > very serious challenge. > > Innovation in naming is the single hardest thing to do in a network > protocol. I have seen UDDI, Realnames, X.500, so many proposals. > > > When someone tells me a simple thing is too complex and then > proposes to do the single hardest, most complex thing in computer > networking I have concerns. > >> -Original Message- >> From: Drummond Reed [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, November 08, 2006 7:42 PM >> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' >> Cc: specs@openid.net; [EMAIL PROTECTED] >> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] >> Handle "http://[EMAIL PROTECTED]" Style Identifiers) >> >> Phillip, >> >> Please don't shoot me -- I am just the messenger -- but a >> year-long effort >> (Yadis) went into the design and deployment of XRDS documents >> as the discovery infrastructure for OpenID. >> >> There are numerous reasons for this, but they boil down to >> this: the XRDS layer of identity is rooted at a higher layer >> than that of DNS. Users don't just have DNS names in OpenID; >> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS >> documents, which perform mapping of URLs/XRIs to >> URI-identified service endpoints. These service endpoint URIs >> in turn map down to services resolvable at the DNS layer >> (which then of course map down to machine addresses at the IP layer). >> >> I fully understand that you "have seen so many attempts to >> reinvent it" (the DNS). OpenID and URL/XRI-based identity is >> not an attempt to reinvent it. It is the emergence of >> identity infrastructure at a higher layer designed to take >> advantage of the abstractions available at that layer, including: >> >> * URI and XRI syntax (much richer than DNS) >> * HTTP and HTTPS protocols for discovery >> * Extensible, XML-encoded resource description metadata >> * Mapping of reassignable and persistent identifiers for >> persistent identity >> * Discovery of typed service endpoints >> >> I know you know my personal bias (anyone who would push the >> XRI boulder this long uphill has got to have a few screws >> loose), but at this point it seems like trying to push the >> XRDS layer back down into DNS would be like trying to put the >> genie back in the bottle. >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip >> Sent: Wednesday, November 08, 2006 3:01 PM >> To: Recordon, David; David Fuelling >> Cc: specs@openid.net; [EMAIL PROTECTED] >> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" >> Style Identifiers >> >> You can make things complex in two ways, one is by adding too >> many curlicues to a design, another is by refusing to use the >> deployed infrastructure for its intended purpose. >> >> The signaling and discovery infrastructure of the Internet is the >> DNS. >> >> I have seen so many attempts to reinvent it. >> >>> -Original Message- >>> From: Recordon, David >>> Sent: Wednesday, November 08, 2006 4:50 PM >>> To: Hallam-Baker, Phillip; David Fuelling >>> Cc: specs@openid.net; [EMAIL PROTECTED] >>> Subject: RE: [PROPO
RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
Quite a few years went into the design of DNS. The concern I have here is that to influence the wider network is a very serious challenge. Innovation in naming is the single hardest thing to do in a network protocol. I have seen UDDI, Realnames, X.500, so many proposals. When someone tells me a simple thing is too complex and then proposes to do the single hardest, most complex thing in computer networking I have concerns. > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 7:42 PM > To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] > Handle "http://[EMAIL PROTECTED]" Style Identifiers) > > Phillip, > > Please don't shoot me -- I am just the messenger -- but a > year-long effort > (Yadis) went into the design and deployment of XRDS documents > as the discovery infrastructure for OpenID. > > There are numerous reasons for this, but they boil down to > this: the XRDS layer of identity is rooted at a higher layer > than that of DNS. Users don't just have DNS names in OpenID; > they have URLs or XRIs. Those URLs or XRIs resolve to XRDS > documents, which perform mapping of URLs/XRIs to > URI-identified service endpoints. These service endpoint URIs > in turn map down to services resolvable at the DNS layer > (which then of course map down to machine addresses at the IP layer). > > I fully understand that you "have seen so many attempts to > reinvent it" (the DNS). OpenID and URL/XRI-based identity is > not an attempt to reinvent it. It is the emergence of > identity infrastructure at a higher layer designed to take > advantage of the abstractions available at that layer, including: > > * URI and XRI syntax (much richer than DNS) > * HTTP and HTTPS protocols for discovery > * Extensible, XML-encoded resource description metadata > * Mapping of reassignable and persistent identifiers for > persistent identity > * Discovery of typed service endpoints > > I know you know my personal bias (anyone who would push the > XRI boulder this long uphill has got to have a few screws > loose), but at this point it seems like trying to push the > XRDS layer back down into DNS would be like trying to put the > genie back in the bottle. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip > Sent: Wednesday, November 08, 2006 3:01 PM > To: Recordon, David; David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > You can make things complex in two ways, one is by adding too > many curlicues to a design, another is by refusing to use the > deployed infrastructure for its intended purpose. > > The signaling and discovery infrastructure of the Internet is the DNS. > > I have seen so many attempts to reinvent it. > > > -Original Message- > > From: Recordon, David > > Sent: Wednesday, November 08, 2006 4:50 PM > > To: Hallam-Baker, Phillip; David Fuelling > > Cc: specs@openid.net; [EMAIL PROTECTED] > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > Style Identifiers > > > > Involving DNS seems to make this too complex. If we're going to > > involve DNS, we might as well re-architect Yadis to use it as yet > > another discovery option. > > > > --David > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip > > Sent: Wednesday, November 08, 2006 1:37 PM > > To: David Fuelling > > Cc: specs@openid.net; [EMAIL PROTECTED] > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > Style Identifiers > > > > Please don't map to Http this way. > > > > It would be fine to define a fixed mapping from a user > identifier to > > http. But it has to respect the http scheme design and be > crafted to > > avoid operability concerns. > > > > http://example.com/user would be acceptable as meeting the scheme > > design. It is absolutely critical to maintain left/right hierarchy. > > > > The username/password pieces in http were not well thought > out and may > > have to be eliminated. > > > > > > The scheme I would propose would incorporate a policy > lookup so that > > it is possible to overide this mapping. The mapping to http > is fine as >
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Watkins Sent: Wednesday, November 08, 2006 4:21 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > >Recordon, David wrote: >> Involving DNS seems to make this too complex. If we're going to involve >> DNS, we might as well re-architect Yadis to use it as yet another >> discovery option. > >Yes, the TXT proposal seems complex. I prefer Phillip's second >suggestion, but I think something more unique would be advisable, e.g. > >http://openid.example.com/openid/user > >so that organizations can more easily separate the OpenID IdP systems >(hostname openid.MAILDOMAIN, web path /openid/) from any regular >http/https offerings. > >It would be nice (see my 'concerns about each user having a unique >"URL"' thread in the general openid list) if this could handle empty >usernames, e.g. if users could claim an identifier like > @example.com >to identify the IdP but let the IdP determine the user's identifier. Peter, as I mentioned in my reply on the General list, this is how the directed identity feature in OpenID Authentication 2.0 works. That was David's original suggestion as I remember -- have OpenID RPs treat an email address as simply an IdP name and execute the protocol from there. Since the XRI TC is now working on specifying the email form of an XRI (called an MXRI -- mailto XRI), this could work for both ordinary email addresses and MXRI addresses. But that's only if we decide that using an email address as an OpenID identifier makes sense, or if it just adds a new layer of confusion (as others have noted). =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
Phillip, Please don't shoot me -- I am just the messenger -- but a year-long effort (Yadis) went into the design and deployment of XRDS documents as the discovery infrastructure for OpenID. There are numerous reasons for this, but they boil down to this: the XRDS layer of identity is rooted at a higher layer than that of DNS. Users don't just have DNS names in OpenID; they have URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which perform mapping of URLs/XRIs to URI-identified service endpoints. These service endpoint URIs in turn map down to services resolvable at the DNS layer (which then of course map down to machine addresses at the IP layer). I fully understand that you "have seen so many attempts to reinvent it" (the DNS). OpenID and URL/XRI-based identity is not an attempt to reinvent it. It is the emergence of identity infrastructure at a higher layer designed to take advantage of the abstractions available at that layer, including: * URI and XRI syntax (much richer than DNS) * HTTP and HTTPS protocols for discovery * Extensible, XML-encoded resource description metadata * Mapping of reassignable and persistent identifiers for persistent identity * Discovery of typed service endpoints I know you know my personal bias (anyone who would push the XRI boulder this long uphill has got to have a few screws loose), but at this point it seems like trying to push the XRDS layer back down into DNS would be like trying to put the genie back in the bottle. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 3:01 PM To: Recordon, David; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers You can make things complex in two ways, one is by adding too many curlicues to a design, another is by refusing to use the deployed infrastructure for its intended purpose. The signaling and discovery infrastructure of the Internet is the DNS. I have seen so many attempts to reinvent it. > -Original Message- > From: Recordon, David > Sent: Wednesday, November 08, 2006 4:50 PM > To: Hallam-Baker, Phillip; David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Involving DNS seems to make this too complex. If we're going > to involve DNS, we might as well re-architect Yadis to use it > as yet another discovery option. > > --David > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip > Sent: Wednesday, November 08, 2006 1:37 PM > To: David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Please don't map to Http this way. > > It would be fine to define a fixed mapping from a user > identifier to http. But it has to respect the http scheme > design and be crafted to avoid operability concerns. > > http://example.com/user would be acceptable as meeting the > scheme design. It is absolutely critical to maintain > left/right hierarchy. > > The username/password pieces in http were not well thought > out and may have to be eliminated. > > > The scheme I would propose would incorporate a policy lookup > so that it is possible to overide this mapping. The mapping > to http is fine as a last resort but making it the first > resort means we cannot ever change it. > > What I would suggest is that we resolve [EMAIL PROTECTED] as follows > > 1) Perform a DNS lookup for a TXT record at _openid.example.com > if found perform policy processing > > 2) map the uri to http://example.com/user, do OpenID > > > Policy processing: > > The TXT record consists of a sequence of tag=value pairs that > list the authentication protocols that are supported. This > allows the relying party to choose the most appropriate > protocol for its needs. > > For example: > > "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" > > This says that the identity provider supports three different > authentication protocols, SAML, a reduced SAML and OPENID. > > > > -Original Message- > > From: David Fuelling [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 1:56 PM > > To: Hallam-Baker, Phillip > > Cc: specs@openid.net; [EMAIL PROTECTED] > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > Style Identifiers > > > > Hi Philip, > > > > I'm not sure I understand "Please don't use H
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Recordon, David wrote: > Involving DNS seems to make this too complex. If we're going to involve > DNS, we might as well re-architect Yadis to use it as yet another > discovery option. Yes, the TXT proposal seems complex. I prefer Phillip's second suggestion, but I think something more unique would be advisable, e.g. http://openid.example.com/openid/user so that organizations can more easily separate the OpenID IdP systems (hostname openid.MAILDOMAIN, web path /openid/) from any regular http/https offerings. It would be nice (see my 'concerns about each user having a unique "URL"' thread in the general openid list) if this could handle empty usernames, e.g. if users could claim an identifier like @example.com to identify the IdP but let the IdP determine the user's identifier. -Peter > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hallam-Baker, Phillip > Sent: Wednesday, November 08, 2006 1:37 PM > To: David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > Identifiers > It would be fine to define a fixed mapping from a user identifier to > http. But it has to respect the http scheme design and be crafted to > avoid operability concerns. > > http://example.com/user would be acceptable as meeting the scheme > design. It is absolutely critical to maintain left/right hierarchy. > What I would suggest is that we resolve [EMAIL PROTECTED] as follows > > 1) Perform a DNS lookup for a TXT record at _openid.example.com > if found perform policy processing > > 2) map the uri to http://example.com/user, do OpenID > > > Policy processing: > > The TXT record consists of a sequence of tag=value pairs that list the > authentication protocols that are supported. This allows the relying > party to choose the most appropriate protocol for its needs. > > For example: > > "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" > > This says that the identity provider supports three different > authentication protocols, SAML, a reduced SAML and OPENID. > > >> -Original Message- >> From: David Fuelling [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, November 08, 2006 1:56 PM >> To: Hallam-Baker, Phillip >> Cc: specs@openid.net; [EMAIL PROTECTED] >> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" >> Style Identifiers >> >> Hi Philip, >> >> I'm not sure I understand "Please don't use HTTP this way". >> >> I was suggesting that the user enter an email address. The RP then >> maps the email address to a URL (which would be in the proper scheme). >> >> >>> -Original Message- >>> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, November 08, 2006 1:45 PM >>> To: David Fuelling; specs@openid.net >>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style >>> Identifiers >>> >>> Please don't use HTTP this way. That is not the semantics >> for http URLs. >>> A better scheme would be to use mailto:[EMAIL PROTECTED] or >> to define >>> openid:[EMAIL PROTECTED] >>> >>> >>> There are two issues here: >>> >>> 1) The user presentation of the identifier >>> 2) The machine presentation >>> >>> The two do not need to be the same. www.cnn.com works >> perfectly well >>> as a way to locate CNN. That is a perfectly acceptable user >>> presentation. It is not an acceptable machine presentation and >>> browsers SHOULD NOT accept href="www.cnn.com". >>> >>> >>> >>> >>>> -Original Message- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling >>>> Sent: Wednesday, November 08, 2006 1:40 PM >>>> To: specs@openid.net >>>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" >>>> Style Identifiers >>>> >>>> Please see my questions/ideas enclosed... >>>> >>>> Thanks! >>>> >>>> David Fuelling >>>> >>>>> -Original Message- >>>>> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >>>>> On Behalf Of Drummond Reed >>>>> Sent: Friday, October 20, 2006 1:04 AM >>>>> To: 'Recordon, David'; specs@openid.net >>>>> Subject: RE: [PROPOSAL] Handle "
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Many sites allow users to register for services using an e-mail address. Often such sites require the user to verify ownership of the e-mail address by sending an e-mail to the just registered address, but not always. When a site allows such a registration they also request the user to create a password. So users can access "service" by providing e-mail/password -- my guess is that many users use the same password as required for their actual e-mail account, but I have no idea how many. People do this all the time. I know of at least one pretty large portal that allows it. If e-mail addresses could be used, sites could lookup the domain using whatever method is described by OpenId, find the OP and let that collect the id/password. If the domain isn't an OP, the site could handle it locally as a registered e-mail address/identity. Rich On 11/8/06 5:06 PM, Dick Hardt wrote the following: Hi David A Homesite is a new concept for users, so when they see a prompt for it, they will know they have one or not. They are not just typing in a random URL. Pretty much every user has an email address, so a prompt asking for an email would suggest to user that their email will work -- which of course hardly any will. -- Dick On 8-Nov-06, at 10:51 AM, David Fuelling wrote: Dick, It seems like the same problem exists if a user types an IdP URL. If that URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still encounter a problem. Shouldn't the RP show an "educational page" if a Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can use? David Fuelling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dick Hardt Sent: Sunday, October 22, 2006 12:26 PM To: John Panzer Cc: Kaliya *; specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers ... If we support email addresses, then the prompt may look something like this: "email | Homesite | i-name | OpenID" Now any user with an email address thinks they can type it into the box and login. This of course is not going to be the case. ___ 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
You can make things complex in two ways, one is by adding too many curlicues to a design, another is by refusing to use the deployed infrastructure for its intended purpose. The signaling and discovery infrastructure of the Internet is the DNS. I have seen so many attempts to reinvent it. > -Original Message- > From: Recordon, David > Sent: Wednesday, November 08, 2006 4:50 PM > To: Hallam-Baker, Phillip; David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Involving DNS seems to make this too complex. If we're going > to involve DNS, we might as well re-architect Yadis to use it > as yet another discovery option. > > --David > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip > Sent: Wednesday, November 08, 2006 1:37 PM > To: David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Please don't map to Http this way. > > It would be fine to define a fixed mapping from a user > identifier to http. But it has to respect the http scheme > design and be crafted to avoid operability concerns. > > http://example.com/user would be acceptable as meeting the > scheme design. It is absolutely critical to maintain > left/right hierarchy. > > The username/password pieces in http were not well thought > out and may have to be eliminated. > > > The scheme I would propose would incorporate a policy lookup > so that it is possible to overide this mapping. The mapping > to http is fine as a last resort but making it the first > resort means we cannot ever change it. > > What I would suggest is that we resolve [EMAIL PROTECTED] as follows > > 1) Perform a DNS lookup for a TXT record at _openid.example.com > if found perform policy processing > > 2) map the uri to http://example.com/user, do OpenID > > > Policy processing: > > The TXT record consists of a sequence of tag=value pairs that > list the authentication protocols that are supported. This > allows the relying party to choose the most appropriate > protocol for its needs. > > For example: > > "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" > > This says that the identity provider supports three different > authentication protocols, SAML, a reduced SAML and OPENID. > > > > -----Original Message- > > From: David Fuelling [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 1:56 PM > > To: Hallam-Baker, Phillip > > Cc: specs@openid.net; [EMAIL PROTECTED] > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > Style Identifiers > > > > Hi Philip, > > > > I'm not sure I understand "Please don't use HTTP this way". > > > > I was suggesting that the user enter an email address. The RP then > > maps the email address to a URL (which would be in the > proper scheme). > > > > > > > -Original Message- > > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, November 08, 2006 1:45 PM > > > To: David Fuelling; specs@openid.net > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > > > Identifiers > > > > > > Please don't use HTTP this way. That is not the semantics > > for http URLs. > > > > > > A better scheme would be to use mailto:[EMAIL PROTECTED] or > > to define > > > openid:[EMAIL PROTECTED] > > > > > > > > > There are two issues here: > > > > > > 1) The user presentation of the identifier > > > 2) The machine presentation > > > > > > The two do not need to be the same. www.cnn.com works > > perfectly well > > > as a way to locate CNN. That is a perfectly acceptable user > > > presentation. It is not an acceptable machine presentation and > > > browsers SHOULD NOT accept href="www.cnn.com". > > > > > > > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > > > > Sent: Wednesday, November 08, 2006 1:40 PM > > > > To: specs@openid.net > > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > > > Style Identifiers > > > > > > > >
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hi David A Homesite is a new concept for users, so when they see a prompt for it, they will know they have one or not. They are not just typing in a random URL. Pretty much every user has an email address, so a prompt asking for an email would suggest to user that their email will work -- which of course hardly any will. -- Dick On 8-Nov-06, at 10:51 AM, David Fuelling wrote: > Dick, > > It seems like the same problem exists if a user types an IdP URL. > If that > URL (e.g., example.com) isn't a valid OpenId IdP, then the user > will still > encounter a problem. > > Shouldn't the RP show an "educational page" if a > Homesite/i-name/OpenId/email doesn't resolve to something that > OpenID can > use? > > David Fuelling > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On Behalf >> Of Dick Hardt >> Sent: Sunday, October 22, 2006 12:26 PM >> To: John Panzer >> Cc: Kaliya *; specs@openid.net >> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style >> Identifiers >> >> ... >> >> If we support email addresses, then the prompt may look something >> like this: >> >> "email | Homesite | i-name | OpenID" >> >> Now any user with an email address thinks they can type it into the >> box and login. This of course is not going to be the case. >> > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Involving DNS seems to make this too complex. If we're going to involve DNS, we might as well re-architect Yadis to use it as yet another discovery option. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 1:37 PM To: David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers Please don't map to Http this way. It would be fine to define a fixed mapping from a user identifier to http. But it has to respect the http scheme design and be crafted to avoid operability concerns. http://example.com/user would be acceptable as meeting the scheme design. It is absolutely critical to maintain left/right hierarchy. The username/password pieces in http were not well thought out and may have to be eliminated. The scheme I would propose would incorporate a policy lookup so that it is possible to overide this mapping. The mapping to http is fine as a last resort but making it the first resort means we cannot ever change it. What I would suggest is that we resolve [EMAIL PROTECTED] as follows 1) Perform a DNS lookup for a TXT record at _openid.example.com if found perform policy processing 2) map the uri to http://example.com/user, do OpenID Policy processing: The TXT record consists of a sequence of tag=value pairs that list the authentication protocols that are supported. This allows the relying party to choose the most appropriate protocol for its needs. For example: "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" This says that the identity provider supports three different authentication protocols, SAML, a reduced SAML and OPENID. > -Original Message- > From: David Fuelling [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:56 PM > To: Hallam-Baker, Phillip > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Hi Philip, > > I'm not sure I understand "Please don't use HTTP this way". > > I was suggesting that the user enter an email address. The RP then > maps the email address to a URL (which would be in the proper scheme). > > > > -Original Message- > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 1:45 PM > > To: David Fuelling; specs@openid.net > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > > Identifiers > > > > Please don't use HTTP this way. That is not the semantics > for http URLs. > > > > A better scheme would be to use mailto:[EMAIL PROTECTED] or > to define > > openid:[EMAIL PROTECTED] > > > > > > There are two issues here: > > > > 1) The user presentation of the identifier > > 2) The machine presentation > > > > The two do not need to be the same. www.cnn.com works > perfectly well > > as a way to locate CNN. That is a perfectly acceptable user > > presentation. It is not an acceptable machine presentation and > > browsers SHOULD NOT accept href="www.cnn.com". > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > > > Sent: Wednesday, November 08, 2006 1:40 PM > > > To: specs@openid.net > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > > Style Identifiers > > > > > > Please see my questions/ideas enclosed... > > > > > > Thanks! > > > > > > David Fuelling > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > > > On Behalf Of Drummond Reed > > > > Sent: Friday, October 20, 2006 1:04 AM > > > > To: 'Recordon, David'; specs@openid.net > > > > Subject: 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. > > > > > > This seems reasonable at first glance. However, almost every > > > website I have a login
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Please don't map to Http this way. It would be fine to define a fixed mapping from a user identifier to http. But it has to respect the http scheme design and be crafted to avoid operability concerns. http://example.com/user would be acceptable as meeting the scheme design. It is absolutely critical to maintain left/right hierarchy. The username/password pieces in http were not well thought out and may have to be eliminated. The scheme I would propose would incorporate a policy lookup so that it is possible to overide this mapping. The mapping to http is fine as a last resort but making it the first resort means we cannot ever change it. What I would suggest is that we resolve [EMAIL PROTECTED] as follows 1) Perform a DNS lookup for a TXT record at _openid.example.com if found perform policy processing 2) map the uri to http://example.com/user, do OpenID Policy processing: The TXT record consists of a sequence of tag=value pairs that list the authentication protocols that are supported. This allows the relying party to choose the most appropriate protocol for its needs. For example: "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" This says that the identity provider supports three different authentication protocols, SAML, a reduced SAML and OPENID. > -Original Message- > From: David Fuelling [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:56 PM > To: Hallam-Baker, Phillip > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Hi Philip, > > I'm not sure I understand "Please don't use HTTP this way". > > I was suggesting that the user enter an email address. The > RP then maps the email address to a URL (which would be in > the proper scheme). > > > > -Original Message- > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 1:45 PM > > To: David Fuelling; specs@openid.net > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > > Identifiers > > > > Please don't use HTTP this way. That is not the semantics > for http URLs. > > > > A better scheme would be to use mailto:[EMAIL PROTECTED] or > to define > > openid:[EMAIL PROTECTED] > > > > > > There are two issues here: > > > > 1) The user presentation of the identifier > > 2) The machine presentation > > > > The two do not need to be the same. www.cnn.com works > perfectly well > > as a way to locate CNN. That is a perfectly acceptable user > > presentation. It is not an acceptable machine presentation and > > browsers SHOULD NOT accept href="www.cnn.com". > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > > > Sent: Wednesday, November 08, 2006 1:40 PM > > > To: specs@openid.net > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > > Style Identifiers > > > > > > Please see my questions/ideas enclosed... > > > > > > Thanks! > > > > > > David Fuelling > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > > > On Behalf Of Drummond Reed > > > > Sent: Friday, October 20, 2006 1:04 AM > > > > To: 'Recordon, David'; specs@openid.net > > > > Subject: 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. > > > > > > This seems reasonable at first glance. However, almost every > > > website I have a login with (today) requests my email address so > > > that the site can communicate with me electronically. > > > > > > So, if email addresses WERE used as an additional "login > input" for > > > OpenId, a user who didn't want to use his/her email > address to login > > > could always just use an IdP URL or XRI instead (as they > can today). > > > > > > Am I missing the
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
I wonder if it would help our discussion to clarify what is meant when we say that an email address is an "identifier". While an email address does technically identify SOMETHING, here I'm using it more as a "mapping". So, the way I'm conceiving of things is that the email is in fact a REAL email address. It's just that OpenId has a procedure for using it to forward a user to a proper IdP. A good parallel would be the Identity URL itself. A common user might think of this URL as something to be clicked on, and resolvable -- A Location. However, OpenID is instead/additionally using this URL in a slightly different way -- to map to an identity. Are not these two instances (email and Claimed Identity URL) "misleading" in the same way? (I'm actually not convinced that either is misleading, but I could be swayed). > -Original Message- > From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:45 PM > To: David Fuelling > Cc: specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > # So, if in a hypothetical world where we have 4 potential OpenId > # "values" that a user could enter, AND the goal is to reduce > # confusion, then does it really make sense to cut out the most common > # "value" (which is an email address)? > > IMHO, because using identifiers that look like email addresses would > be misleading. > > -- > Jonathan Daugherty > JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hi Philip, I'm not sure I understand "Please don't use HTTP this way". I was suggesting that the user enter an email address. The RP then maps the email address to a URL (which would be in the proper scheme). > -Original Message- > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:45 PM > To: David Fuelling; specs@openid.net > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Please don't use HTTP this way. That is not the semantics for http URLs. > > A better scheme would be to use mailto:[EMAIL PROTECTED] or to define > openid:[EMAIL PROTECTED] > > > There are two issues here: > > 1) The user presentation of the identifier > 2) The machine presentation > > The two do not need to be the same. www.cnn.com works perfectly well as a > way to locate CNN. That is a perfectly acceptable user presentation. It is > not an acceptable machine presentation and browsers SHOULD NOT accept > href="www.cnn.com". > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > > Sent: Wednesday, November 08, 2006 1:40 PM > > To: specs@openid.net > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > Style Identifiers > > > > Please see my questions/ideas enclosed... > > > > Thanks! > > > > David Fuelling > > > > > -----Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Drummond Reed > > > Sent: Friday, October 20, 2006 1:04 AM > > > To: 'Recordon, David'; specs@openid.net > > > Subject: 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. > > > > This seems reasonable at first glance. However, almost every > > website I have a login with (today) requests my email address > > so that the site can communicate with me electronically. > > > > So, if email addresses WERE used as an additional "login > > input" for OpenId, a user who didn't want to use his/her > > email address to login could always just use an IdP URL or > > XRI instead (as they can today). > > > > Am I missing the privacy concern here? > > > > > * Reassignability: email addresses are not only > > reassignable, but for > > > some domains, they are notoriously short-lived identifiers. > > > > Is this really such a problem? It seems to exist for URL's > > in the current protocol proposal anyway. For instance, most > > people don't own a Domain, which means they'll be using > > OpenID URL's that somebody else owns. Thus, URL's are > > reassignable too, and suffer from this in the same way > > (although I don't really see this as a problem). > > > > > * Non-portability: unless you own the top-level domain, they aren't > > > portable. > > > > Again, is this a problem if the email isn't the actual > > identifier? If we have a means of mapping an email to an > > OpenID Identity URL, then if the email goes away (is > > transferred or otherwise not in the control of the original > > user), then what's the problem? > > > > Point 1.) Losing an email address is no different than the > > case where a URL is lost/transferred/goes away. > > > > Point 2.) If a user "lost" his email address, theoretically > > the owner of the email address (example.com, e.g.) would > > remove the mapping from [EMAIL PROTECTED] to beth's Identity > > Provider URL. > > > > Point 3.) Even if the email address domain owner failed to > > remove this mapping, only the end-user (beth in this case) > > would be using the email to login. Presumably, if she > > switched email addresses, she would use her new address to > > login, and it wouldn't matter. Somebody else trying to use > > her email address would need to login to the IdP, and > > presumably be stopped there. > > > > > Food for thought... > > > > > > =Drummond > > > > > > ___ > > 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Dick, It seems like the same problem exists if a user types an IdP URL. If that URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still encounter a problem. Shouldn't the RP show an "educational page" if a Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can use? David Fuelling > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Dick Hardt > Sent: Sunday, October 22, 2006 12:26 PM > To: John Panzer > Cc: Kaliya *; specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > ... > > If we support email addresses, then the prompt may look something > like this: > > "email | Homesite | i-name | OpenID" > > Now any user with an email address thinks they can type it into the > box and login. This of course is not going to be the case. > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Please don't use HTTP this way. That is not the semantics for http URLs. A better scheme would be to use mailto:[EMAIL PROTECTED] or to define openid:[EMAIL PROTECTED] There are two issues here: 1) The user presentation of the identifier 2) The machine presentation The two do not need to be the same. www.cnn.com works perfectly well as a way to locate CNN. That is a perfectly acceptable user presentation. It is not an acceptable machine presentation and browsers SHOULD NOT accept href="www.cnn.com". > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > Sent: Wednesday, November 08, 2006 1:40 PM > To: specs@openid.net > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Please see my questions/ideas enclosed... > > Thanks! > > David Fuelling > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Drummond Reed > > Sent: Friday, October 20, 2006 1:04 AM > > To: 'Recordon, David'; specs@openid.net > > Subject: 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. > > This seems reasonable at first glance. However, almost every > website I have a login with (today) requests my email address > so that the site can communicate with me electronically. > > So, if email addresses WERE used as an additional "login > input" for OpenId, a user who didn't want to use his/her > email address to login could always just use an IdP URL or > XRI instead (as they can today). > > Am I missing the privacy concern here? > > > * Reassignability: email addresses are not only > reassignable, but for > > some domains, they are notoriously short-lived identifiers. > > Is this really such a problem? It seems to exist for URL's > in the current protocol proposal anyway. For instance, most > people don't own a Domain, which means they'll be using > OpenID URL's that somebody else owns. Thus, URL's are > reassignable too, and suffer from this in the same way > (although I don't really see this as a problem). > > > * Non-portability: unless you own the top-level domain, they aren't > > portable. > > Again, is this a problem if the email isn't the actual > identifier? If we have a means of mapping an email to an > OpenID Identity URL, then if the email goes away (is > transferred or otherwise not in the control of the original > user), then what's the problem? > > Point 1.) Losing an email address is no different than the > case where a URL is lost/transferred/goes away. > > Point 2.) If a user "lost" his email address, theoretically > the owner of the email address (example.com, e.g.) would > remove the mapping from [EMAIL PROTECTED] to beth's Identity > Provider URL. > > Point 3.) Even if the email address domain owner failed to > remove this mapping, only the end-user (beth in this case) > would be using the email to login. Presumably, if she > switched email addresses, she would use her new address to > login, and it wouldn't matter. Somebody else trying to use > her email address would need to login to the IdP, and > presumably be stopped there. > > > Food for thought... > > > > =Drummond > > > ___ > 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
# So, if in a hypothetical world where we have 4 potential OpenId # "values" that a user could enter, AND the goal is to reduce # confusion, then does it really make sense to cut out the most common # "value" (which is an email address)? IMHO, because using identifiers that look like email addresses would be misleading. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
I agree. In fact, given that most people don't know what an XRI is, we might say there will be 3.5 times as much confusion. ;) So, if in a hypothetical world where we have 4 potential OpenId "values" that a user could enter, AND the goal is to reduce confusion, then does it really make sense to cut out the most common "value" (which is an email address)? > -Original Message- > From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:30 PM > To: David Fuelling > Cc: specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > # SIDE NOTE: For those who argue against email addresses in the OpenId > # login form on the grounds of confusion, these 2 email proposals > # should be no less "confusing" than trying to educate a user that the > # Identity URL they type in (e.g., http://aol.com) is not their > # identity. Both will/would take some education. > > Except that with this new feature, there would be twice as much > confusion. > > And except that an openid works both as a normal URL and as an OpenID, > whereas an email-like-thing may work as an OpenID, but is not always > going to work as an email even though it looks like one. > > So maybe 2.5 times as much confusion. :) > > -- > Jonathan Daugherty > JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Please see my questions/ideas enclosed... Thanks! David Fuelling > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Drummond Reed > Sent: Friday, October 20, 2006 1:04 AM > To: 'Recordon, David'; specs@openid.net > Subject: 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. This seems reasonable at first glance. However, almost every website I have a login with (today) requests my email address so that the site can communicate with me electronically. So, if email addresses WERE used as an additional "login input" for OpenId, a user who didn't want to use his/her email address to login could always just use an IdP URL or XRI instead (as they can today). Am I missing the privacy concern here? > * Reassignability: email addresses are not only reassignable, but for some > domains, they are notoriously short-lived identifiers. Is this really such a problem? It seems to exist for URL's in the current protocol proposal anyway. For instance, most people don't own a Domain, which means they'll be using OpenID URL's that somebody else owns. Thus, URL's are reassignable too, and suffer from this in the same way (although I don't really see this as a problem). > * Non-portability: unless you own the top-level domain, they aren't > portable. Again, is this a problem if the email isn't the actual identifier? If we have a means of mapping an email to an OpenID Identity URL, then if the email goes away (is transferred or otherwise not in the control of the original user), then what's the problem? Point 1.) Losing an email address is no different than the case where a URL is lost/transferred/goes away. Point 2.) If a user "lost" his email address, theoretically the owner of the email address (example.com, e.g.) would remove the mapping from [EMAIL PROTECTED] to beth's Identity Provider URL. Point 3.) Even if the email address domain owner failed to remove this mapping, only the end-user (beth in this case) would be using the email to login. Presumably, if she switched email addresses, she would use her new address to login, and it wouldn't matter. Somebody else trying to use her email address would need to login to the IdP, and presumably be stopped there. > Food for thought... > > =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
# SIDE NOTE: For those who argue against email addresses in the OpenId # login form on the grounds of confusion, these 2 email proposals # should be no less "confusing" than trying to educate a user that the # Identity URL they type in (e.g., http://aol.com) is not their # identity. Both will/would take some education. Except that with this new feature, there would be twice as much confusion. And except that an openid works both as a normal URL and as an OpenID, whereas an email-like-thing may work as an OpenID, but is not always going to work as an email even though it looks like one. So maybe 2.5 times as much confusion. :) -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hi All, Sorry to re-open this can of worms, but I'm just getting a chance to chime in. I actually think David Recordan's idea re: email address to URL resolution would be a great idea! My vote would also be to allow an Email address to map to an Identity Provider URL. NOTE: The email address does not map to a Claimed Identity nor to a Verified Identity (This is key!) Assuming I'm reading David R's proposal correctly, I think the only difference between the two proposals is that in mine, the IdP doesn't need to know what email address was entered (remember, the email is NOT the identity -- it's just a mapping). Here it is 1.) User enters an email address into an RP's OpenId login box. 2.) Behind the scenes, the RP resolves the email address to an OpenId URL via [Resolution Procedure] below. 3.) If the email address resolves to an Identity Provider URL, then the RP continues the OpenId protocol as if the user had entered the Identity Provider URL. 4.) If the email address does NOT resolve to an Identity Provider URL, then the RP SHOULD display a page that says something like: "We're sorry, your email address doesn't not yet support Open ID. Please try a different identifier type." On the same page should be some verbiage to help educate the user about what OpenID identifiers are, and possibly how email addresses map to them. Additionally, this could be a page to educate the user about XRI's, and the other parts of OpenId that are appropriate. ### [Resolution Procedure]: An email address resolves to a valid OpenId IdP URL, per the following procedure. A1.) For a given email address of the form '[EMAIL PROTECTED]' and a corresponding domain of the form 'http(s)://domain.tld/, a RP SHOULD attempt OpenID URL discovery (See OpenId Auth 2.0 section 7.3 - Discovery) on the following URL's that are resolved out of the specified email address: 1.) http://. 2.) http://www.. The above URL's MUST be resolved by replacing the and values with corresponding values from the specified email address' 'domain' and 'tld' parameters. In addition, resolution of the above 2 alternate URL's should be done via a HEAD request to all of the URL's first, followed by a GET request to all of the URL's if no URL produces a valid Yadis Resource URL via the HEAD method. A2.) Per the OpenId spec, if URL Discovery fails, then HTML-based discovery should be attempted on the same URL's, in the same manner as above. SIDE NOTE: For those who argue against email addresses in the OpenId login form on the grounds of confusion, these 2 email proposals should be no less "confusing" than trying to educate a user that the Identity URL they type in (e.g., http://aol.com) is not their identity. Both will/would take some education. Thanks! David Fuelling [EMAIL PROTECTED] > -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 _
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
No, that is the work-arroundThe solution is to have the email client assign fonts according to who is writing. Messages from Lord Rees-Mogg are written in an elegant Edwardian Copperplate. Paris Hilton uses BroadwayComments from Dick come in this font Sounds right to me. > -Original Message-> From: [EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]] On Behalf Of Dick Hardt> Sent: Sunday, October 22, 2006 5:00 PM> To: Kaliya Hamlin> Cc: specs@openid.net> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"> Style Identifiers>>> On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote:>> > For starters please don't use Comic Sans in professional> > correspondence. it is very hard to read (or take seriously)> http://> > bancomicsans.com/home.html>> Kaliya: The easy solution is to have your email program turn> all responses to plain text. :-)> ___> 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 9:04 PM, George Fletcher wrote: > > > Dick Hardt wrote: >> >> On 22-Oct-06, at 7:00 PM, George Fletcher wrote: >> >>> >>> >>> Dick Hardt wrote: With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. >>> Doesn't this imply that both the user and RP have to know which >>> IdP's >>> are "trust worthy"? >> >> It is a choice by the user. Just like the user chooses with ISP to >> move their data, which browser to run, which OS to run. IN >> general, those are not dictated by the RP. > I agree it is the user's choice to pick a "trust worthy" IDP. > However, if "un-trust worthy" IDPs exist, and users choose them, > then the RP (in order to protect itself) has to determine which > IDPs it considers "trust worthy". Hence both the user and the RP > "have to know" which IDPs are "trust worthy" and which are not. What is the RP needing to protect itself from? How does the RP protect itself from users that pick bad passwords or post them on sticky notes on their computer or walk away from their computer while logged in? >> Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. >>> So why can't idp.spammers.com allow anyone to enter a URI of >>> http://idp.spammers.com/ that resolves to a valid XRDS >>> document. >>> The RP then follows the IdP service link back to >>> https://idp.spammers.com and does the association exchange. Now >>> the RP >>> re-directs the user to https://idp.spammers.com for the login page, >>> which just re-directs the user back to the RP with the valid >>> "assertion" >>> fields. idp.spammers.com does not have to ask the user for >>> authentication credentials (that is out of scope for the spec). For >>> commenting on blogs this would be similar to "bugmenot" for web >>> subscription services. >>> >>> So of course, the RP just needs to "blacklist" idp.spammers.com. >>> But >>> now we are back in the same situation we have today where its a race >>> between spammers setting up "IdPs" and RPs "black-listing" them. >> >> I don't understand why the RP needs to do that ... is the RP >> wanting to do something it can't do today? > No, not really. Though in most cases today the RP is also the IDP > so relying on "some other party" to do the authentication doesn't > happen too often (except within certain closely related services). > There is nothing stopping the RP from looking at the URI for the > IDP and not accepting it as a valid IDP. agreed, just like an RP can look at an IP address and decide not to accept it. >> >>> >>> Fundamentally, "trust worthiness" is paramount to making the system >>> work. For now, this means RPs will likely have some sort of ACL >>> (black >>> or white) for the IdPs that they deal with. >> >> The "trust" I am referring to is the user "trusting" the IdP to >> not let someone else impersonate them. > I believe that there is also a need for the RP to "trust" the IdP > to not allow impersonation. >> >> George: would you explain what problem you are wanting to solve so >> that we can deal with a concrete example? There are use cases >> OpenID solves today, and others require additional features that >> currently are not in the specification. > A RP provides a personal finance service that allows users to > manage portfolio information online. It also supports online bill > pay services. This RP requires a set of information for the > "account" to be created at the RP. With the current specs that RP > can accept the authenticated OpenID URI and request the additional > required information. Nothing different here. The issue come in > the form of liability for the RP. Is the RP liable if someone gets > access to someone else's information? In today's world this is the > case partly because the RP is doing its own authentication. If the > RP is "trusting" an IDP to do the authentication (plain, strong, > second factor, etc) then who is liable? I suspect the RP is, > though they might be able to "go after" the IdP. Thus the RP needs > to know which IdPs are "trust worthy" in order to protect its > liability exposure. One of the key innovations of user-centric identity is that the RP and IdP do not need to trust each other. This is initially a tough concept to accept for people that have worked in the security industry. If an RP wants strong authentication, then the RP will request a strong authentication claim, and yes, the RP will need to trust the entity that made that claim. Note that the strong authentication ma
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Dick Hardt wrote: > > On 22-Oct-06, at 7:00 PM, George Fletcher wrote: > >> >> >> Dick Hardt wrote: >>> With OpenID, there is a presumption the user has selected a trust >>> worthy IdP that will only present the user's identifiers when it >>> really is the user. >>> >> Doesn't this imply that both the user and RP have to know which IdP's >> are "trust worthy"? > > It is a choice by the user. Just like the user chooses with ISP to > move their data, which browser to run, which OS to run. IN general, > those are not dictated by the RP. I agree it is the user's choice to pick a "trust worthy" IDP. However, if "un-trust worthy" IDPs exist, and users choose them, then the RP (in order to protect itself) has to determine which IDPs it considers "trust worthy". Hence both the user and the RP "have to know" which IDPs are "trust worthy" and which are not. > >>> Actually, idp.spammers.com cannot do that. The URL has metadata that >>> states which IdP(s) are authoritative. What idp.spammers.com can do is >>> flood an RP with a bunch of identifiers. But this is no different then >>> a script creating new accounts on a system and is defended using the >>> same mechanisms such as throttling and captchas. >>> >> So why can't idp.spammers.com allow anyone to enter a URI of >> http://idp.spammers.com/ that resolves to a valid XRDS document. >> The RP then follows the IdP service link back to >> https://idp.spammers.com and does the association exchange. Now the RP >> re-directs the user to https://idp.spammers.com for the login page, >> which just re-directs the user back to the RP with the valid "assertion" >> fields. idp.spammers.com does not have to ask the user for >> authentication credentials (that is out of scope for the spec). For >> commenting on blogs this would be similar to "bugmenot" for web >> subscription services. >> >> So of course, the RP just needs to "blacklist" idp.spammers.com. But >> now we are back in the same situation we have today where its a race >> between spammers setting up "IdPs" and RPs "black-listing" them. > > I don't understand why the RP needs to do that ... is the RP wanting > to do something it can't do today? No, not really. Though in most cases today the RP is also the IDP so relying on "some other party" to do the authentication doesn't happen too often (except within certain closely related services). There is nothing stopping the RP from looking at the URI for the IDP and not accepting it as a valid IDP. > >> >> Fundamentally, "trust worthiness" is paramount to making the system >> work. For now, this means RPs will likely have some sort of ACL (black >> or white) for the IdPs that they deal with. > > The "trust" I am referring to is the user "trusting" the IdP to not > let someone else impersonate them. I believe that there is also a need for the RP to "trust" the IdP to not allow impersonation. > > George: would you explain what problem you are wanting to solve so > that we can deal with a concrete example? There are use cases OpenID > solves today, and others require additional features that currently > are not in the specification. A RP provides a personal finance service that allows users to manage portfolio information online. It also supports online bill pay services. This RP requires a set of information for the "account" to be created at the RP. With the current specs that RP can accept the authenticated OpenID URI and request the additional required information. Nothing different here. The issue come in the form of liability for the RP. Is the RP liable if someone gets access to someone else's information? In today's world this is the case partly because the RP is doing its own authentication. If the RP is "trusting" an IDP to do the authentication (plain, strong, second factor, etc) then who is liable? I suspect the RP is, though they might be able to "go after" the IdP. Thus the RP needs to know which IdPs are "trust worthy" in order to protect its liability exposure. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Wouldn't it be nice if we could just bypass all the stupid email callback stuff that we usually have to put up with? Its easy to do, the only constraint being that the IdP has to be able to advertise an SRV record. IdP advertises _openid.example.com SRV 1 100 80 openid1.example.com Given an identifier [EMAIL PROTECTED] the RP looks for the _openid service, resolves this works out where to resolve the URI. This does not have to be the only mode of resolution but it is certainly a very very useful one and something that can be used transparently inline with existing practice. Many sites already use the email address form as an identifier. Of course there is a spam issue, there is a spam issue with every contact identifier. That's why you use the IdP account and don't muck up your email account. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt > Sent: Sunday, October 22, 2006 11:14 PM > To: George Fletcher > Cc: specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > > On 22-Oct-06, at 7:00 PM, George Fletcher wrote: > > > > > > > Dick Hardt wrote: > >> With OpenID, there is a presumption the user has selected a trust > >> worthy IdP that will only present the user's identifiers when it > >> really is the user. > >> > > Doesn't this imply that both the user and RP have to know > which IdP's > > are "trust worthy"? > > It is a choice by the user. Just like the user chooses with > ISP to move their data, which browser to run, which OS to > run. IN general, those are not dictated by the RP. > > >> Actually, idp.spammers.com cannot do that. The URL has > metadata that > >> states which IdP(s) are authoritative. What > idp.spammers.com can do > >> is flood an RP with a bunch of identifiers. But this is no > different > >> then a script creating new accounts on a system and is > defended using > >> the same mechanisms such as throttling and captchas. > >> > > So why can't idp.spammers.com allow anyone to enter a URI of > > http://idp.spammers.com/ that resolves to a valid > XRDS document. > > The RP then follows the IdP service link back to > > https://idp.spammers.com and does the association exchange. > Now the > > RP re-directs the user to https://idp.spammers.com for the > login page, > > which just re-directs the user back to the RP with the valid > > "assertion" > > fields. idp.spammers.com does not have to ask the user for > > authentication credentials (that is out of scope for the > spec). For > > commenting on blogs this would be similar to "bugmenot" for web > > subscription services. > > > > So of course, the RP just needs to "blacklist" > idp.spammers.com. But > > now we are back in the same situation we have today where > its a race > > between spammers setting up "IdPs" and RPs "black-listing" them. > > I don't understand why the RP needs to do that ... is the RP > wanting to do something it can't do today? > > > > > Fundamentally, "trust worthiness" is paramount to making the system > > work. For now, this means RPs will likely have some sort of ACL > > (black > > or white) for the IdPs that they deal with. > > The "trust" I am referring to is the user "trusting" the IdP to not > let someone else impersonate them. > > George: would you explain what problem you are wanting to solve so > that we can deal with a concrete example? There are use cases OpenID > solves today, and others require additional features that currently > are not in the specification. > > -- 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 7:00 PM, George Fletcher wrote: > > > Dick Hardt wrote: >> With OpenID, there is a presumption the user has selected a trust >> worthy IdP that will only present the user's identifiers when it >> really is the user. >> > Doesn't this imply that both the user and RP have to know which IdP's > are "trust worthy"? It is a choice by the user. Just like the user chooses with ISP to move their data, which browser to run, which OS to run. IN general, those are not dictated by the RP. >> Actually, idp.spammers.com cannot do that. The URL has metadata that >> states which IdP(s) are authoritative. What idp.spammers.com can >> do is >> flood an RP with a bunch of identifiers. But this is no different >> then >> a script creating new accounts on a system and is defended using the >> same mechanisms such as throttling and captchas. >> > So why can't idp.spammers.com allow anyone to enter a URI of > http://idp.spammers.com/ that resolves to a valid XRDS document. > The RP then follows the IdP service link back to > https://idp.spammers.com and does the association exchange. Now > the RP > re-directs the user to https://idp.spammers.com for the login page, > which just re-directs the user back to the RP with the valid > "assertion" > fields. idp.spammers.com does not have to ask the user for > authentication credentials (that is out of scope for the spec). For > commenting on blogs this would be similar to "bugmenot" for web > subscription services. > > So of course, the RP just needs to "blacklist" idp.spammers.com. But > now we are back in the same situation we have today where its a race > between spammers setting up "IdPs" and RPs "black-listing" them. I don't understand why the RP needs to do that ... is the RP wanting to do something it can't do today? > > Fundamentally, "trust worthiness" is paramount to making the system > work. For now, this means RPs will likely have some sort of ACL > (black > or white) for the IdPs that they deal with. The "trust" I am referring to is the user "trusting" the IdP to not let someone else impersonate them. George: would you explain what problem you are wanting to solve so that we can deal with a concrete example? There are use cases OpenID solves today, and others require additional features that currently are not in the specification. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Dick Hardt wrote: > With OpenID, there is a presumption the user has selected a trust > worthy IdP that will only present the user's identifiers when it > really is the user. > Doesn't this imply that both the user and RP have to know which IdP's are "trust worthy"? > Actually, idp.spammers.com cannot do that. The URL has metadata that > states which IdP(s) are authoritative. What idp.spammers.com can do is > flood an RP with a bunch of identifiers. But this is no different then > a script creating new accounts on a system and is defended using the > same mechanisms such as throttling and captchas. > So why can't idp.spammers.com allow anyone to enter a URI of http://idp.spammers.com/ that resolves to a valid XRDS document. The RP then follows the IdP service link back to https://idp.spammers.com and does the association exchange. Now the RP re-directs the user to https://idp.spammers.com for the login page, which just re-directs the user back to the RP with the valid "assertion" fields. idp.spammers.com does not have to ask the user for authentication credentials (that is out of scope for the spec). For commenting on blogs this would be similar to "bugmenot" for web subscription services. So of course, the RP just needs to "blacklist" idp.spammers.com. But now we are back in the same situation we have today where its a race between spammers setting up "IdPs" and RPs "black-listing" them. Fundamentally, "trust worthiness" is paramount to making the system work. For now, this means RPs will likely have some sort of ACL (black or white) for the IdPs that they deal with. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 5:05 PM, George Fletcher wrote: > > Dick Hardt wrote: >> What is different with OpenID vs email is that there is certainty >> that the user actually is the user. > I'm a little confused. How is there certainty that "the user > actually is the user"? The viability of the identifier > representing the same user is dependent on the OpenID provider not > recycling identifiers. Or did you just mean that in email, > authentication is not always required for someone to use an email > identifier? With SMTP, a bad guy can forge the headers. With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. > > Note that the OpenID protocol does not prevent idp.spammers.com > from allowing any identifier to be used and "authenticated" > regardless of whether it's the same user or not. It is incumbent > on the relying parties to determine if they will allow identifiers > authenticated by a particular idp. Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 2:28 PM, Praveen Alavilli wrote: > > > [EMAIL PROTECTED] wrote: >> For starters please don't use Comic Sans in professional >> correspondence. it is very hard to read (or take seriously) >> http://bancomicsans.com/home.html >> >> >> On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: >>> >>> >>> It's more of a problem with how we can accept 3rd party OpenId >>> users at AOL (we as an RP). Obviously for simple use cases like >>> leaving comments on blogs it wouldn't really matter as long as >>> the user is identified by someone (and someone doing rate >>> limiting or something else to prevent spamming - otherwise I >>> still can't see how it reduces spam anyway) - but when we want to >>> take it to the next level - provide more services to these users >>> (photos/calendar/etc.. ) we want to limit it to only a few IDPs >>> whom we trust. (due to both security and business reasons). >> >> This doesn't really work in the model. The goal is to let anyone >> set up their own OpenID and that basically across the OpenID >> universe it works. You limiting it to only like verisign or other >> 'big' IdP's is not really part of the vision of what we are trying >> to build. Obviously behind this whole network needs to be >> reputation for IdPs and individual OpenID addresses. > I understand it's not the vision of OpenId, but accepting > identities from everyone else in the world is not going to happen > in "reality". It will in my "reality" :-) > Obviously there is no reputation service built by trusted vendors > (similar to CAs) yet. We need a short term solution atleast (though > we all hate short term solutions) if we really want OpenId to be > supported by big players - isn't it ? >> >>> So this is the problem we are trying to figure out how we can >>> message the users that we support OpenIds from certain providers >>> (say Verisign PIP) but not from all. >> >> This is one way to approach it and I hope you don't do it this way >> because it breaks what OpenID is about. > Well, it really depends on what else OpenIds are going to be used > for. As I said, if it's just the blogging domain I don't think > there are any issues. If we want to start pushing OpenId into a > trusted and secure authentication domain (I really think it > should), some changes need to happen. Although "Reputation" is a > good solution but unfortunately Reputation for IDPs or user URI's > is not going to build over night. It changes the way how web apps > and users got used to traditionally. Today as an example, I can > goto AOL Personal Finance, create an account, setup my financial > accounts, bill pay, etc.. with in few mins. And they could do the same thing with OpenID. The difference would be they would not need to create a password, and could click buttons to provide a bunch of the profile data. There really is little difference except for the automation. >>> >>> Another area where we want some more clarification (if it already >>> exists) or support is about how we can have a persistent handler >>> (apart from URI) for a given user so it would help in cases when >>> a user's account gets reclaimed by someone else. >> >> ahh...that is where further reading of what i-names and i-numbers >> are about would help. Because there is another level of >> indirection built in, when an i-name is reassigned the i-number >> below it is not. This helps users not have the 'reclaiming by >> someone else problem' when depending on URLs. > Actually there were 2 things I was trying to point on in my > previous mail (sorry I was not clear). One is the persistent id, > which would probably be satisfied with i-numbers (even though I was > looking more for optimization by including it as part of the > authentication response itself) and second is the PPID (or LUID or > SUID or whatever people refer to them in different protocols/ > specs), which is not just an i-number but it's an id that's > different for each RP such that users cannot be tracked across > different sites. There are "portable identifiers". URLs that the user controls that they can point to whichever IdP they want. There are also "directed identifiers". URLs generated by the IdP and managed by the IdP for each RP. In other words, there is a separate identifier for each RP so that RPs cannot correlate data. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Dick Hardt wrote: > > On 20-Oct-06, at 10:14 AM, George Fletcher wrote: >> >> Of course, my expectation is that this syntax would be optional; the >> user can always specify their full URI identifier. >> >> I agree that this kind of an identifier is not portable, but I'm >> guessing that most users wouldn't know how to tweak their blog to add >> the necessary OpenID 1.1 HTML code to change their IDP. Most users, >> just use flickr for photos and if flickr supported OpenID, could >> potentially use some URI defined for them by flickr as an OpenID >> identifier. This identifier from flickr would not be very easily >> portable. > > My understanding of the proposal from David was that this was a way to > discover the user's IdP, not that the email was an identifier. > > -- Dick > Sorry to imply that email should be a valid identifier. That wasn't my intent. I'm fine with where this discussion is headed (and has headed in the past; after reading the old threads). For wide spread adoption it will be very important to have a "If you're not sure what to enter, click here" link on the login form to try and explain to users what they might be able to try as identifiers. My comment was really trying to speak to the issue of identifier portability. Is there an OpenID definition for this? If I have an OpenID provided by SomeSite as http://george.somesite.com, then how is that identifier portable? For it to be portable, somesite.com would have to allow me to either (a) change the HTML code of my "public page" (though if I read the draft 2.0 spec correctly, the HTML method is deprecated) or (b) provide some mechanism where I could change the IDP service URL returned in the XRDS document. If somesite.com does not provide either of these mechanisms, then this identifier is not "portable". Also, the viability of my identifier may be dependent on the service. For instance, somesite.com may have a rule that says if I delete my SomeSite "account", then they will no longer authenticate my identifier. Of course, user choice always enters in and I can choose to not use that service as my OpenID identifier provider. The "i-names" infrastructure does solve some of this by focusing on the identity management issues. Though here I'm paying explicitly for this "portability" service (along with others). Thanks, George P.S. Should this discussion get moved to the "general" list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
[EMAIL PROTECTED] wrote: For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.html On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons). This doesn't really work in the model. The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works. You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build. Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses. I understand it's not the vision of OpenId, but accepting identities from everyone else in the world is not going to happen in "reality". Obviously there is no reputation service built by trusted vendors (similar to CAs) yet. We need a short term solution atleast (though we all hate short term solutions) if we really want OpenId to be supported by big players - isn't it ? So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about. Well, it really depends on what else OpenIds are going to be used for. As I said, if it's just the blogging domain I don't think there are any issues. If we want to start pushing OpenId into a trusted and secure authentication domain (I really think it should), some changes need to happen. Although "Reputation" is a good solution but unfortunately Reputation for IDPs or user URI's is not going to build over night. It changes the way how web apps and users got used to traditionally. Today as an example, I can goto AOL Personal Finance, create an account, setup my financial accounts, bill pay, etc.. with in few mins. If we are going to start providing the services to the user based on their Reputation scores, it changes the complete model - as a user do I need to wait for a long time before I can actually use all the cool features provided by AOL Personal Finance and do I constantly need to worry about someone mistakenly causing negative reputation on my account? May be I am over complicating but that doesn't sound easy and can be built quickly. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. ahh...that is where further reading of what i-names and i-numbers are about would help. Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not. This helps users not have the 'reclaiming by someone else problem' when depending on URLs. Actually there were 2 things I was trying to point on in my previous mail (sorry I was not clear). One is the persistent id, which would probably be satisfied with i-numbers (even though I was looking more for optimization by including it as part of the authentication response itself) and second is the PPID (or LUID or SUID or whatever people refer to them in different protocols/specs), which is not just an i-number but it's an id that's different for each RP such that users cannot be tracked across different sites. thx Praveen __ Identity Woman: Saving the world with user-centric identity. www.identitywoman.net = ___ 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Dick Hardt wrote: > What is different with OpenID vs email is that there is certainty > that the user actually is the user. > I'm a little confused. How is there certainty that "the user actually is the user"? The viability of the identifier representing the same user is dependent on the OpenID provider not recycling identifiers. Or did you just mean that in email, authentication is not always required for someone to use an email identifier? Note that the OpenID protocol does not prevent idp.spammers.com from allowing any identifier to be used and "authenticated" regardless of whether it's the same user or not. It is incumbent on the relying parties to determine if they will allow identifiers authenticated by a particular idp. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.htmlOn Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons).This doesn't really work in the model. The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works. You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build. Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses. So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. ahh...that is where further reading of what i-names and i-numbers are about would help. Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not. This helps users not have the 'reclaiming by someone else problem' when depending on URLs. __Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
[Please pardon me if I am spamming the spec mailing list with general comments/issues that might have been discussed before] It's not the problem of just making AOL users OpenId enabled, so they can access 3rd party RPs (use http://www.aol.com/ or http://aimpages.com/ or http://journals.aol.com/, etc) - as someone else said it's a matter of educating the users (even if it takes long time based on user's geek level - because pretty much every IDP out there today tries to educate users about how to make sure they are not entering their credentials at a phishing site, but it still happens). It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons). So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. Obviously we can just follow the existing model of a free form field that says "Enter your OpenId" but most of the time we will end up failing the users saying "we don't accept your OpenId". Just bad user experience in our opinion. So instead we want to somehow message the user saying these are the only IDPs we trust - whether showing a drop down list of IDPs on the login form or something else, we want to see a standard way of doing it so user's don't feel like they are in an alien world from one RP to another (ofcourse keeping aside the phishing issues). We totally agree that adding another option to the already confusing list of account types is a bad idea. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. Instead of it being an additional attribute that IDP can advertise as supported (which an RP can get via the Attribute Exchange protocol), if it can be baked into the "authentication" response, itself as a required field, it would help in having a common way of doing a locally stored identity discovery. If it can be generated similar to how PPID (Private Personal Identifier) is generated dynamically by Infocard it would be a great addition to OpenId IMO. thx =Praveen.alavilli [EMAIL PROTECTED] wrote: On 20-Oct-06, at 12:17 PM, John Panzer wrote: Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea. 1) If you put something out into the market that looks like an e- mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, while being open to new practices. Once we can support both we can gain experience and start gradually migrating people over to the new world. At least that's my take. I empathize with your problem John, but I agree with Kaliya and others. Lets take another step back and envision what the login box prompt will say. In OpenID 1.x it was: "Enter your OpenID" With some text to explain what an OpenID was. With OpenID 2.0, we have something like: "Homesite | i-name | OpenID" (Homesite being more user friendly then
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 11:44 AM, Praveen Alavilli wrote: > It's more of a problem with how we can accept 3rd party OpenId > users at AOL (we as an RP). Obviously for simple use cases like > leaving comments on blogs it wouldn't really matter as long as the > user is identified by someone (and someone doing rate limiting or > something else to prevent spamming - otherwise I still can't see > how it reduces spam anyway) - but when we want to take it to the > next level - provide more services to these users (photos/calendar/ > etc.. ) we want to limit it to only a few IDPs whom we trust. (due > to both security and business reasons). So this is the problem we > are trying to figure out how we can message the users that we > support OpenIds from certain providers (say Verisign PIP) but not > from all. Obviously we can just follow the existing model of a free > form field that says "Enter your OpenId" but most of the time we > will end up failing the users saying "we don't accept your OpenId". > Just bad user experience in our opinion. So instead we want to > somehow message the user saying these are the only IDPs we trust - > whether showing a drop down list of IDPs on the login form or > something else, we want to see a standard way of doing it so user's > don't feel like they are in an alien world from one RP to another > (ofcourse keeping aside the phishing issues). We totally agree that > adding another option to the already confusing list of account > types is a bad idea. OpenID Authentication allows you to know it is the same user that you saw last time. In many ways, it is an automated mechanism for public sites that allow anyone to create an account by selecting a username and a password. Limiting users to come from only a small set of IdPs is like limiting which ISPs can connect to your website -- it is not the user-centric model. For example, if you have not seen an identifier before, you may require them to enter a captcha. When you see them again, and if they did not do something *bad*, then you may not need to prompt them for the *captcha* again. What is different with OpenID vs email is that there is certainty that the user actually is the user. With email, there is no certainty that the from: field really is who sent the message, which is what a number of protocols in the SMTP world are working to resolve.. Just like in the battle with spam, once you have the identity of the user, then you can have 3rd party assertions from someone you trust (if needed) to have more data about the user. For example, there may be a service provider that asserts that a given identifier belongs to a user that has a *good* reputation. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote: > For starters please don't use Comic Sans in professional > correspondence. it is very hard to read (or take seriously) http:// > bancomicsans.com/home.html Kaliya: The easy solution is to have your email program turn all responses to plain text. :-) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
While I'd certainly agree that a goal is letting anyone setup and IdP and have it work on any RP, I see that as utopia. The protocol should certainly support that, as well as not do anything to actively thwart it. With that said, OpenID as a protocol can be used in cases where this may not be desired. I agree that the best way to look at this is by creating a distributed trust/reputation network. This thus allows a RP to intelligently make a decision of if it should accept a given identifier, or the IdP it is hosted on. Right now I see this as needed to really bootstrap large scale adoption. Any word from Karmasphere about something like this Meng? --David P.S. Plain-text kills all fonts. :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kaliya Hamlin Sent: Sunday, October 22, 2006 3:43 PM To: specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.html On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons). This doesn't really work in the model. The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works. You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build. Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses. So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. ahh...that is where further reading of what i-names and i-numbers are about would help. Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not. This helps users not have the 'reclaiming by someone else problem' when depending on URLs. __ Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 20-Oct-06, at 10:14 AM, George Fletcher wrote: > [Sorry for the strange posting format. I got on the list after > seeing the emails. --George] > > First, I'm new to the list and don't want to resurface an old and > long debated topic. > > To me this proposal is about how to make finding the user's IDP > simpler using something the customer is already familiar with. > Therefore, the email address format in not an identifier, but > rather a way to hint to the RP both my IDP and an identifier to use > at the IDP. The desire being to address current user behavior > which doesn't include specifying a URI as a login mechanism. I > don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft. > Trying to educate "the masses" to remember a new identifier, that > for some is meaningless (i.e. the user might not have a blog or > other URL that they are used to remembering or sharing), is difficult. See email to John. I think the user is already familiar with typing in a domain name to get to a site. They can type in yahoo.com, google.com or aol.com to get to their prospective homesite. > > As another option, the RP could present UI that has a drop down of > "common IDPs" and then based on the selected "common IDP" provide > another text entry for that IDP's form of identifer. However, that > somewhat defeats the purpose of trying to have a very simple form > entry mechanism which customers can get used to seeing and feel > comfortable with. It also places a burden on the RP to keep their > UI up-to-date. LOL ... and who would determine who the "common IdPs" are? :-) ... I can envision many enterprises managing their employees identity. > > Of course, my expectation is that this syntax would be optional; > the user can always specify their full URI identifier. > > I agree that this kind of an identifier is not portable, but I'm > guessing that most users wouldn't know how to tweak their blog to > add the necessary OpenID 1.1 HTML code to change their IDP. Most > users, just use flickr for photos and if flickr supported OpenID, > could potentially use some URI defined for them by flickr as an > OpenID identifier. This identifier from flickr would not be very > easily portable. My understanding of the proposal from David was that this was a way to discover the user's IdP, not that the email was an identifier. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 20-Oct-06, at 12:17 PM, John Panzer wrote: > Kaliya * wrote on 10/20/2006, 11:57 AM: > >> I think it is a terrible idea. >> >> 1) If you put something out into the market that looks like an e- >> mail it will be used like an e-mail. I have personal experience >> with this. >> >> I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] >> (it was not an e-mail address) but because it looked like one >> people used it like one and I basically had to go to .mac and pay >> for an account so that the wires did not cross. > This came out of the discussions we have about a smooth migration > path for our users at AOL. In our case the [EMAIL PROTECTED] > nickname is also a resolvable email address, though it may not be > the primary mail account of the user. I'd suggest that as a best > practice, anywhere that a [EMAIL PROTECTED] nickname is used, it > should also be a resolvable email address. And there should always > be an option to not use something that looks like an email address. >> 2) I think OpenID is new and needs a new way to identify folks. >> And it is our job to teach people about this new way. Lots of >> services give people homepages within their spaces...myspace, >> AIMpages etc. so they can use those URL's if they don't have one >> yet they can get one. > There's a bootstrapping problem here. It's very, very hard to > promote the use of something that requires a more complex login > flow to replace something that is very simple (albeit limited and > in its own silo). How can we cross this chasm? Our suggestion is > to support existing practice of [EMAIL PROTECTED] in a standard way, > while being open to new practices. Once we can support both we can > gain experience and start gradually migrating people over to the > new world. At least that's my take. I empathize with your problem John, but I agree with Kaliya and others. Lets take another step back and envision what the login box prompt will say. In OpenID 1.x it was: "Enter your OpenID" With some text to explain what an OpenID was. With OpenID 2.0, we have something like: "Homesite | i-name | OpenID" (Homesite being more user friendly then IdP) All of these items are new things to users, and the user either has one or does not. If we support email addresses, then the prompt may look something like this: "email | Homesite | i-name | OpenID" Now any user with an email address thinks they can type it into the box and login. This of course is not going to be the case. I think the most straightforward method for your users is to educate them that AOL is now a homesite, and they can type in aol.com into the box. This user experience then is very similar to the user typing in aol.com into the address bar. They get sent to aol.com which will then prompt them for [EMAIL PROTECTED] Given that you need to educate them that they can do something new to begin with, this seems to be the most straightforward path. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
We actually built some code some time ago to explore this. The basic insight was: if we can do Yadis discovery on XRIs (which aren't rooted in DNS), then we can do Yadis discovery on any other kind of identifier, whether it's an e-mail address or an ISBN number or what have you -- and once we have a Yadis file for a given identifier, we are home free because it essentially maps that identifier into HTTP. We considered three or four different ways of doing Yadis resolution from e-mail addresses and the like, including the http:// [EMAIL PROTECTED]/ idea that David mentions; under the hood they are different, but what the user sees is the same. Usability is the key problem here: - we confuse the user because suddenly it's not URL-based identity any more - we confuse the user because users aren't clickable any more (except for a mailto: tag, which is confusing in its own right it most identities pop up a blog or home page) - we confuse the user because if I type the identifier into by browser's address bar, it pops up a phishing warning (!) instead of the user's home page. We decided that for the time being, it was going to be much easier to educate users on the need to use URLs as identifiers, than to educate users to not be confused by the above behaviors. The situation would change if, say, Mozilla and MSFT were performing Yadis discovery on e-mail-style identifiers, and directed the user to their (http) home page from a given e-mail address. Not impossible to imagine, but certainly not something to expect any century from now. On Oct 20, 2006, at 13:44, Jonathan Daugherty wrote: # I'm not actually proposing the IdP make an assertion about # [EMAIL PROTECTED] It would only be used during the discovery phase # and then an assertion for a URL be returned. Ok, I misunderstood. But even in the case where the IdP makes an assertion about a different identifier, that's confusing, too; you enter something that looks like an email (and maybe your provider tells you it even is), but you log into the site as something else, right? -- Jonathan Daugherty JanRain, Inc. ___ 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
# I'm not actually proposing the IdP make an assertion about # [EMAIL PROTECTED] It would only be used during the discovery phase # and then an assertion for a URL be returned. Ok, I misunderstood. But even in the case where the IdP makes an assertion about a different identifier, that's confusing, too; you enter something that looks like an email (and maybe your provider tells you it even is), but you log into the site as something else, right? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
I'm not actually proposing the IdP make an assertion about [EMAIL PROTECTED] It would only be used during the discovery phase and then an assertion for a URL be returned. --David -Original Message- From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 2:57 PM To: George Fletcher Cc: Recordon, David; specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers # It might create some confusion depending on the audience. For the # audience that doesn't run their own web server, or have their own # blog, it might be confusing to enter a URI. By confusion, I mean entering something that looks like an email but probably isn't, and trying to figure out just what the relationship between email-looking things and email addresses really is. And seeing an RP render an email-like thing with "http://"; on the front and "/" on the end. The biggest subset of our prospective audience is the one that is not going to readily understand this, and that is going to create a lot of confusion. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
This all depends on whether OpenIDs are going to be used exclusively as hooks for attributes or as a contact mechanism. I think that there will inevitably be demand to use the identifiers as contact addresses. The question is how this need is going to be met in a way that prevents people being spammed to death. I don't see how anyone is going to pay to be =drummond if they are the only person who is ever going to type the text in. The idea makes no sense since anyone who cares about what they type in can get a plug in that provides a pretty name for free. Ergo we are talking about contact addresses and on the Internet that means email addresses. I am willing to watch people spend large amounts of money attempting to prove otherwise. I am not going to throw roadblocks in their way to the tar pit. All I want is the ability to say to people 'I told you so' afterwards. And to offer email addresses on an equal basis with XRIs. In other words I am quite happy for others to jump into what I believe to be a tar pit and splash around. What I object to is being tied to them. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John PanzerSent: Friday, October 20, 2006 3:17 PMTo: Kaliya *Cc: specs@openid.netSubject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea.1) If you put something out into the market that looks like an e-mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, while being open to new practices. Once we can support both we can gain experience and start gradually migrating people over to the new world. At least that's my take.-- John PanzerSystem Architecthttp://abstractioneer.org ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 10/19/06, Recordon, David <[EMAIL PROTECTED]> wrote: > 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. Here are the past threads that I could find about this issue: 1. http://lists.danga.com/pipermail/yadis/2005-May/000412.html 2. http://lists.danga.com/pipermail/yadis/2005-June/000501.html 3. http://lists.danga.com/pipermail/yadis/2005-July/001113.html 4. http://lists.danga.com/pipermail/yadis/2005-November/001589.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On 10/20/06, John Panzer <[EMAIL PROTECTED]> wrote: Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea. 1) If you put something out into the market that looks like an e-mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address.Why not just give them @aol*username. or http://www.aol.com/username. Both are valid openID and it is NOT and e-mail address. I bet you have a tone of users who simply have AOL handles for IM and don't want to activiate or deal with e-mail systems. I get that your users are 'naive' and don't get new things and some don't know how to scroll. BUT YOU CAN EDUCATE THEM. at one point e-mail didn't exist and we had to teach people about that. I explain this stuff to normal folks all the time these days. I think regular folks are willing to learn this stuff to make the web safer and more convenient for them. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, This "e-mail is the standards way" is false. It really is not user fridnely. I resent sites asking me for my e-mail and requiring me to use it as a login. I have at least 4 e-mails. I use different ones a different sites and can't remember which one I use were. I am all for figuring out Bootstrapping but I think approach is miss guided. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea. 1) If you put something out into the market that looks like an e-mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, while being open to new practices. Once we can support both we can gain experience and start gradually migrating people over to the new world. At least that's my take. -- John Panzer System Architect http://abstractioneer.org ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
I think it is a terrible idea.1) If you put something out into the market that looks like an e-mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. 3) Giving folks i-names is an option too. URLs do certain things well...XRI alows people to migrate from @AOL*julie to =julie and basically maintain the same identifier (The i-number behind it).4) We need to follow the creative commons lead and have lots of different ways of explaining the new way to people. It is not that complex. I explain it to normal people all the time. We are getting the right metaphors and ways to talk about them. We should do some little videos adn comic strips to explaing this new way. I think it is the task of the OpenID Community Org to produce such things. =Kaliya ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
# It might create some confusion depending on the audience. For the # audience that doesn't run their own web server, or have their own # blog, it might be confusing to enter a URI. By confusion, I mean entering something that looks like an email but probably isn't, and trying to figure out just what the relationship between email-looking things and email addresses really is. And seeing an RP render an email-like thing with "http://"; on the front and "/" on the end. The biggest subset of our prospective audience is the one that is not going to readily understand this, and that is going to create a lot of confusion. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
It might create some confusion depending on the audience. For the audience that doesn't run their own web server, or have their own blog, it might be confusing to enter a URI. This approach would help those users make the transition without restricting the users who do "get it" from entering URIs. It also provides a simple way for RPs to appeal to a larger set of users (e.g. my mother-in-law wouldn't understand what to enter if asked for a URI based identifier). Thanks, George P.S. Hopefully I've got Thunderbird sending plain text messages now so they don't get "scrubbed" in the archives. Sorry about that. Recordon, David wrote: > Yes, potentially. It is a bit of a hybrid approach I guess. > > --David > > -Original Message- > From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] > Sent: Friday, October 20, 2006 12:59 PM > To: Recordon, David > Cc: Drummond Reed; specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > Identifiers > > # The thing is they aren't really giving them their email address. > # Rather an identifier which looks like an email address to a user and # > in some cases may also be an email address. > > Isn't that likely to create a lot of confusion? > > -- > 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] Handle "http://[EMAIL PROTECTED]" Style Identifiers
[Sorry for the strange posting format. I got on the list after seeing the emails. --George] First, I'm new to the list and don't want to resurface an old and long debated topic. To me this proposal is about how to make finding the user's IDP simpler using something the customer is already familiar with. Therefore, the email address format in not an identifier, but rather a way to hint to the RP both my IDP and an identifier to use at the IDP. The desire being to address current user behavior which doesn't include specifying a URI as a login mechanism. I don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft. Trying to educate "the masses" to remember a new identifier, that for some is meaningless (i.e. the user might not have a blog or other URL that they are used to remembering or sharing), is difficult. As another option, the RP could present UI that has a drop down of "common IDPs" and then based on the selected "common IDP" provide another text entry for that IDP's form of identifer. However, that somewhat defeats the purpose of trying to have a very simple form entry mechanism which customers can get used to seeing and feel comfortable with. It also places a burden on the RP to keep their UI up-to-date. Of course, my expectation is that this syntax would be optional; the user can always specify their full URI identifier. I agree that this kind of an identifier is not portable, but I'm guessing that most users wouldn't know how to tweak their blog to add the necessary OpenID 1.1 HTML code to change their IDP. Most users, just use flickr for photos and if flickr supported OpenID, could potentially use some URI defined for them by flickr as an OpenID identifier. This identifier from flickr would not be very easily portable. Thanks, George 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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 6:46 PM To: specs at 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 "user at example.com" 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 "user at example.com" 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Yes, potentially. It is a bit of a hybrid approach I guess. --David -Original Message- From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 12:59 PM To: Recordon, David Cc: Drummond Reed; specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers # The thing is they aren't really giving them their email address. # Rather an identifier which looks like an email address to a user and # in some cases may also be an email address. Isn't that likely to create a lot of confusion? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
# The thing is they aren't really giving them their email address. # Rather an identifier which looks like an email address to a user and # in some cases may also be an email address. Isn't that likely to create a lot of confusion? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
The thing is they aren't really giving them their email address. Rather an identifier which looks like an email address to a user and in some cases may also be an email address. In terms of privacy, if it is known that the OpenID Identifier scheme is http://example.com/username then it is trivial for a RP to change that into an email address [EMAIL PROTECTED] even if the user never entered that directly. On the response from the IdP, the IdP would not assert that the user owns [EMAIL PROTECTED] Rather it would perform the normal directed identity flow returning an actual URL. Take this format of identifier as: 1) Format users already type 2) Easy for RP to start directed identity flow 3) Pass to IdP as a "hint" for who the user needs to authenticate as --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 1:04 AM To: Recordon, David; specs@openid.net Subject: 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: [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: [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