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: [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 domain + tld 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: IdP's Advertising Both http and https
On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote: -Original Message- From: Recordon, David But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) no warning on GET redirects If GET is going to be an acceptable method for responses, the spec should be updated. Section 5.2.1. HTTP Redirect states: This method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility. Yes/no? -Rowan ___ 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: 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, 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
Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
Hey David, Thanks for your ideas. Some more thoughts below. -Original Message- From: David Nicol [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 6:49 PM To: David Fuelling Cc: Martin Atkins; specs@openid.net; [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers On 11/9/06, David Nicol [EMAIL PROTECTED] wrote: http://[EMAIL PROTECTED] (cool addy, btw) certainly won't get anyone to David Fuelling's home page, now or in any likely future. True, http://[EMAIL PROTECTED] won't get anyone to my homepage...but it would get me to my IdP (assuming Google was my IdP, and offered such a scheme). Ideas: (1) define a way to include an e-mail address among the things obtainable with an OpenID authentication, and a transform to provide a default when none is declared I think the OpenID Simple Registration Extension will provide for this (If I understand what you're meaning) http://openid.net/specs/openid-simple-registration-extension-1_0.html (2a) declare that OpenID does not do e-mail based authentication and never will I hope this can get some more debate in some form or fashion. :) (2b) name some other mechanism for e-mail based authentication and include it by reference, blessing said method by so doing. I think that all this discussion about email userid is moving us off track. My original proposal was that the email maps/normalizes to a URL of an IdP (the userid is ignored/not used). So, '[EMAIL PROTECTED]' would be treated as if the User had entered 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form. Once the user agent is redirected to the 'any.edu' IdP, the IdP would be responsible for figuring out which user is trying to login to the IdP (this is already allowed by OpenId since we can enter a homesite/IdP/OP URL into the login form). The OP might authenticate me by biometric (voice, fingerprint, DNA Sample, etc), or some other scheme, making the username portion of my email irrelevant. Just to be clear, I'm **not** advocating that an email get transformed into a URL that includes the userid of the email (although, I'd be open to entertaining the notion). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
# I think that all this discussion about email userid is moving us off # track. My original proposal was that the email maps/normalizes to a # URL of an IdP (the userid is ignored/not used). # # So, '[EMAIL PROTECTED]' would be treated as if the User had entered # 'http://any.edu' (the URL of their IdP/OP) into the OpenId login # form. Then why not just enter 'http://any.edu' or 'any.edu' instead? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
