Re: Proposal for Modularizing Auth 2.0 Discovery
-- Best regards, Gavin Baumanis T: +61 -3 992 51099 F: +61 -3 992 52706 E: [EMAIL PROTECTED] Property Services RMIT University Level 6, 449 Swanston Street Melbourne VIC 3000 Australia On Saturday, March 03, 2007 at 17:26, in message [EMAIL PROTECTED], Mark Baker [EMAIL PROTECTED] wrote: snip I suggest just saying that any URI can be used, and let the community/market decide what actually gets used. Mark. Sure, and (as is done already), provide appropriate examples and perhaps even leave out (of the examples) the contested ones. Not saying they can't be used, but perhaps not advertising the contentious ones either? Who makes up the list of what is/isn't??? well the list, of course as is always the case. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
Hi Gabe, On 2/28/07, Gabe Wachob [EMAIL PROTECTED] wrote: Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. I don't understand that. Why shouldn't, say, an ftp URI be usable as an ftp URI instead of converted to an http URI? My bigger concern though, is that such a mapping would be a case of URI space squatting. http://esw.w3.org/topic/UriSpaceSquatting Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
While I'm strongly in favor of modularization from an architectural perspective, is there a potential security problem here if multiple protocols are developed to resolve the same kind of identifier? (because they could resolve to a different set of endpoints / services) It appears to me that the only way this can work is that while we modularize, we only let the same set of people who have defined some of the plug-in documents define new plug-in documents how to do discovery. The Yadis decentralized innovation model -- everybody define the service types they like, they don't need to ask anybody -- may not work here. Or am I off-base? Cheers, Johannes. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal for Modularizing Auth 2.0 Discovery
I agree. I think it is great having a way for people to easily propose new identifier formats and even use them within their own implementations. There does however need to be some sort of community review process before new identifiers are added to OpenID in a public fashion. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Friday, March 02, 2007 12:47 PM To: specs@openid.net Subject: Re: Proposal for Modularizing Auth 2.0 Discovery While I'm strongly in favor of modularization from an architectural perspective, is there a potential security problem here if multiple protocols are developed to resolve the same kind of identifier? (because they could resolve to a different set of endpoints / services) It appears to me that the only way this can work is that while we modularize, we only let the same set of people who have defined some of the plug-in documents define new plug-in documents how to do discovery. The Yadis decentralized innovation model -- everybody define the service types they like, they don't need to ask anybody -- may not work here. Or am I off-base? Cheers, Johannes. Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
On 3/2/07, Gabe Wachob [EMAIL PROTECTED] wrote: Hi Mark- I think I understand your first point. I think FTP is a degenerate case though, because its just like HTTP in the sense that there's basically one way that everybody knows how to use an FTP URI to get at a *document* (e.g. the FTP protocol) -- in that way, its just like HTTP. Besides, nobody has a reason to use FTP URIs (though I'm sure someone will show me why I'm wrong!) Sure, but ftp was just an example. There might be any number of new, useful URI schemes deployed in the future which become easily dereferenceable. As for URI squatting, I'm just not seeing the connection here. Who's squatting here on what URI space? Time for an example I suppose ... I own markbaker.ca., and publish http URIs in that namespace. I might (I don't) also have email addresses there, say [EMAIL PROTECTED] If a public standard were crafted which defined a mapping for mailto:[EMAIL PROTECTED] to something under http://markbaker.ca (say, http://markbaker.ca/~mark), then by virtue of minting a new markbaker.ca email address, the corresponding http URI is now effectively reserved, and unavailable for me to use as anything other than an alias. There's also existing namespaces to consider, as such a mapping spec would be affecting all existing published URIs, not just new ones. What if I already had both http://markbaker.ca/~foobar and mailto:[EMAIL PROTECTED], but both were unrelated? It's not squatting in the sense of a person other than me reserving a name in my own space - at least not if the mapping is done to prevent that from happening (which won't be trivial for schemes which don't use the DNS). But it's squatting in the sense that some external force (the mapping spec) prevents me from using my namespace the way I want. I suggest just saying that any URI can be used, and let the community/market decide what actually gets used. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal for Modularizing Auth 2.0 Discovery
I'd agree on specifying HTTP as the only resolution method required. Unfortunately, I have a conflict of interests with the SMTP service extension... Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal for Modularizing Auth 2.0 Discovery
Gabe Wachob wrote: Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. I don't really think it's necessary to *mandate* that a HTTP mapping always be used. After all, it's very easy for a spec to, if it's appropriate, define a mapping to an HTTP URL and then reference the HTTP-based discovery spec. While I agree that at this point any discovery protocol that *doesn't* use HTTP is going to face an uphill struggle as far as real-world implementations go, if people want to go ahead and try to get their off-the-wall protocols adopted I don't see any reason why we shouldn't let them. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
What Should an OpenId Be? [WAS: RE: Proposal for Modularizing Auth 2.0 Discovery]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Wednesday, February 28, 2007 3:02 PM To: 'Drummond Reed'; 'Martin Atkins'; specs@openid.net Subject: Proposal for Modularizing Auth 2.0 Discovery snip Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. +1. Wherever we go from here, we need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. A while back there was understatementsome talk/understatement about whether email addresses should be used as 1st-Class or 2nd-Class OpenIds (see the wiki here http://openid.net/wiki/index.php/Debating_Emails_as_1st-Class_or_2nd-Class_C itizens). I think it is important to be clear that it is *not* a great idea to use certain other identifiers (email address, phone number, etc) *as* OpenIds. Rather, these should instead map to OpenId Http URL's (or XRI's if possible). This is important because profile attributes like email address, telephone number, etc may or may not be private in certain circumstances. For example, logging-in with my email address at an RP, which maps my email address to a publicly-displayable OpenId, is an ok thing to do assuming I trust the RP with my email address (The RP will hopefully respect my privacy by displaying my mapped OpenId URL or XRI on publicly facing pages where appropriate). If we drift into the territory that says emails addresses (or other profile attributes) *are* OpenIds, then RP's and end-users will run into lots of problems -- E.g., an RP has a publicly facing page that needs to show a user's identifier, but doing so with an email OpenId would be bad for the end user, so the RP is stuck. Bottom Line (repeating myself): We need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. I think the current spec is right on the money here: OpenId Identifiers should be an Http URI or an XRI. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
