Adding a metadata object to request and response objects

[Nathan Fischer]

Frequently a message has some metadata associated with it that wouldn't be suitable to be called a parameter of the method. Things like authorization tokens, correlation/request IDs, etc.

I would propose adding an optional "meta" field to the request and response objects with a description like "A Structured value that holds the metadata to be used during the invocation of the method. This member MAY be omitted.".

This could come with a bump to a protocol version number of 2.1. It shouldn't be a breaking change since existing 2.0 software can just ignore the metadata, although new software may require it.

Anyone have thoughts on this?

[Felix Becker]

At Sourcegraph we already use this to embed Opentracing span contexts (https://opentracing.io/)

Although in theory this could also be done through `params`, and I fear it will not be clear what goes into `meta` and what into `params`. 

[Alex Efros]

Hi!

On Fri, Nov 09, 2018 at 12:03:51PM -0800, Nathan Fischer wrote:
> Frequently a message has some metadata associated with it that wouldn't be
> suitable to be called a parameter of the method. Things like authorization
> tokens, correlation/request IDs, etc.

Authorization tokens are better to be sent in params, because methods
often need access to authorization details and their behaviour may depends
on it.

IMO "meta" may be used only for things which doesn't affect method
behaviour in any way. And here we come to case when one RPC method call
another RPC. It's usual to include same "meta" data with second call or
somehow inherit/update "meta" data to produce "meta" data for second call.
Which usually result in needs for method to know about "meta" and handle
it somehow… which means it's not a "meta" anymore, just a regular param.

The conclusion is there is no real sense to add "meta" - at least until
we'll be able to somehow define what exactly should be in "meta" and what
in "params".

Personally, I tend to add "ctx" (context) key to each method params and
send all not-an-actual-params there (like auth tokens, request ID,
tracing, debugging, timeout, etc.). This way it's easy to implement common
handling of auth/tracing/etc. features in library/framework, but each
method is still has access to these details and it's easy to use current
method's context to generate context for next RPC call from current
method.

--
WBR, Alex.

[Andrew Arnott]

I don't think authorization has any place in JSON-RPC. If you have a durable connection over which to pass JSON-RPC messages, the creds should have been passed as part of establishing the connection. And if you're using HTTP, the HTTP Headers are the established and well-spec'd place to pass authorization tokens.

Depending on the stack you're building your server on, I would also venture to say your methods should never be dealing with tokens directly. The middleware should be processing and validating it, allowing your method to just contain your business logic.

As for the tracing example, we're doing that already as well. I don't personally think the spec needs to accommodate for it, since it requires specially arranged handling on both sides anyway.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To post to this group, send email to json...@googlegroups.com.
Visit this group at https://groups.google.com/group/json-rpc.
For more options, visit https://groups.google.com/d/optout.

[Nathan Fischer]

> I don't think authorization has any place in JSON-RPC.

To be clear, I think that the meta field should not have a schema in the spec, rather it should be open for the application or middleware to decide what the structure is. So we wouldn't be dictating that authorization would or wouldn't be in any given place.

> I fear it will not be clear what goes into `meta` and what into `params`

Seems like a valid concern. Perhaps we can define that params are "parameters used by the business logic of a specific method" while meta is for "fields related to cross cutting concerns".

--

Nathan Fischer

Software Engineer, Lightform

lightform.com | blog | @lightforminc

[Alex Efros]

Hi!

On Tue, Nov 13, 2018 at 07:09:12AM -0800, Andrew Arnott wrote:
> Depending on the stack you're building your server on, I would also venture
> to say your methods should never be dealing with tokens directly. The
> middleware should be processing and validating it, allowing your method to
> just contain your business logic.

Sometimes authorization is more complicated than just "is it allowed to
call this method", business logic may depends on authorization details
(like permissions) tied to token.

Also, sometimes next RPC called from current method should use same
authorization context as current method, which means current method should
have access to token to send same token to next RPC.

--
WBR, Alex.

[Matt (MPCM)]

I'm partial to enveloping this type of data, with a json-rpc payload inside of it. This way you can either stick that in a JWT, and have a dedicated layer that applies authorization, and fwd's on, or if it is really part of your method signature... it should of course live in params. I dont quite feel this warrants existing in the core spec, because there are a lot of blends of what people want and consider a best practice, lots of bike-shedding... often this has direct transport considerations, or rate-limiting implications, that are more specific to the env at all, ahead of method execution.

[Nathan Fischer]

> I'm partial to enveloping this type of data, with a json-rpc payload inside of it.

This actually reminds me of a question I have as someone new to the community here. How much does the community in general value interoperable JSON-RPC implementations? I think your approach is totally valid for a proprietary implementation, but would raise issues interacting with another "standard" implementation.

This question has a significant impact on the proposal for a meta object in general. If interoperable JSON-RPC implementations are not very important to us, then I think a meta object doesn't really need to be added to the standard, anyone who wants something like that can just add it to their JSON-RPC "based" protocol with the knowledge that they'll be implementing all the clients and servers. But if interoperability is a a concern, then I think a meta field is a valuable addition to enable extensible middleware.

--

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To post to this group, send email to json...@googlegroups.com.
Visit this group at https://groups.google.com/group/json-rpc.
For more options, visit https://groups.google.com/d/optout.

[Deomid Ryabkov]

fwiw, i was just investigating this as a means of passing ancillary information along with requests - in my case, routing information.

sourcegraph's "meta" is the closest and would just fine for my purpose.

i'm not expecting the standard to specify what's inside "meta", just define the key name - meta, ctx or whatever, - and mention that caller should be able to provide it and the handler should be able to obtain it.

something to consider for 2.1, perhaps.

On Monday, November 19, 2018 at 7:46:52 PM UTC, Nathan Fischer wrote:

> I'm partial to enveloping this type of data, with a json-rpc payload inside of it.

This actually reminds me of a question I have as someone new to the community here. How much does the community in general value interoperable JSON-RPC implementations? I think your approach is totally valid for a proprietary implementation, but would raise issues interacting with another "standard" implementation.

This question has a significant impact on the proposal for a meta object in general. If interoperable JSON-RPC implementations are not very important to us, then I think a meta object doesn't really need to be added to the standard, anyone who wants something like that can just add it to their JSON-RPC "based" protocol with the knowledge that they'll be implementing all the clients and servers. But if interoperability is a a concern, then I think a meta field is a valuable addition to enable extensible middleware.

On Sun, Nov 18, 2018 at 12:27 PM Matt (MPCM) <wicke...@gmail.com> wrote:

I'm partial to enveloping this type of data, with a json-rpc payload inside of it. This way you can either stick that in a JWT, and have a dedicated layer that applies authorization, and fwd's on, or if it is really part of your method signature... it should of course live in params. I dont quite feel this warrants existing in the core spec, because there are a lot of blends of what people want and consider a best practice, lots of bike-shedding... often this has direct transport considerations, or rate-limiting implications, that are more specific to the env at all, ahead of method execution.

On Friday, November 9, 2018 at 9:00:00 PM UTC-5, Nathan Fischer wrote:

Frequently a message has some metadata associated with it that wouldn't be suitable to be called a parameter of the method. Things like authorization tokens, correlation/request IDs, etc.

I would propose adding an optional "meta" field to the request and response objects with a description like "A Structured value that holds the metadata to be used during the invocation of the method. This member MAY be omitted.".

This could come with a bump to a protocol version number of 2.1. It shouldn't be a breaking change since existing 2.0 software can just ignore the metadata, although new software may require it.

Anyone have thoughts on this?

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to json...@googlegroups.com.

To post to this group, send email to json...@googlegroups.com.
Visit this group at https://groups.google.com/group/json-rpc.
For more options, visit https://groups.google.com/d/optout.