Use evaluation/evaluations syntax instead of arrays

[tulshi]

From @ogazitt in the AuthZen call on 4/16:

In specifying the COAZ mapping, make the mapping look exactly like how we pass parameters to evaluation/evaluations call. That way we can avoid specifying arrays and then converting that to what an evaluation / evaluations call needs.

[tulshi]

Example provided by @baboulebou:

"x-coaz-mapping": {
            "action": [
              { "name": "'read'" },
              { "name": "'write'" }
            ],
            "resource": [
              { "type": "'storage_object'", "id": "params.arguments.source" },
              { "type": "'storage_object'", "id": "params.arguments.destination" }
            ],
            "subject": [{
              "type": "'user'",
              "id": "token.sub"
            }],
            "context": [{
              "agent": "token.client_id"
            }]
          }
        }

[alexolivier]

So something like this?

Current (arrays everywhere, PEP reshapes into evaluations):

  "x-coaz-mapping": {
    "action":   [{ "name": "'read'" }, { "name": "'write'" }],
    "resource": [{ "type": "'storage_object'", "id": "params.arguments.source" },
                 { "type": "'storage_object'", "id": "params.arguments.destination" }],
    "subject":  [{ "type": "'user'", "id": "token.sub" }],
    "context":  [{ "agent": "token.client_id" }]
  }

Proposed (identical to an AuthZEN evaluations body):

  "x-coaz-mapping": {
    "subject": { "type": "'user'", "id": "token.sub" },
    "context": { "agent": "token.client_id" },
    "evaluations": [
      { "action": { "name": "'read'" },
        "resource": { "type": "'storage_object'", "id": "params.arguments.source" } },
      { "action": { "name": "'write'" },
        "resource": { "type": "'storage_object'", "id": "params.arguments.destination" } }
    ]
  }

[alexolivier]

Or we if we choose to land #491 it would be

  "x-coaz-mapping": {
    "subject": { "type": { "value": "user" }, "id": { "expr": "token.sub" } },
    "context": { "agent": { "expr": "token.client_id" } },
    "evaluations": [
      { "action":   { "name": { "value": "read" } },
        "resource": { "type": { "value": "storage_object" }, "id": { "expr": "params.arguments.source" } } },
      { "action":   { "name": { "value": "write" } },
        "resource": { "type": { "value": "storage_object" }, "id": { "expr": "params.arguments.destination" } } }
    ]
  }

[ogazitt]

@alexolivier @tulshi this is great, with a couple of tweaks:

1. have we considered using the moniker "x-authzen"? we already have some "brand equity" in "authzen".
2. it would be nice to use the evaluation or evaluations as the key for the payload, so it's unambiguous which call should be made.

Combining:

"x-authzen": {
  "evaluation": {
    "subject": { { "type": "'user'", "id": "token.sub" },
    "context": { "agent": "token.client_id" },
    "action": { "name": "'read'" },
    "resource": { "type": "'storage_object'", "id": "params.arguments.destination" }
  }
} 

With respect to #491, I agree that requiring the single-hash for string literals could be a footgun, but the level of nesting that's necessary to properly differentiate a literal value from an expression seems onerous and makes the payload much harder to read and decipher.

Could we go the other way? Assume that simple strings in JSON are literals, and require a prefix (e.g. @ or $) to designate a CEL expression?

E.g.:

"subject": { { "type": "user", "id": "@token.sub" }