XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://user at example.com" Style Identifiers)

Wed Nov 8 16:41:57 PST 2006

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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Hallam-Baker, Phillip
Sent: Wednesday, November 08, 2006 3:01 PM
To: Recordon, David; David Fuelling
Cc: specs at openid.net; general at openid.net
Subject: RE: [PROPOSAL] Handle "http://user@example.com" 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 at openid.net; general at openid.net
> Subject: RE: [PROPOSAL] Handle "http://user@example.com" 
> 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: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs at openid.net; general at openid.net
> Subject: RE: [PROPOSAL] Handle "http://user@example.com" 
> 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 user at example.com 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:sappenin at gmail.com]
> > Sent: Wednesday, November 08, 2006 1:56 PM
> > To: Hallam-Baker, Phillip
> > Cc: specs at openid.net; general at openid.net
> > Subject: RE: [PROPOSAL] Handle "http://user@example.com" 
> > 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:pbaker at verisign.com]
> > > Sent: Wednesday, November 08, 2006 1:45 PM
> > > To: David Fuelling; specs at openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://user@example.com" 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:user at example.com or
> > to define
> > > openid:user at example.com
> > > 
> > > 
> > > 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: specs-bounces at openid.net
> > > > [mailto:specs-bounces at openid.net] On Behalf Of David Fuelling
> > > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > > To: specs at openid.net
> > > > Subject: RE: [PROPOSAL] Handle "http://user@example.com"
> > > > Style Identifiers
> > > >
> > > > Please see my questions/ideas enclosed...
> > > >
> > > > Thanks!
> > > >
> > > > David Fuelling
> > > >
> > > > > -----Original Message-----
> > > > > From: specs-bounces at openid.net
> > [mailto:specs-bounces at openid.net]
> > > > > On Behalf Of Drummond Reed
> > > > > Sent: Friday, October 20, 2006 1:04 AM
> > > > > To: 'Recordon, David'; specs at openid.net
> > > > > Subject: RE: [PROPOSAL] Handle 
> "http://user@example.com" 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 beth at example.com 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 at openid.net
> > > > http://openid.net/mailman/listinfo/specs
> > > >
> > > >
> > 
> > 
> > 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs