OpenRPC: user-attended RPC between sites

[meepbear *]

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

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.