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:[EMAIL PROTECTED] >>> Sent: Wednesday, November 08, 2006 7:42 PM >>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' >>> Cc: specs@openid.net; [EMAIL PROTECTED] >>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] >>> Handle "http://[EMAIL PROTECTED]" 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: [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: specs@openid.net; [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: specs@openid.net; [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: specs@openid.net; [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: specs@openid.net; [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; specs@openid.net >>>>>> 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: specs@openid.net >>>>>>> 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'; specs@openid.net >>>>>>>> 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 >>>>>>> specs@openid.net >>>>>>> http://openid.net/mailman/listinfo/specs >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>>> >>>> >>> _______________________________________________ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >>> >>> >>> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > _______________________________________________ > general mailing list > [EMAIL PROTECTED] > http://openid.net/mailman/listinfo/general > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
