XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://user at example.com" Style Identifiers)
Hallam-Baker, Phillip
pbaker at verisign.com
Thu Nov 9 01:19:05 UTC 2006
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:drummond.reed at cordance.net]
> Sent: Wednesday, November 08, 2006 7:42 PM
> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
> Cc: specs at openid.net; general at openid.net
> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL]
> Handle "http://user@example.com" 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: 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
>
>
>
More information about the specs
mailing list