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 > > 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 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 > > > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs