[Json] Secure JSON Procedure Call

[Phillip Hallam-Baker <[e-mail]>]

Looking to see if there is interest in specifying a standard approach to
writing a secure RPC call mechanism using JSON as the encoding.

The key here is 'secure'. Every message must be authenticated and validated
in a consistent fashion. The idea being that at a certain layer of
abstraction, every protocol can be reduced to a caller API and a symmetric
dispatch class.

So for the mesh service I am just writing, I have a class:

    /// <summary>
/// The new base class for the client and service side APIs.
    /// </summary>
    public abstract partial class MeshService : Goedel.Protocol.JPCService {

        /// <summary>
        /// The caller session context.
        /// </summary>
        public JPCSession Session;

        /// <summary>
/// Base class for implementing the transaction.
        /// </summary>
        public virtual VersionResponse Version (
                VersionRequest Request) {
            var Response = new VersionResponse ();
            // Do stuff.
            return Response;
            }
        ...
        }

There is a client class that inherits from this and adds the bits a caller
needs on the caller side (i.e. identify the service to bind to, the account
and credential) and the bits that are needed on the server side (was the
message authenticated, what account is it bound to, what stream, etc.)

While this is very close to traditional RPC. As with the difference between
JSON and XML, what is thrown away is the important part.

SOAP was designed to provide an all-singing, all-dancing remote procedure
call for remotting COM objects over the Web. That might not be what people
thought they were trying to do but it was what they ended up doing. And a
lot of the complexity of the WS-* stack with SOAP, WSDL, WS-Security, etc.
all layering on top of each other come from the fact that this is a layer
that has to be transparent and invisible to the calling applications.


That is not how we write network protocols. Well, not good ones. The
'signature' (as in schema, not digital signature) of an API call and a
network protocol have a similar function but one describes a representation
in computer memory, the other describes a serialization to be sent on a
wire.

That has some important consequences. We don't really care about the
difference between int and Int32. Int64, UInt64, etc. in the network
version. All we care about is that we can represent the data we expect to
see comfortably in whatever language we choose to use and respond
gracefully otherwise.

Another big difference is that on the net, there is no difference between
an array and a list or a set.


Where XML RPC like things go wrong is that they are attempts to replicate
the in-memory representation of the data structure at another place. And
the in-memory data structure has a lot of material that is really not
suited to being replicated. We have pointers off to objects that haven't
been transmitted yet or may not be needed at all. An in-memory list is
likely indexed with some sort of hash dictionary for fast access. But on
the wire it is just a list. Rebuilding the index at the other end is easier
than sending it on the wire.


Anyone else thinking on these lines? I have some tools I am building and it
would be nice if we could get to some consistency.