Re: Using email address as OpenID identifier
this discussion, of course, has happened before: http://openid.net/pipermail/specs/2008-January/002104.html And paul is correct, IMHO... NAPTR is a better and more flexible way to address this. The original proposal had regex expressions in TXT RRs. which, while not improper, does not have a resolver code base to draw from, and some well-laid groundwork for regex processing libraries for resolvers to use. on the other hand, i've never want to use my email address as my openID, and you'd have to write a new profile which allowed the OP/RP to understand i can prove ownership of the identifier. =peterd On Apr 9, 2008, at 2:14 PM, Paul E. Jones wrote: James, I don't think we need SRV records to do this. NAPTR would suffice, as that would allow one to transform one string into another. But, it seems that there is an overwhelming preference for using some kind of string of undetermined structure to identify a user which is not of an e-mail format. (I know there is an intent to use a URI, but most users have no idea what a URI is and few really type them properly.) So, while I still think the form [EMAIL PROTECTED] is better for the user world-wide community, I understand the counter-arguments. And, perhaps I'll be proven wrong-- which is OK. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Monday, April 07, 2008 3:21 PM To: specs@openid.net Subject: Using email address as OpenID identifier This would require defining an OpenID SRV record in DNS. Would make sense for someone to get this formally defined as part of IETF. Could kinda be done in the same way that Boeing is moving forward definition of XRI in LDAP.. -Original Message- Message: 1 Date: Mon, 07 Apr 2008 18:56:57 +0100 From: Martin Atkins [EMAIL PROTECTED] Subject: Re: Using email address as OpenID identifier To: specs@openid.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Paul E. Jones wrote: Perhaps it is important to say, though, that I do not think it requires the e-mail providers to get on board with this (in my view) simpler notation. I could use an ID like [EMAIL PROTECTED] and that should work, if myopenid.com would publish the appropriate NAPTR record. I could also insert NAPTR records into the packetizer.com DNS server that would allow me to use my email address, but point at my preferred OpenID provider. In short, just because the [EMAIL PROTECTED] syntax is used does not mean that it necessarily an e-mail address: it could be, but more importantly, it just follows that familiar format documented in RFC 822. Funnily enough, I've always percieved the fact that syntactically- valid but non-existant email addresses are being used as identifiers as a problem rather than a benefit: * It creates confusion for users when something looks like an email address but it doesn't behave as one. I've seen this sort of confusion with Jabber servers, where users get confused that their Jabber ID and email address are not the same, especially when Jabber clients say For example, [EMAIL PROTECTED] under the Jabber ID field. * If not all email-shaped OpenID identifiers are actually working mailboxes, it's likely to lead to a distressing user experience where the user is first asked to enter their OpenID identifier -- that is, their email address -- and then they're asked to enter and verify their email address. At this point, I expect users to at best say Stupid computer! Remember what I've told you! and at worst get confused and think that the OpenID identifier they entered was not correct. * As has often been raised in both the OpenID-with-email and in the Jabber circles, many people are reluctant to give up their email addresses to the public eye for fear of spam. Note that Yahoo.com will, by default, use a big opaque string as an identifier rather than the user's Yahoo! account name for this very reason. * ** ** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ** ** ___ 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: Service Key Discovery 1.0
FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ 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: OpenID Email Discovery
On Jan 3, 2008, at 6:03 PM, Hallam-Baker, Phillip wrote: NAPTR is an ietf proposed standard but there is no deployed base. well, there certainly are deployed bases where i sit, since we have DNS zones in operation with well over 40M entries... most of which are NAPTR RR's, and many, many users of these services. The reason i made the suggestion, however, is that the proposed solution (of using TXT RRs) showed examples of regx like functions for resolvers to post-process... which is precisely what NAPTR RRs were intended to provided (among other things) and that use of TXT RRs are being discouraged. the SRV RR does not provide any facilities for regx-like answers. =peterd ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Email Discovery
actually, NAPTR RR's would be a better fit, as the unique-part of an openID may be in the local-path part of a URI, not the hostname... of course, if a users openID changes, so too might their underlying DNS name, and then DNS won't help you at all there. XRI is better situated to solve that use case. =peterd On Jan 3, 2008, at 4:48 PM, Hallam-Baker, Phillip wrote: This is the function of the existing DNS SRV record. _openid.example.com SRV 1 1 1 1 openid1.example.com The Internet has an architecture already. Use it, don't try to reinvent it. From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav Sent: Thu 03/01/2008 4:01 PM To: 'OpenID specs list' Subject: OpenID Email Discovery (The full story is posted at http://www.hueniverse.com/hueniverse/ 2008/01/addressing-open.html but this contains the technical parts of the post). This proposal adds Email Discovery allowing users to use their email address as an OpenID. … We need to map between the email to the OpenID identifier and this is where DNS comes in. DNS already has a system for resolving email addresses into an actual server – email resolution using an MX record. Why not add a new record type for OpenID. Basically another way to perform OpenID discovery that is all about making it user- friendly. All that is needed is a URL the site performing discovery can append the email to and treat it as an OpenID identifier. This can be done using a OpenID TXT record: ‘OpenID [username rule] [priority] [URL]’ where [username rule] is a wildcard expression used to match the username part of the email (everything up to the [EMAIL PROTECTED]), [priority] is the MX-like priority value, and [URL] is the URL used to generate the OpenID identifier. The URL uses ‘*’ to indicate where the username is inserted, and ‘**’ to indicate where the full, URL-encoded, email address is inserted (both optional). For example: example.com TXT ‘OpenID * 10 http://*.example.com/’ example.com TXT ‘OpenID joe 10 http://example.org/openid?**’ Which reads: for any email address [EMAIL PROTECTED] other than ‘joe’ use ‘http://username.example.com/’ as the OpenID identifier. For email address [EMAIL PROTECTED] use ‘http://example.org/openid?joe% 40example.com’ as the OpenID identifier. Rules are processed first based on the username rule match (in order of match closeness) and then on priority which is used in the same manner as MX records priority. … There are many ways to implement identity delegation, but in the context of email identifiers and simplifying the user experience, the idea is to move the delegation mapping to the OpenID provider. When users sign-up for a new OpenID, they will be given the option, perhaps as a premium paid service, to make the OpenID provider map incoming identity checks for the user email address with their local OpenID identifier. So instead of the users telling the site about their local identity (using delegation), the OpenID provider will perform the mapping. In the above example, [EMAIL PROTECTED] has his OpenID managed by ‘example.org’. When signing up for an OpenID at ‘example.org’, Joe asked it to accept identity requests for [EMAIL PROTECTED] or at least provide delegation discovery. When Joe tries to log into an OpenID-enabled site using [EMAIL PROTECTED], the site convert the email address to the URL ‘http://example.org/openid?joe% 40example.com’ and use it like a regular OpenID identifier. ‘example.org’ will reply with the needed discovery information to get Joe authenticated using the OpenID protocol. By using the ‘**’ symbol, the full email address is sent over to the OpenID provider which can perform mapping of identities other than its own local ones. This can be viewed as hosted delegated identity where the OpenID provider also provides hosting of the OpenID delegation information for the user. It doesn’t require any new standards except for implementation and support by OpenID providers. --- Would love to get some feedback. Thanks, EHL ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
