| |||||||||||||
|
| |||||||||||||
authenticating with XMPP ID (jabber address)authenticating with XMPP ID (jabber address)Posted May 28, 2008 11:13 UTC (Wed) by jamesh (subscriber, #1159)In reply to: authenticating with XMPP ID (jabber address) by martinfick Parent article: The problem(s) with OpenID
Given that people have been deploying HA solutions for the technologies OpenID is based on for a long time, why do you say that OpenID doesn't help with HA?
So it looks like you can introduce HA to pretty much any part of the protocol. Depending on your requirements, you may not require redundancy at all levels (e.g. a single HA OpenID provider might be enough). As for the independence issue, things seem similar to email. Maintaining your independence while setting up an HA mail system will involve setting up redundant servers. You can delegate some of this to other organisations as backup MX, but this involves giving them control over some portion of your incoming email stream. I guess the answer here is to not delegate authority/control to people you don't trust.
(Log in to post comments)
authenticating with XMPP ID (jabber address) Posted May 28, 2008 19:35 UTC (Wed) by martinfick (subscriber, #4455) [Link] Given that people have been deploying HA solutions for the technologies OpenID is based on for a long time, why do you say that OpenID doesn't help with HA? Actually, most of the solutions that you mention are either performance/scaling solutions or expensive workaround HA solutions because the protocols that you mention do not have HA built into them to start with! So openid DOES NOT help with HA, it simply assumes that the technologies that you mention will be enough to provide it. I am claiming that they will not! These solutions will not provide a solution for an individual who wants to setup his own openid server and wants to simply delegate failover to a friend or an ISP. To be more specific: * The discovery phase of OpenID is basically just a few plain HTTP requests. It should be no more difficult to add redundancy here than for any other web site (round robin DNS, load balancers, etc). These are mostly performance, not HA solutions. None of these allow for simple delegation (if so, please explain how). * The preferred discovery mechanism for OpenID 2.0 is to serve and XRDS document, which includes a priority list of service endpoints. The RP will pick the highest priority service with a supported protocol. This provides a way to specify that multiple OpenID providers can make assertions about a single URL, and provides an entry point for doing round-robin provider selection. Again, this does not allow for the XRDS document to be simply delegated to someone else (if so, please explain how). If this were backed by a simple naming scheme that allowed me to delegate this to someone else it would be fine. But, as is, without this feature you have just moved the single point of failure to the XRDS document and whatever expensive hardware you can throw at this document to keep it up. When the dust settles, by using XRDS you have just introduced another link that can break instead of adding another chain in parallel, this actually makes things worse from an HA perspective! I believe that your remaining three bullets are actually unnecessary. Users can (at least I can) live with a momentary interruption of service while failover occurs, but obviously this cannot persist. So it looks like you can introduce HA to pretty much any part of the protocol. You make it sound like I only have to introduce it to one part when I really have to introduce it to every part for it to actually be HA. And as shown above, many of those parts will not be easy to introduce it to without help from the protocol. As for the independence issue, things seem similar to email. Maintaining your independence while setting up an HA mail system will involve setting up redundant servers. You can delegate some of this to other organizations as backup MX... But how can I delegate this to others with openid? The protocol does not provide a mechanism to do this? Can a friend easily provide a backup openid service for you? How would the naming scheme work? If my identity URL is http://mydomain.com/myopenidsoftware/John.Doe, how can my friend's openid server which gives him an identity URL of http://backup.com/backupopenidsoftware/Friend use his server to backup my id? That is the problem, there is no easy standard way of doing this? If there were a standard way to create openid identity URLs, this might be possible. I have suggested a very naive solution to the openid mailing list, but few seemed to even think it was required, and none bothered to even rip apart my naive solution. :) They probably agree with you that HA can be thrown below the openid technologies, but this is really not feasible for the individual and I would think that it would not be feasible for most small businesses either. It's just an expensive kludge. My naive solution is here: http://www.theficks.name/Hacks/OpenID, it is lame, but perhaps it could inspire someone to suggest a real solution, or to realize that openid needs one! I just realize now that perhaps a similar simple scheme could be used to make the XRDS document HA? I am not sure what would be better, but if XRDS doesn't really provide HA, why bother with its complexity anyway?
authenticating with XMPP ID (jabber address) Posted May 30, 2008 6:27 UTC (Fri) by jamesh (subscriber, #1159) [Link] > These are mostly performance, not HA solutions. None of these allow > for simple delegation (if so, please explain how). Many high availability solutions also improve performance. An HA solution does not necessarily mean having a backup server sitting round waiting for the primary server to die. In fact, most multi-active solutions are more likely to handle crashes correctly because they need to be aware of other nodes in the common case. > Again, this does not allow for the XRDS document to be simply delegated > to someone else (if so, please explain how). As I said, you can use the same techniques as used to make any web site highly available. > You make it sound like I only have to introduce it to one part when > I really have to introduce it to every part for it to actually be HA It wasn't my intention to make it look like you only needed to add HA to one part. Some of the techniques I mentioned can be omitted though (a single high availability OpenID provider might satisfy your needs, for instance). > But how can I delegate this to others with openid? The protocol does > not provide a mechanism to do this? Can a friend easily provide a > backup openid service for you? How would the naming scheme work? If > my identity URL is http://mydomain.com/myopenidsoftware/John.Doe, how > can my friend's openid server which gives him an identity URL of > http://backup.com/backupopenidsoftware/Friend use his server to > backup my id? That is the problem, there is no easy standard way of > doing this? Take a look at the discovery portions of the specification again. In particular, the difference between the "claimed identifier" and the "OP-local identifier". The identifier allocated to you by an OpenID provider is not necessarily the same as the claimed identifier given to the relying parties. Provided you have your discovery information in order, this should not be a problem. Now, this isn't to say that there are bugs in the existing OpenID implementations. Some deployments are buggy (e.g. SourceForge's implementation is incomplete, with no support for XRDS). Few libraries try secondary endpoints in the XRDS if the first fails (this is roughly equivalent to an MTA only trying the first MX record). Things will have to improve, but they are not inherent flaws in the specification. We are talking about a fairly new technology here.
authenticating with XMPP ID (jabber address) Posted May 30, 2008 16:25 UTC (Fri) by martinfick (subscriber, #4455) [Link] I think that you missed this part of my reply above: These solutions will not provide a solution for an individual who wants to setup his own openid server and wants to simply delegate failover to a friend or an ISP. Your answers do not address this primary issue. MX records for email do. Without this, openid is not poised for global adoption and will remain something that enslaves anyone who wants to use it to the whims of large corporate openid providers. It is not a reasonable solution for someone who wants to be independent, which is really a shame. For those of us who look for the ability to be independent from a software infrastructure perspective (which I suspect many free software users do), openid brings us this hope, but unfortunately it seems to fall short of delivering this. :( From your answers and others like you it is obvious that openid has done a good job marketing to and making life easy and profitable for the expensive high end providers, perhaps this was the single most important/valid criticism in this article. However, little thought seems to have been given to the concerns of smaller entities such as individual users who want to be their own providers. Maybe I am just old school, I still own a land line (scoff)! Back when email was designed connectivity and availability were not taken for granted as they are today. I guess it is just hard to escape from this narrow minded point of view when the web today seems like it just works. Sadly, this point of view shows clearly in the design of many newer technologies.
|
|
||||||||||||