opentdf/platform

Policy: resource mappings GET/LIST should provide attribute value FQNs in response

Closed this issue · 4 comments

jakedoublev commented

Background

LIST of resource mappings is a known service to service API for PDPs and should therefore provide the FQN in response of mapped attribute values to avoid PEPs/PDPs receiving the value id and having to do a roundtrip.

Acceptance Criteria

  1. resource mappings return fqns of attribute values they map to in response
  2. integration tests
ryanulit commented

@jakedoublev does this include the ListResourceMappingsByFullyQualifiedGroup query as well or just the base GET/LIST queries?

https://github.com/opentdf/platform/blob/main/service/policy/db/query.sql#L530-L545

  • 👀1
jakedoublev commented

@ryanulit I think we probably want the FQN of the Resource Mapping in each read RPC because the mappings are used by services downstream (not admins alone) and therefore should not rely on UUIDs.

  • 👍1
ryanulit commented

You meant FQN of the Attribute Value right? This also just made me think that we might want to return the FQN of the Resource Mapping Group (i.e. https://<namespace>/resm/<group_name>) in its Get/List queries as well, but I can make a separate ticket for that if you agree.

jakedoublev commented

Sorry for the confusion. I agree we need the below for read actions (get/list):

  1. attribute value FQN when returning resource mappings
  2. resource mapping group FQN when returning resource mapping groups
  3. after requirement change that resource mappings must be in a group is implemented, a get/list of a resource mapping should also include the relevant RM group FQN
  • 👍1