authenticating with XMPP ID (jabber address)

authenticating with XMPP ID (jabber address)

Posted May 28, 2008 19:35 UTC (Wed) by martinfick (subscriber, #4455)
In reply to: authenticating with XMPP ID (jabber address) by jamesh
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?

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?

---

(Log in to post comments)

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