OpenRPC: user-attended RPC between sites
meepbear at hotmail.com
Sat Jul 16 18:54:36 PDT 2005
>LiveJournal exposes its API in with at least four different APIs:
>LiveJournal's own "flat" protocol, XML-RPC, The Blogger/MetaWeblog API
>and the AtomAPI.
That should teach me not to make unbased assumptions :).
>I fail to see how any of these solve this problem: the
>remote site still needs to include some credentials. Otherwise, how can
>LiveJournal know that the posting site has permission?
I know the intent was to keep OpenID as it currently is but if you add
tokens then things can integrate well into an existing infrastructure.
(This is mostly a rehash of a post I made a couple of weeks ago)
In your example I select a picture, type some text and fill in my OpenID
URL. After I submit your application (the caller) contacts my OpenID server
the same way a consumer does now except that it would also request a
delegation token for 'livejournal.com'.
The user experience is exactly the same as current consumers' except that I
see "do you trust this site to impersonate your identity to livejournal.com"
instead of just "do you trust this site to know your identity". I authorize
the request and the server hands the caller a token.
The caller now has everything it needs and makes its usual RPC request to
LiveJournal and hands it my OpenID URL along with the token as
For the "picture posting" example, LiveJournal would check that the OpenID
is a LiveJournal blog, have its own OpenID server verify the token and then
(dis)allows the post.
The downside is that it requires extending OpenID. The upside is that all of
the existing APIs can remain the way they are and would just need to support
the new authentication scheme. On the caller's side the differences should
be minimal as well; instead of sending an username/password combination,
they'd send a OpenID URL/OpenID token combination instead.
It doesn't solve the profile exchange problem (except that you could then
use different sites' existing exposed APIs) in general but it feels like the
most elegant solution to other "delegated authority" problems to me. It also
eliminates one user intervention in OpenRPC in the case where the OpenID
server and the RPC endpoint are on different sites.
All that said, I didn't see anything wrong with OpenRPC :). It just seems
preferable to make little changes to what's already there rather than start
over with something new.
More information about the yadis