I see on Scripting News today that there a couple more subsHarmonizer implementations have popped up, so thought I'd run my test suite over them to see how they go. Neither seem to behave the same way as mine and Dave's, although looking back at the spec, their behaviour may actually be correct. The way I implemented mine was to look at Dave's Radio client code, do the same thing in Python, verify that it worked with Dave's server, then write the server-side code so that it worked with mine too. However, the resulting code didn't conform to the spec (it only accepted strings where the spec says arrays are required, for subscribe() and unsubscribe() - now fixed).

Treating Dave's server responses as the correct ones, here are the results. Everyone appears to conform to the spec, but there are differences in things that aren't stated specifically.

server	invalid login	unknown method	startup() -> array	subscribe (string) (opt.)	unsub. (string) (opt.)	setup / subscribe (array)	unsub. (array)	reset() (opt.)
harvard	fault 4	fault 7	yes	yes	yes	yes	yes	fault 7
topicex.	fault 4	fault 7	yes	yes	yes	yes	yes	yes
miseldine	empty string	fault 0	yes	fault 0	fault 0	yes	yes	yes
ghostc.	fault 1	blank HTTP response	yes	yes	no	yes	yes	blank HTTP response

In light of all this, here are some recommendations for implementors. First, people doing the server side:

1. XML-RPC fault code 4 should be returned when invalid login details are passed.
2. XML-RPC fault code 7 should be returned on an invalid method.
3. String values should be accepted where arrays are specified in the spec (i.e. subscribe(login, password, url) should be equivalent to subscribe(login, password, [url]))

And for clients:

1. Always pass urls as arrays (Dave's and my implementations allow strings in subscribe and unsubscribe, but others don't).

Marc Canter points to Brian Field-Elliot’s SourceID project, an open-source implementation of the Liberty Alliance system.

I found an article that attempts to explain the whole thing; it seems similar to what I’ve been talking about, except with more XML. In place of my tokens, it has SAML assertions.

The interesting part of it is that sites using an authentication provider don’t even get to see who it is that is authenticating — they just get a random number, and then presumably connect back to the authentication server to ask for more details later. This is identity federation.

In my case, I’m not sure if this is necessary, or even desirable, as the whole point of my authentication system is to prove who you are, or at least what resources you are responsible for. I wonder …

I’m building some infrastructure so I can get my community server stuff playing nicely with my search engine.

Over the weekend I started prototyping it in the [[Topic Exchange]]. Currently there are just two XML-RPC calls:

<code>identity.getToken(login, password)</code>

This takes your login and password, and returns a token.

<code>identity.validateToken(token)</code>

This takes a token, and returns the login id that generated it.

The key concept here is that you can authenticate yourself to a remote server by giving it a token from the Topic Exchange. Tokens are only redeemable once, and expire if not used in 10 minutes. If you get a token that validates, you can be pretty sure that the person who gave it to you owns the userid you got back from the validateToken call.

The first application is proving to a search engine that you own an account on a community server. I’m going to hack this into the [[Python Community Server]], so people can connect to a search engine and validate themselves as members of a community (and thus show up in search results when people search for text published anywhere on the server).

It will become slightly more complicated: the plan is to make it so you can give getToken more info, some sort of cookie, which will be passed back in validateToken, so a server can give you some info about the type of token it wants and you can be sure that the token is only valid on that server (preventing the possibility of someone getting a token under false pretenses and passing off as you elsewhere).

This could trivially be used as the hub for a single sign-on (Passport / Liberty Alliance-like) system. Apparently the OpenIdentity folks have been working on something, which I’m really looking forward to seeing. I wonder if it has much in common?

IMHO the world really needs a single sign-on system that is as trivial for developers to use as [[RSS]] and [[XML-RPC]]. Let’s make this happen …