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 07:42:19 UTC 2006 

What you are calling discovery is what I would term location.

URL - Uniform Resource Locator

The locator is completely self contained, no discovery necessary, all the information you need to resolve is there. 

> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com] 
> Sent: Thursday, November 09, 2006 2:05 AM
> To: Johannes Ernst
> Cc: Hallam-Baker, Phillip; specs at openid.net; general
> Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] 
> Handle "http://user@example.com" Style Identifiers)
> 
> I agree with Johannes here. DNS is not user accessible (for 
> good reason) Documents on a web server are relatively more accessible.
> 
> wrt. DNS, I think DNSSEC could have a significant role in 
> providing server to server discovery, specifically of key key 
> material.
> 
> -- Dick
> 
> On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote:
> 
> > Just commenting on the XRDS discovery from HTTP URLs bit.
> >
> > Using DNS as a mechanism, given a URL, to discover the 
> location of, or 
> > obtain the content or equivalent of, the XRDS file, was 
> proposed back 
> > then in Yadis 0.x days, and rejected. The reason being that 
> any such 
> > mechanism would require the system administrator in charge 
> of the DNS 
> > system to "configure XRDS" for any and all users in that domain. It 
> > would give that system administrator an effective veto 
> (exercised by 
> > being lazy, for example) over whether or not users could 
> use OpenID on 
> > that domain, and in particular which services to reference 
> from that 
> > file (e.g. competitive services). There was general 
> consensus that for 
> > a "user-centric" identity system, that was not desirable, 
> and that's 
> > why we decided in favor of the HTTP header extension, its HTML 
> > equivalent, and the shortcut via the MIME type.
> >
> > We felt on safe ground with respect to naming design, because it's 
> > very much the same approach as, say, the reference of 
> embedded GIFs or 
> > CSS in HTML, or the use of URLs to identify DTDs in XML.
> >
> >
> > On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:
> >
> >> 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
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> specs mailing list
> >> specs at openid.net
> >> http://openid.net/mailman/listinfo/specs
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
> 
> 
>

More information about the general mailing list