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:[EMAIL PROTECTED] > Sent: Thursday, November 09, 2006 2:05 AM > To: Johannes Ernst > Cc: Hallam-Baker, Phillip; specs@openid.net; general > Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] > Handle "http://[EMAIL PROTECTED]" 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:[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
