Open jakedoublev opened 4 months ago
Unfortunately, for the fqn table we're constructing this in SQL, but it seems that there should be two functions that live together. One for Go FQN construction and one for SQL. Should at least reduce the scavenger hunt. main/service/policy/db/attribute_fqn.go#L42
I believe there is a requirement for FQN to be a URI; at least for Attributes. If true, this issue will limit the scope of future changes.
Reopening with additional context that we should move validation like what was introduced here into a platform policy lib so that we can share it throughout the platform services and downstream PEPs.
Background
There is a need to look up attributes (namespaces, definitions, values) by FQNs, and therefore a need to build, store, validate, and tear them down. https://github.com/opentdf/platform/issues/95 added the functionality to store FQNs in the database for lookup FQN -> Policy Attribute Objects, but there are needs in Access PDP, test functions, and the policy services to dynamically build FQNs going from Policy Attribute Objects -> FQNs. This should be common functionality
We should also expose this functionality on the SDK for use in PEPs without a separate import.
Acceptance Criteria
fmt.Sprintf
calls are replaced by the shared functionsGetAttributesByValueFQNs
request (consumed by Auth service requests) successfully populates FQNs for all policy objects in response without doing joins with the FQNs table, deferring to composite keys and foreign keys to preserve relational integrity