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

Johannes Ernst jernst+openid.net at netmesh.us
Fri Nov 10 00:25:40 UTC 2006


On Nov 8, 2006, at 23:42, Hallam-Baker, Phillip wrote:

> 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.

Gotta nitpick here, sorry about that:

I don't think it does. For example, the URL does not tell me:
  - what HTTP version the server can speak
  - what representations of the resource it can return, e.g. MIME types
  - what HTTP methods it understands (e.g. WebDav)
etc.etc. All the stuff that is in the HTTP headers beyond the URLs.

One way of looking at XRDS is to add more meta-data to URLs just like  
certain HTTP fields add more meta-data. Theoretically, one could pack  
all of that meta-data into HTTP header extensions, but that's ...  
well, not so good. So the header adds a level of indirection from  
where that info can be retrieved.

There's another problem with using DNS for this: DNS would have a  
very hard time returning 1000 different XRDS files (or equivalent)  
from 1000 different URLs hosted on the same server. Just think of  
identity-related services that the IdP/OP charges for: some users on  
the host will have bought other packages (e.g. voice auth vs. fob)  
than others, and thus their XRDS file changes -- and rather quickly,  
e.g. when they don't pay on time.

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




More information about the specs mailing list