Re: [OpenID] OpenID Extension to handle Emails Addresses?
David Fuelling wrote: I would even entertain the notion of the OpenID extension doing DNS lookup first, then EAUT, though I need to think more on the topic. Alternatively, maybe we make DNS optional. At this point I'll throw in my more recent post about why DNS must be supported and must be the primary mode, with others as fallback: http://www.apparently.me.uk/18285.html However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) The finer points of how we get there don't bother me that much. Being able to optionally redirect email addresses to URLs just as we can currently redirect URLs to other URLs would be good and consistent with the OpenID model that exists today. Preserving the ability to do delegation would be good so that I can use email addresses in my vanity domain without running my own OP. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins [EMAIL PROTECTED]wrote: David Fuelling wrote: I would even entertain the notion of the OpenID extension doing DNS lookup first, then EAUT, though I need to think more on the topic. Alternatively, maybe we make DNS optional. At this point I'll throw in my more recent post about why DNS must be supported and must be the primary mode, with others as fallback: http://www.apparently.me.uk/18285.html Very interesting points in your blog post!! It has me wondering the following questions: 1. The arguments about using DNS could apply to OpenID in general. However, OpenID doesn't do anything with DNS. Why is this? What were the compelling reasons to not use DNS with OpenID? Is there an FAQ page somewhere about that? I have only vague recollections on the topic. 2. Do some of the larger email providers have an opinion on the mechanism used for Discovery in the email case? For instance, would Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based discovery be consulted first? Do they even care? However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) What if the user actually wants their URL to be the claimed identifier? Would you be open to that? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
David Fuelling wrote: 1. The arguments about using DNS could apply to OpenID in general. However, OpenID doesn't do anything with DNS. Why is this? What were the compelling reasons to not use DNS with OpenID? Is there an FAQ page somewhere about that? I have only vague recollections on the topic. When you have an HTTP-based identifier, I think it makes sense to use HTTP to resolve it. So, just as with any other HTTP transaction, you: * As the DNS for the server that handles HTTP for the domain. (Which the A record in the domain has become the de-facto standard for, for better or worse. It'd be good if it were a SRV record, but whatever.) * You ask the HTTP server what's at the path given in the URL. * The response tells you the OpenID discovery information or, in the Yadis case, where to find the discovery information. Now, you could argue (and people have argued) that using the MX record to find the mail server and somehow asking the mail server for the discovery information would be sensible. However, I would argue that this is overloading the concept of mail exchanger -- we don't use the MX record to discover IMAP or POP3 services either -- and that realistically speaking asking people to alter their SMTP server software is a complete non-starter. You could also reasonably argue that my proposal of resolving [EMAIL PROTECTED] as mart.degeneration.co.uk is a layering violation, since the username part does not belong in the DNS. I wouldn't mind losing that if someone has an alternative proposal for making delegation work. (One such proposal would be to put EAUT endpoint information in the DNS, of course. I wouldn't object to that on principle.) 2. Do some of the larger email providers have an opinion on the mechanism used for Discovery in the email case? For instance, would Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based discovery be consulted first? Do they even care? While obviously I can't speak for these big providers, my assumption in all this is that big providers can do whatever they like, whether it be altering the root of their website or putting stuff in DNS. Certainly the DNS change requirement hasn't stopped Hotmail or GMail supporting SPF. I would of course be interested to hear from one of the big providers on this subject, since as far as I can tell they've been silent on it so far. However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) What if the user actually wants their URL to be the claimed identifier? Would you be open to that? I still haven't quite followed why, in that case, the user wouldn't just enter the URL into the OpenID box at the RP. If the user knows what a URL is enough to know they want to use it as an identifier, I think they can manage to type it in without relying on a layer of indirection to achieve that. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] OpenID Extension to handle Emails Addresses?
The Internet has an identifier for users - it is their email address. Trying to tech users to use anything else is pointless. As far as I am concerned, we have a hierarchy of usability interests here: Users: They come first, their needs are paramount and trump all others. Authentication consumers: They come next, make admin as easy as possible, but not if it is going to hurt users. We can expect an auth consumer to have a properly configured DNS server or fix their server if broken. Identity providers: This is a serious business. I don't consider it necessary to make barriers to entry any lower than they currently are for administering a mail server. At the moment the URL centric spec seems to have this hierarchy stood on its head. In order to make matters easy for authentication providers the user is expected to futz with URLs. I have a dozen blogs, I have never considered them to be part of my core identity. They are attributes, not my name. So we have an identifier, [EMAIL PROTECTED], how do we resolve it? Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com or for fault tolerance: _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com or we can redirect to a third party: _openid.example.com PTR pip.verisignlabs.com Any competent network admin can configure SRV records using any of the mainstream DNS servers that have come out in the past 8 years. Windows 2000 uses SRV as a core service. There is no need for users to know this is going on, the only point where the SRC is required is that the identity server has to advertise the service and the authentication consumer app has to be able to read it. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com We don't need to just stop at establishing identity either. We can use this as a means of deploying the type of exotic authentication protocols that Stefan Brands and myself have developed which allow for anonymous authorization without authentication. Someone is going to do federated auth this way sooner or later. It is the obvious way to do it that is consistent with the Internet architecture. The only real arguable point in what I wrote is that I do not have solid data on how users will react. It is my hypothesis that they will find an email address easier than a URL. If folk want to argue that point lets test it out. The main obstacle to change here would be the effect on the legacy base. We would need to get the identity providers to upgrade (easy) and the web sites to upgrade (harder) and there would have to be some sort of change over period that we would need to think through. -Original Message- From: [EMAIL PROTECTED] on behalf of David Fuelling Sent: Thu 10/30/2008 12:20 PM To: Martin Atkins Cc: specs@openid.net; OpenID List Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses? On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins [EMAIL PROTECTED]wrote: David Fuelling wrote: I would even entertain the notion of the OpenID extension doing DNS lookup first, then EAUT, though I need to think more on the topic. Alternatively, maybe we make DNS optional. At this point I'll throw in my more recent post about why DNS must be supported and must be the primary mode, with others as fallback: http://www.apparently.me.uk/18285.html Very interesting points in your blog post!! It has me wondering the following questions: 1. The arguments about using DNS could apply to OpenID in general. However, OpenID doesn't do anything with DNS. Why is this? What were the compelling reasons to not use DNS with OpenID? Is there an FAQ page somewhere about that? I have only vague recollections on the topic. 2. Do some of the larger email providers have an opinion on the mechanism used for Discovery in the email case? For instance, would Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based discovery be consulted first? Do they even care? However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information
Re: [OpenID] OpenID Extension to handle Emails Addresses?
Hallam-Baker, Phillip wrote: Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. Thanks for another voice in favor of DNS. I was beginning to feel like the only one on this side of the fence. :) The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com I did consider SRV, but the return value from OpenID discovery is not a hostname, it's a structure like this: * Endpoint URL * Final claimed identifier (after following redirects) * OP-local identifier (or delegate in 1.1 terminology) * OpenID version (either 1.1 or 2.0, currently) Some of these we can infer. For example, in my DNS-based proposal I just assumed that all email-based identifiers would use OpenID 2.0, because a provider's going to have to change their implementation anyway so they might as well upgrade to 2.0 while they're at it if they don't support it already. I went with a TXT record with a custom serialization, despite it being technically incorrect, both so that the information required for the above structure could be represented and also so that it can be deployed on DNS providers that only allow A, CNAME, MX and TXT records to be configured. The latter is important for the delegation case, as the main audience for delegation is people with vanity domains. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com And I infer from this that you're not adverse to the idea of encoding custom formats in TXT records, so hopefully you'll appreciate my approach. However, if you've got an alternative proposal that's more DNS-pure I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd take a very convincing argument for me to get behind anything that requires something other than A, CNAME, MX and TXT records though, for the reasons stated above. (In case you haven't seen it, my current strawman proposal is here: http://www.apparently.me.uk/18285.html ) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Extension to handle Emails Addresses?
I agree with using DNS. I would however suggest using TXT as a fallback from SRV. Sent via BlackBerry by ATT -Original Message- From: Martin Atkins [EMAIL PROTECTED] Date: Thu, 30 Oct 2008 11:51:12 To: Hallam-Baker, Phillip[EMAIL PROTECTED] Cc: specs@openid.net; OpenID List[EMAIL PROTECTED] Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses? Hallam-Baker, Phillip wrote: Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. Thanks for another voice in favor of DNS. I was beginning to feel like the only one on this side of the fence. :) The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com I did consider SRV, but the return value from OpenID discovery is not a hostname, it's a structure like this: * Endpoint URL * Final claimed identifier (after following redirects) * OP-local identifier (or delegate in 1.1 terminology) * OpenID version (either 1.1 or 2.0, currently) Some of these we can infer. For example, in my DNS-based proposal I just assumed that all email-based identifiers would use OpenID 2.0, because a provider's going to have to change their implementation anyway so they might as well upgrade to 2.0 while they're at it if they don't support it already. I went with a TXT record with a custom serialization, despite it being technically incorrect, both so that the information required for the above structure could be represented and also so that it can be deployed on DNS providers that only allow A, CNAME, MX and TXT records to be configured. The latter is important for the delegation case, as the main audience for delegation is people with vanity domains. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com And I infer from this that you're not adverse to the idea of encoding custom formats in TXT records, so hopefully you'll appreciate my approach. However, if you've got an alternative proposal that's more DNS-pure I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd take a very convincing argument for me to get behind anything that requires something other than A, CNAME, MX and TXT records though, for the reasons stated above. (In case you haven't seen it, my current strawman proposal is here: http://www.apparently.me.uk/18285.html ) ___ 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] OpenID Extension to handle Emails Addresses?
Maybe because the DNS naming system is the Internet for all practical purposes. Think about the telephone system. What parts of the system today have remained the same for a century? Pretty much everything has changed, the telephones, the switches, the wires, even the assignment of the numbers themselves. But the basic interface of 'dial number X to talk to Y' has remained constant. The DNS is the equivalent infrastructure for the Internet. Everything else will change over time. We are currently changing the packet protocol from IPv4 to IPv6 and many parts of the Web are not on the Internet at all, the are URLs embedded in print media, in CD Rom and such. The implementation will change, you might even see new TLDs replace .com or the rise of www.microsoft or whatever. But every such change must and will be incremental. I am not quite sure to interpret the last paragraph. The term 'walled garden' is a loaded one. It is used to refer to the carrier model where the carrier decides where the consumer is allowed to go. I don't think that is what end users want. But what they might well want is a model where they get to define the fences themselves. So they can fence off their financial browser from the anonymizing Web browser they use to view folk dancing Web sites and the like. Its really a matter of who gets to decide where the fence goes... From: Peter Williams [mailto:[EMAIL PROTECTED] Sent: Thu 10/30/2008 3:09 PM To: Martin Atkins; Hallam-Baker, Phillip Cc: specs@openid.net; OpenID List Subject: RE: [OpenID] OpenID Extension to handle Emails Addresses? Verisign wants validation of id related to dns (and dnssec). Wonder why? As long as an op can verify the dns assuraces and communciate them to the rp as a certificate (re)minted by itself, there is a compromise to be had here. Perhaps the op adds the domain to its own walled garden dns server, does its own dnssec, and lets its consumers bind over an mpls vpn and virual routing domain to its dns service.. That would be consistent with the openid model: as the rp app chooses the dns access point, not the op. -Original Message- From: Martin Atkins [EMAIL PROTECTED] Sent: Thursday, October 30, 2008 2:51 PM To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: specs@openid.net specs@openid.net; OpenID List [EMAIL PROTECTED] Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses? Hallam-Baker, Phillip wrote: Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. Thanks for another voice in favor of DNS. I was beginning to feel like the only one on this side of the fence. :) The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com I did consider SRV, but the return value from OpenID discovery is not a hostname, it's a structure like this: * Endpoint URL * Final claimed identifier (after following redirects) * OP-local identifier (or delegate in 1.1 terminology) * OpenID version (either 1.1 or 2.0, currently) Some of these we can infer. For example, in my DNS-based proposal I just assumed that all email-based identifiers would use OpenID 2.0, because a provider's going to have to change their implementation anyway so they might as well upgrade to 2.0 while they're at it if they don't support it already. I went with a TXT record with a custom serialization, despite it being technically incorrect, both so that the information required for the above structure could be represented and also so that it can be deployed on DNS providers that only allow A, CNAME, MX and TXT records to be configured. The latter is important for the delegation case, as the main audience for delegation is people with vanity domains. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com And I infer from this that you're not adverse to the idea of encoding custom formats in TXT records, so hopefully you'll appreciate my approach. However, if you've got an alternative proposal that's more DNS-pure I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd take a very convincing argument for me to get behind anything that requires something other than A, CNAME, MX and TXT records though, for the reasons stated
