search

opentdf / platform

OpenTDF Platform monorepo enabling the development and integration of _forever control_ of data into new and existing applications. The concept of forever control stems from an increasingly common concept known as zero trust.
BSD 3-Clause Clear License
15 stars 4 forks source link

Policy: Resource Mappings GET/LIST should contain Attribute Value FQN in response #978

Open jakedoublev opened 2 weeks ago

jakedoublev commented 2 weeks ago

Background

The current response to resource mappings Get and List calls looks like the below:

{
  "id": "ca864755-0ca7-4980-a388-33d5d06df480",
  "metadata": {
    "created_at": {
      "seconds": 1718223030,
      "nanos": 764733000
    },
    "updated_at": {
      "seconds": 1718223030,
      "nanos": 764733000
    }
  },
  "attribute_value": {
    "id": "80e6533e-c4ac-4c73-9d49-c7649b27fae8",
    "value": "hello"
  },
  "terms": [
    "world",
    "goodbye"
  ]
}

While the UUID is valuable for CRUD of the Resource Mapping (RM) itself in administrative functionality, this puts the burden on PDP developers to associate an Attribute Value UUID with a namespaced definition. The UUID association of an RM to an attribute Value also causes problems with interoperability in a federated platform or shared-policy scenario.

Acceptance Criteria

  1. The RM GET response also returns the Attribute Value FQN
  2. The RM LIST response also returns the Attribute Value FQN
  3. Existing RM functionality and response data are preserved
  4. Integration tests to validate presence of value FQN in response