You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the number of objects that can be fully qualified with a namespace will grow (registered KASes, various mappings)
the structure of the FQN itself may change
The otdfctl CLI has done a great job simplifying the CRUD of policy (attributes/mappings) for platform administrators. However, as the data is truly a graph structure, there is a known desire to understand policy objects by their names rather than their IDs.
There are already some service-to-service RPCs that exist within the platform to contextualize various FQNd policy objects without use of UUIDs:
GetAttributesByValueFQNs (with lookup for a value-less attribute FQN already existing within)
ListResourceMappingsByGroupFQNs
The behavior of these existing RPCs is different from our normal GET/LIST behaviors because it is known that requests to these RPCs seek great depth of context around the policy object being queried. They are service-first RPCs rather than admin-CRUD-first RPCs. That said, we can expose them in the CLI via a lookup functionality. This would be durable to any future FQN extensions or changes and serve the admin/PEP developer need to understand everything relevant to a policy object.
Acceptance Criteria
otdfctl policy lookup [fqn] takes any supported FQN as an argument
the CLI breaks down the FQN argument into its known supported kind
the CLI calls the relevant Policy FQN-driven-read RPC to provide the entire context (all mappings, all grants, etc) to the policy object
the CLI outputs the JSON response
The text was updated successfully, but these errors were encountered:
Background
Currently in the platform there are 4 types of Fully Qualified Names (FQNs) that correspond to objects within OpenTDF Platform policy:
https://<namespace>
https://<namespace>/attr/<attribute definition name>
https://<namespace>/attr/<attribute definition name>/value/<value>
https://<namespace>/resm/<group name>
Two things are possible and maybe even likely:
The
otdfctl
CLI has done a great job simplifying the CRUD of policy (attributes/mappings) for platform administrators. However, as the data is truly a graph structure, there is a known desire to understand policy objects by their names rather than their IDs.There are already some service-to-service RPCs that exist within the platform to contextualize various FQNd policy objects without use of UUIDs:
The behavior of these existing RPCs is different from our normal GET/LIST behaviors because it is known that requests to these RPCs seek great depth of context around the policy object being queried. They are service-first RPCs rather than admin-CRUD-first RPCs. That said, we can expose them in the CLI via a
lookup
functionality. This would be durable to any future FQN extensions or changes and serve the admin/PEP developer need to understand everything relevant to a policy object.Acceptance Criteria
otdfctl policy lookup [fqn]
takes any supported FQN as an argumentThe text was updated successfully, but these errors were encountered: