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: [email protected]; [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: [email protected]; [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: [email protected]; [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: [email protected]; [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; [email protected] > > > 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: [email protected] > > > > 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'; [email protected] > > > > > 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 > > > > [email protected] > > > > http://openid.net/mailman/listinfo/specs > > > > > > > > > > > > > > > _______________________________________________ > specs mailing list > [email protected] > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
