Use of json for policy in authz without a protobuf alternative is obtuse

[haussli]

Use of json for policy in authz without a protobuf alternative is obtuse. Why use json at all? And, why not offer a native protobuf alternative?

Use of JSON seems inconsistent and unnecessary. If the server wishes to use JSON internally, that is its prerogative, but should not be part of the API, or the user should have the option of using either.

My suggestion is that at the very least, a native protobuf version should be supported. This is not my call though; @tomek-US probably needs to decide this.

This is a split of issues/99; #99 (comment)

[morrowc]

Is it the case that we want to support 2 possible policy languages (json/proto) or to support 1, but have 'many' input options (with a proto -> json conversion cleanly supported in tooling)?

(at some point I thought: "proto3 text format is json" - though I admit to always looking at json with 'skepticism'...)

[haussli]

IMHO, support 1 format - protobuf. json inside protobuf seems unnecessarily kinky. But, I do not think this is my decision and there is clearly some precedence here with the origin of authz.

[morrowc]

I think the discussion in #99 ended up with: "Hey, the gRPC base level code, for reaosns, expects JSON for this, so this service is just implementing that wish."

I dislike json for a ton of reasons, but.... I don't know that we get to change this implementation bit here.
I suppose proposing a change in the gRPC base auth policy is a direction we could pursue.

[haussli]

Ja; I understand that the server code has implemented json. I think that that is its sloppy problem. :) For consistency, it should convert protobuf to json, if it insists upon using json.

Some quick searching implies that there are ways to translate protobuf to json, though I do not know how well that works nor if it is specific to java nor if it works in the reverse. Worth investigating if there is interest in supporting proto instead of json. Just IMO.