KAS Grant Specificity: Grants to Values should replace grants on Attributes

[dmihalcik-virtru]

Scenarios:

Schema:

• Attribute A: Grant-> kas.a
  • Value A.1 -> kas.a1
  • Value A.2 -> unassigned
• Attribute B: unassigned
  • Value B.1 -> kas.b1
  • Value B.2 -> unassigned

Policies:

Policy	Split Schema
A.1	s1 => kas.a1
A.2	s1 => kas.a
B.1	kas.b1
B.2	default
A.1 & A.2	S1 => {kas.a, kas.a1}
B.1 & B.2	S1 => kas.b1
A.1 & B.1	S1 => {kas.a1, kas.b1}
A.1 & B.2	S1 => kas.a1
A.2 & B.1	S1 => {kas.a, kas.b1}
A.2 & B.2	S1 => kas.a

[dmihalcik-virtru]

@jakedoublev Does this make sense?

[jakedoublev]

I think the above makes sense. However, I think we could possibly clarify further, such as:

1. I believe KASs can be shared in any way across attribute definitions and values without the platform making an opinion?
2. I believe KASs are not necessarily tied to a namespace, but per the outcome of the recent namespace KASs ADR, namespaces may be associated with a KAS (possibly must be, but TBD). Maybe we should capture that scenario within this issue (unless we're limiting scope and that's separate work)?
3. Are the key splits 100% always an AND split instead of an OR split?

graph LR
    A[Attribute A] --> A1[Value A.1]
    A --> A2[Value A.2]
    A1 -.->|Grant| kas_y["kas.y"]
    A[Attribute A] -.->|Grant| kas_x["kas.x"]

    B[Attribute B] --> B1[Value B.1]
    B --> B2[Value B.2]
    B1 -.->|Grant| kas_z["kas.z"]

   C[Attribute C] --> C1[Value C.1]
    C --> C2[Value C.2]
    C1 -.->|Grant| kas_z["kas.z"]

    style kas_x stroke:#17aa59,stroke-width:2px
    style kas_y stroke:#17aa59,stroke-width:2px
style kas_z stroke:#17aa59,stroke-width:2px
    style B stroke:#ef0a3a,stroke-width:2px
    style B2 stroke:#ef0a3a,stroke-width:2px
	style A2 stroke:#ef0a3a,stroke-width:2px
    style C stroke:#ef0a3a,stroke-width:2px
	style C2 stroke:#ef0a3a,stroke-width:2px


subgraph Legend
      direction LR
      granted["granted kas"]
      style granted stroke:#17aa59,stroke-width:2px
      unassigned["unassigned"]
      style unassigned stroke:#ef0a3a,stroke-width:2px
    end

Loading

[dmihalcik-virtru]

1. Yes, currently there is no direct association between namespaces and kases, or any assertions or assumptions about the KAS URLs (or origins) and their association with any of the attributes or their values.

2. I'd rather keep this limited. This is somewhat due to the fact that we have the namespace stuff in a separate ADR, and somewhat due to the fact that we now have a CI job that enforces that each PR 'closes' a given issue :-)

3. Splits across attributes must always be an AND. Splits within an attribute (two values with the same prefix) may be an OR if they are an 'any-of' attribute type. So in the example above, if a policy had all 6 attributes and they were each any-of, it would generate a redundant split between kas.z as follows:

      split 1 => kas.y, kas.x
      split 2 => kas.z
      split 3 => kas.z
   

This is due to the fact that the current planner does not attempt to make a minimal plan, instead picking one that satisfies the requirements of the grants in terms of how the splits will work. A minimal plan would combine splits 2 and 3 in this scenario.

• Hierarchy should pick the more specific of two options and drop the others, but so far that is not implemented and SDKs treat them as AND.

[jrschumacher]

2. I agree with limiting the scope for now. The "default" KAS is, in effect, the same as the namespace KAS since our existing test policies only have a single namespace.

3. Splits across attributes MUST ALWAYS be an AND. this is obligated by the nature of attributes? We will likely need to document this very well since the product perspective is that AND will be performed infrequently due to the restrictive nature.

[dmihalcik-virtru]

3. Yes that is how the current KAS interpretation works; each attribute value is grouped first into a set by attribute and then each group is evaluated separately.