Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Policy: Implement breaking change that Resource Mappings have a one of Attribute or Attribute Value #1865

Open
ttschampel opened this issue Jan 21, 2025 · 4 comments
Labels
adr Architecture Decision Records pertaining to OpenTDF comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry)

Comments

@ttschampel
Copy link
Member

Implement breaking change that Resource Mappings have a one of Attribute or Attribute Value

Context and Problem Statement

Some PEP consumers of resource mappings need to map resources to an Attribute and not just an Attribute Value. This PEP specific configuration could be folded in and managed by Resource Mapping Policy if this option existed. This ADR will cover the changes to include. The key change is to update the Resource Mapping API:

  • use one of Attribute, Attribute Value

Existing Resource Mappings API

message ResourceMapping {
  string id = 1;

  common.Metadata metadata = 2;

  policy.Value attribute_value = 3 [(buf.validate.field).required = true];

  repeated string terms = 4;

  ResourceMappingGroup group = 5;
}

Proposed Change

message ResourceMapping {
  string id = 1;

  common.Metadata metadata = 2;

  oneof value {
    policy.Value attribute_value = 3;
    policy.Attribute  attribute = 6;
  }

  repeated string terms = 4;

  ResourceMappingGroup group = 5;
}
@ttschampel ttschampel added the adr Architecture Decision Records pertaining to OpenTDF label Jan 21, 2025
@jrschumacher
Copy link
Member

How would downstream PEPs behave when the resource mapping maps to an attribute rather than value? I'm wondering if we need to add namespaces too.

Currently when a resource mapping maps to a value the PEP can use that value to tag the data if the terms match. If we use the attribute the PEP would be able to choose one of the values associated with the attribute.

@jrschumacher jrschumacher added the comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry) label Jan 21, 2025
@ttschampel
Copy link
Member Author

@jrschumacher : Add namespaces to Resource Mappings (Resource Mapping Groups have namespaces already)?

A Resource Mapping should only use Attribute (instead of Attribute Value) when the PEP workflow needs to drive logic that needs to reasons/operate at the Attribute level.

An example taken from tagging:
A set of Attribute Values have been extracted and assertions need to be created where the assertion content should include all Attribute Values for a given Attribute. An example is STANAG assertions where the Releasable To term could be mapped to the relto Attribute . Tagging could then use this Resource Mapping to collect all relto Attribute Values to fill in Releasable To content

@jrschumacher
Copy link
Member

jrschumacher commented Jan 21, 2025

Ah that makes sense. So not necessarily treating resource mappings as a direct parallel to data tagging.

Resource Mapping Groups have namespaces already

Yep thanks for the reminder!

@jakedoublev
Copy link
Contributor

This makes sense to me. To confirm I understand, there should never be Resource Mappings to an Attribute Definition where one or more Values of that Definition already has its own Resource Mapping, and vice versa? You can map terms to the definition or the values of an attribute, but not both simultaneously?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
adr Architecture Decision Records pertaining to OpenTDF comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry)
Projects
None yet
Development

No branches or pull requests

3 participants