With the work in opentdf/platform#51 being merged we need to migrate to the new version.

Add CLI commands for CRUD of subject-mappings. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

OpenTDF has been updated to require authentication. To handle this in the CLI we will want to enable users to authenticate with an OIDC token. To ensure we can protect these we should use the OS keyring to store the token.

See how it's handled in https://github.com/go-jira/jira/blob/4263bd24f9e9c702a92358c5cd7ce0ddd711df4c/jiracli/password.go#L170-L200

Acceptance Criteria

• enable auth in CLI tructl auth set-token
• store token in keyring
• show error if no token set
• show useful error if token is expired

As a developer, I would like the ability to dump all policy config as JSON output so that I can:

• inspect all the policy coning within the platform
• use the policy config in a PEP or proof-of-concept/demo

Depends On

• #30
• opentdf/platform#110

Acceptance Criteria

• determine elegant name for subcommand
• enable a dump of policy config
• dump as json to stdout
  • piping to a file can be achieved with something like tructl policy-dump > policy-config.json

Implement a CLI manual solution that minimizes doc drift

Context and Problem Statement

The Cobra library works really well for generating a manual in the CLI, but this is not the only place our customers will be ingesting the manual. We need a way to generate documentation that can be rendered as HTML, PDF, and the like.

Decision Drivers

• Reduce or eliminate documentation drift
• Support i18n
• Enable non-developers to contribute
• Build an HTML based manual

Considered Options

• Hand-crafted documentation
• Cobra based solution
• Doc driven CLI + Hugo

Decision Outcome

Chosen option: Doc driven CLI + Hugo

This approach offers more value to customers with the tradeoff of some DX pain. The assumption is that new CLI commands will be on the rare side as we continue developing the product and the energy will be invested in a TUI or Web experience.

Confirmation

Hand-crafted documentation

• 🟢 Control over the documentation
• 🟢 Easy to implement
• 🔴 Prone to documentation drift
• 🔴 High level of collaboration required

Cobra based solution

This solution will utilize Cobra's pre-build documentation solution.

• 🟢 Code driven documentation
• 🟢 Reduced documentation drift
• 🟡 Additional tool needed for i18n
• 🔴 Little control over the documentation look and feel without enhancements

Doc driven CLI + Hugo

This approach will utilize markdown files to define the documentation and thus the behavior of the CLI. This will reduce the documentation drift and enable i18n if it becomes needed. The documentation is driven by Hugo's content management.

• 🟢 Markdown based solution
• 🟢 Centralize behavior
• 🟢 Full control over HTML documentation
• 🟡 Small negative impact on DX
  • Feels a little unnatural, but so does i18n with token files
  • Less DRY
  • Slightly slower when running hot (no build first)
• 🟡 Embedded HTML theme via submodule or committed to repo via Hugo
• 🔴 Bespoke

Proposal: Add a GitHub bot user to opentdf to unblock automatic merging of dependency bumps compliant with Codeowners

Background

Dependabot can bump dependencies as newer versions become available and is installed within the opentdf GitHub org.

Knowns / Assumptions

1. Automating dependency bumps is a standard practice that saves time and effort.
2. Out of date dependencies are a significant risk to software security.
3. Manual review of dependency bumps almost never entails exploration of the code changed in each commit of a bumped package, and is more likely (in practice) to involve a review of a changelog or even just blind acceptance of a bump given a minor/patch semver.
4. 3rd party dependencies are always risky, and the greatest evaluation occurs when first introducing them.
5. We have scanning tools in place in the CI pipeline to check vulnerabilities in dependencies.
6. Releases will always involve a QA effort before being published.

Given 2, 3, 4, and 5, it is likely a greater security risk to fall behind in manually approving dependency bumps than to automate their approval and risk a backdoor.

Whatever is employed for otdfctl can be employed across the opentdf GitHub org repositories.

Current state

Dependabot PRs for minor and patch semver bumps are now being set via GitHub Action to auto-merge (squash) and automatically approved in otdfctl. However, there is a conflict with CODEOWNERS. A github bot cannot be added to codeowners so at this time a manual approval is still required to merge. There are some potential workarounds:

Chosen Option

Stick with dependabot and manual approvals. Reassess as needed.

Options

1. Remove codeownership from go.mod and go.sum
   🟥 easier for malicious actor to sneak a backdoor into a dependency and merge it in
   🟩 faster path forward to automated minor/patch bump approvals
2. Add a "bot" GitHub user to the opentdf org for bot-related activities
   🟩 could use a scoped token (probably a PAT) as a secret in workflows (like PR approval of dependabot PRs) to add a layer of authorization security
   🟩 could add the bot user to CODEOWNERS give it access to the dependency lockfiles, a second layer of authorization
   🟥 more secrets to maintain and keep secure

At this time, we will proceed with manual approval of dependency bump PRs until it becomes a burden sufficient enough to justify a decision on the above or another path forward.

Add CLI commands for CRUD of subject mappings conditions. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Blockers

• opentdf/platform#171
• opentdf/platform#278

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

As an admin, I want the ability to specify the output of all CLI commands as JSON rather than rich text so that I can save it to a file or pipe it to another command (i.e. jq)

Acceptance Criteria

• create a universal flag to specify output
• create a shared CLI helper that drives output based on user configuration
• output the appropriate format

Generally, the work we've been doing has been categorized under Policy. To date we've put all these commands at the top-level.

We need to update the commands to reflect the following image

Proposed tree

.- <root>
|-. policy
|  |-. attributes
|  | '- <CRUD>
|  |-. attribute-values
|  | '- <CRUD>
|  |-. namespaces
|  | '- <CRUD>
|  |-. subject-mappings
|  | '- <CRUD>
|  |-. resource-mappings
|    '- <CRUD>
|-. peps
|  '-. sharepoint
|     '- config
|       '- <config-CRUD>
`-. pdps
    '- tagging
      '- config
        '- <config-CRUD>

<CRUD>
- create
- get
- list
- update
- delete
</CRUD>

Acceptance Criteria

• update commands to dump all of our current commands under a `policy command

Add CLI commands for CRUD of Subject Condition Sets. Commands:

create
get
list
update ^{1 2}
delete

Acceptance Criteria

1. add CRUD commands
2. use flags to drive properties for create and update

• cmd create --property
• cmd update --property

3. use flags to drive selectors for get and list (if exists)

• cmd get --status inactive
• cmd list --status inactive

4. leave test instructions as issue comment

Background

#30 introduced a global CLI flag and config to output styled or json. Metadata (optional labels with key/value pairs, created_at, updated_at) exists on the following Policy Objects and should be rendered in styled table output for their CLI commands when available:

1. Namespaces
2. Attribute Definitions
3. Attribute Values
4. Subject Mappings
5. Subject Condition Sets
6. Resource Mappings
7. Key Access Server Registry

Depends on

• opentdf/platform#355

Acceptance Criteria

1. Styled table output universally and consistently renders any metadata labels available on a Policy Object
2. Styled table output universally and consistently renders created_at timestamp information
3. Styled table output universally and consistently renders updated_at timestamp information

We need a simple quickstart document and a more comprehensive "CLI Usage" document explaining how to use the CLI. It should not cover how to spin up the DSP backend, that should be covered in the backend REPO.
It should cover all the common use-cases for interacting with the platform

• How to define how to create a resource
• How to CRUD an attribute
• How to CRUD an attribute value (and why)
• How to configure Idp
• WIP - more to come

Update to use the new go get github.com/opentdf/opentdf-v2-poc/sdk@sdk-wrapper

There is a universal ResourceDescriptor (typically under Descriptor_ on a given Resource Definition) that allows several optional fields to be supplied and tied to the resource being created/updated. It is cumbersome to manage and pass all of these flags individually, and we have discussed the feasibility of passing JSON to the flag. It could be hand-written as --metadata={"descriptorKeyName":"someValue"} to start, and eventually piped in or ingested from a file where the filepath is provided (such as --metadata-file=../descriptor.json)

With the recent platform changes, the CLI is not fully functioning. We need to update the SDKs and restore functionality.

Blockers

• opentdf/platform#278
• opentdf/platform#171

Dependencies

• #62
• #10
• #36
• #33

Acceptance Criteria

• update the SDK
• test each command and fix connectivity
  • if a command is missing features or the work is larger than expected, create new issues to capture the work
• change delete to deactivate
• show status on table view

Background

Issues: opentdf/platform#108 & opentdf/platform#96

Delete of attributes, attribute values, and namespaces is now a dangerous destructive action the platform will make available via an unsafe service and dangerous rpc's. Tructl needs to be updated due to these changes.

Acceptance Criteria

Relevant resources: attributes, attribute values, and namespaces

• DELETE commands/handlers should be updated to DEACTIVATE
• Help flag response should inform tructl users that they can deactivate but not delete them
• LIST commands should be updated to default to querying ACTIVE state resources, but optionally query for ANY or INACTIVE if a user wants to LIST those states
• GET/LIST commands should show state in the response data

Goal is to implement e2e tests for the CLI and the OpenTDF platform using the CLI

Depends on

• #33
• (optional) #73
• (optional) opentdf/platform#355

Acceptance Criteria

• implement policy
  • CRUD attributes
  • CRUD attribute values
  • CRUD attribute namespaces
• identify painpoints and doc drift (add as comment to this issue)

We need to create a Testrail project to capture e2e tests which will then be used to create the tests.

Depends on

• #26

Acceptance Criteria

• Create Testrail project
• Document all e2e tests needed
  • Use the CLI documentation to drive this

This issue is WIP.

Background

There is a desire to support multiple sources of truth to associate a Subject (user, PE, NPE) via Subject Condition Sets (SCS) and their Subject Mappings (SM) to Attribute Values on data resources. These may look like:

1. Identity Provider (idP) Access Tokens
2. idP user info
3. trusted PEP-derived context
4. fetched data from an external source (i.e. a platform owner's external /userSettings or /userInfo endpoint for the rest of their services)

When admins are creating Subject Condition Sets and their mappings to values, they should have a playground to test that with: a) a test input of any of those sources of external Subject context (as they are supported) and b) a test Subject Condition Set, there is a logical match of the SCS for the Subject. For example:

Example playground test "match/no match" scenarios:

Subject: copy/pasted JWT access token
Selection: checkbox of idP plugin to load (and probably its running endpoint)
SCS: test SCS

Subject: copy/pasted list of fields/values (assumed to be a PEP-driven flow where the PEP can attest to the user)
Selection: empty/default
SCS: test SCS

Subject: copy/pasted JWT access token
Selection: data fetcher
SCS: test SCS

This is distinct from an access decision playground like ABACUS because it would be isolated to testing any dynamic idP plugins, any selector syntax in the subject_external_fields in the SCS, and any AND/OR/IN/NOT_IN logical matching within the SCS. A playground like ABACUS tests one level higher where a Subject's matched attribute values are already resolved through the mappings and the test is pairing Data attributes with Subject attributes to make a decision. It is likely this playground could exist within the higher level playground to e2e test Subject -> SCS/SM -> attribute values -> + data attributes -> access decision, but it should also exist and be able to be run independently.

We need the ability to integrate with Ollama and LangChainGo so that we can explore various LLM solutions for meeting customer's need with managing DSP.

https://github.com/jmorganca/ollama
https://tmc.github.io/langchaingo

LangChainGo + Ollama: https://tmc.github.io/langchaingo/docs/getting-started/guide-ollama

Add CLI commands for CRUD of namspaces. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

Add CLI commands for CRUD of kas-grants. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

Enums:

• attribute rules
• subject mappings operators

Table schema with valid values

Acceptance Criteria

• Attribute Rule and Subject Mappings Operator flags list valid values in -h
• Attribute Rule and Subject Mappings Operator flags provide valid values in the error message given when they have been mistakenly omitted from a create/update and are required

See GitHub repository branch protection setting and TF provider info

Background

With the work for opentdf/platform#383, the CLI now needs to utilize a token within the SDK calls throughout, bringing the work in #63 to working e2e.

Acceptance Criteria

1. auth flow driven by CLI can store a token for later use
2. all Policy CLI commands authenticate their requests through the SDK
3. updated README with any new instructions

Background

We need an access control list to be validated before the release action will run, or any OpenTDF developer could trigger a release of the CLI. See example: https://github.com/virtru-corp/.github/blob/36434ecc9bd5338987b386d7d4c75e7d1b148ba9/virtru-actions/security-actions/check-release-permissions/action.yaml#L12

Acceptance Criteria

1. a release-acl.yaml file is added in .github with core team members added to the list
2. the release github action reads in that list and validates that the requester of the run is in that list
3. if they're not in the list, the action should fail

We need to ensure we have quality enforcement enabled for this repo.

Acceptance Criteria

• linting: https://github.com/marketplace/actions/run-golangci-lint
• unit tests: run: go test ./...
• end-to-end tests: run: e2e-tests/run.sh
• vulnerability check: https://github.com/marketplace/actions/golang-govulncheck-action
• conventional commits: https://github.com/amannn/action-semantic-pull-request
  • we will use PR titles to drive this
  • we will enforce squashing and using PR title and PR description for commit message

To ensure customers can download the CLI and use it to manage their platform, we need the optional ability to build binaries for each supported OS and architecture. This should be done with a Makefile such as example Makefile

Supported GOOS and GOARCH can be listed with go tool dist list

Acceptance Criteria

• implement builds with Makefile
• build binaries for the following platform and architectures
  • darwin/amd64
  • darwin/arm64
  • linux/amd64
  • linux/arm
  • linux/arm64
  • windows/amd64
  • windows/arm
  • windows/arm64

Background

Metadata labels (map[string]string) and description (string) can be optionally set on most resource tables throughout the policy config schema.

Acceptance Criteria

1. Metadata createdAt and updatedAt, set on the serverside, are always displayed in response to GET and LIST of a resource
2. Metadata labels and description are displayed in GET and LIST when they've been provided
3. The metadata display logic is reusable throughout resources

Add CLI commands for CRUD of resource-mappings. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

SDK changed upstream

Acceptance Criteria

• update the sdk
• test the build for breaks

We need to create GitHub workflows for driving the build process

Consider using:

• https://github.com/googleapis/release-please

Depends on

#22

Acceptance Criteria

• add a github action to drive the build process
• publish artifacts as releases

We need edit and create views for the policy config for the TUI

Acceptance Criteria

• create the edit and create views
• utilize charm's huh component to drive froms
• document solutions for abstraction to drive development of future interactive commands

Add CLI commands for CRUD of attribute-definition. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

Currently, we are packaging our python-based LLMGen as an OS specific binary, that needs to be distribured with the main package.

To that end, we need to incorporate a CI step that will pull and build the LLMGen repo and package it with the CLI

Background

Soft-delete/deactivation was added for Attributes, Namespaces, and Attribute Values in opentdf/platform#108 & opentdf/platform#96. The tructl CLI should have support for flags on LIST of those three Objects to filter by state active, inactive, or any, with active as the default fallback.

Acceptance Criteria

1. a familiar flag convention is employed to filter LIST calls by active state
2. that flag convention is consumed when LISTing Namespaces, Attribute Definitions, and Attribute Values in RPCs
3. the helper flag -h should clarify that active is the default filter applied with no flags provided, which is the default behavior serverside

The major commands will be the noun the user is interacting with such as attribute, or keyserver and the subcommands are create, get, list, update, and delete.

Namespace Commands

1. List Namespaces

   • Command: tructl namespaces list
   • Description: Lists all namespaces.
   • Examples:
     • tructl namespaces list

2. Get Namespace

   • Command: tructl namespaces get <id>
   • Parameters: <id> - The unique identifier of the namespace.
   • Examples:
     • tructl namespaces get 123e4567-e89b-12d3-a456-426614174000

3. Create Namespace

   • Command: tructl namespaces create <name>
   • Parameters: <name> - The unique name of the namespace.
   • Examples:
     • tructl namespaces create FinanceDept

4. Update Namespace

   • Command: tructl namespaces update <id> <name>
   • Parameters: <id> - The unique identifier, <name> - New name for the namespace.
   • Examples:
     • tructl namespaces update 123e4567-e89b-12d3-a456-426614174000 NewName

5. Delete Namespace

   • Command: tructl namespaces delete <id>
   • Parameters: <id> - Identifier of the namespace to delete.
   • Examples:
     • tructl namespaces delete 123e4567-e89b-12d3-a456-426614174000

AttributeDefinition Commands

1. List AttributeDefinitions

   • Command: tructl attributedefinitions list
   • Description: Lists all attribute definitions.
   • Examples:
     • tructl attributedefinitions list

2. Get AttributeDefinition

   • Command: tructl attributedefinitions get <id>
   • Parameters: <id> - ID of the attribute definition.
   • Examples:
     • tructl attributedefinitions get 123e4567-e89b-12d3-a456-426614174000

3. Create AttributeDefinition

   • Command: tructl attributedefinitions create <namespace_id> <name> <rule> <metadata_json>
   • Parameters: <namespace_id>, <name>, <rule>, <metadata_json>.
   • Examples:
     • tructl attributedefinitions create 123e4567-e89b-12d3-a456-426614174000 Color Enum '{"description":"Color attribute"}'

4. Update AttributeDefinition

   • Command: tructl attributedefinitions update <id> <namespace_id> <name> <rule> <metadata_json>
   • Parameters: <id>, <namespace_id>, <name>, <rule>, <metadata_json>.
   • Examples:
     • tructl attributedefinitions update 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174000 NewName Enum '{"description":"Updated description"}'

5. Delete AttributeDefinition

   • Command: tructl attributedefinitions delete <id>
   • Parameters: <id> - ID of the attribute definition to delete.
   • Examples:
     • tructl attributedefinitions delete 123e4567-e89b-12d3-a456-426614174000

AttributeValue Commands

1. List AttributeValues

   • Command: tructl attributevalues list
   • Description: Lists all attribute values.
   • Examples:
     • tructl attributevalues list

2. Get AttributeValue

   • Command: tructl attributevalues get <id>
   • Parameters: <id> - ID of the attribute value.
   • Examples:
     • tructl attributevalues get 123e4567-e89b-12d3-a456-426614174000

3. Create AttributeValue

   • Command: tructl attributevalues create <namespace_id> <attribute_definition_id> <value> <members_json_array> <metadata_json>
   • Parameters: <namespace_id>, <attribute_definition_id>, <value>, <members_json_array>, <metadata_json>.
   • Examples:
     • `tructl attributevalues create 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174001 Blue '[]' '{"description":"Blue color value"}'

`

4. Update AttributeValue

   • Command: tructl attributevalues update <id> <namespace_id> <attribute_definition_id> <value> <members_json_array> <metadata_json>
   • Parameters: <id>, <namespace_id>, <attribute_definition_id>, <value>, <members_json_array>, <metadata_json>.
   • Examples:
     • tructl attributevalues update 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174001 Red '[]' '{"description":"Updated to Red color"}'

5. Delete AttributeValue

   • Command: tructl attributevalues delete <id>
   • Parameters: <id> - ID of the attribute value to delete.
   • Examples:
     • tructl attributevalues delete 123e4567-e89b-12d3-a456-426614174000

KeyAccessServer Commands

1. List KeyAccessServers

   • Command: tructl keyaccessservers list
   • Description: Lists all key access servers.
   • Examples:
     • tructl keyaccessservers list

2. Get KeyAccessServer

   • Command: tructl keyaccessservers get <id>
   • Parameters: <id> - ID of the key access server.
   • Examples:
     • tructl keyaccessservers get 123e4567-e89b-12d3-a456-426614174000

3. Create KeyAccessServer

   • Command: tructl keyaccessservers create <key_access_server> <public_key> <metadata_json>
   • Parameters: <key_access_server>, <public_key>, <metadata_json>.
   • Examples:
     • tructl keyaccessservers create KeyServer1 "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC..." '{"location":"Server Room 1"}'

4. Update KeyAccessServer

   • Command: tructl keyaccessservers update <id> <key_access_server> <public_key> <metadata_json>
   • Parameters: <id>, <key_access_server>, <public_key>, <metadata_json>.
   • Examples:
     • tructl keyaccessservers update 123e4567-e89b-12d3-a456-426614174000 KeyServer2 "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD..." '{"location":"Server Room 2"}'

5. Delete KeyAccessServer

   • Command: tructl keyaccessservers delete <id>
   • Parameters: <id> - ID of the key access server to delete.
   • Examples:
     • tructl keyaccessservers delete 123e4567-e89b-12d3-a456-426614174000

ResourceMapping Commands

1. List ResourceMappings

   • Command: tructl resourcemappings list
   • Description: Lists all resource mappings.
   • Examples:
     • tructl resourcemappings list

2. Get ResourceMapping

   • Command: tructl resourcemappings get <id>
   • Parameters: <id> - The unique identifier of the resource mapping.
   • Examples:
     • tructl resourcemappings get 123e4567-e89b-12d3-a456-426614174000

3. Create ResourceMapping

   • Command: tructl resourcemappings create <attribute_value_id> <terms_json_array> <metadata_json>
   • Parameters: <attribute_value_id>, <terms_json_array>, <metadata_json>.
   • Examples:
     • tructl resourcemappings create 123e4567-e89b-12d3-a456-426614174000 '["term1", "term2"]' '{"description":"Mapping for a resource"}'

4. Update ResourceMapping

   • Command: tructl resourcemappings update <id> <attribute_value_id> <terms_json_array> <metadata_json>
   • Parameters: <id>, <attribute_value_id>, <terms_json_array>, <metadata_json>.
   • Examples:
     • tructl resourcemappings update 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174001 '["newTerm1", "newTerm2"]' '{"description":"Updated mapping description"}'

Delete ResourceMapping

• Command: tructl resourcemappings delete <id>
• Parameters: <id> - Identifier of the resource mapping to delete.
• Examples:
  • tructl resourcemappings delete 123e4567-e89b-12d3-a456-426614174000

SubjectMapping Commands

1. List SubjectMappings

   • Command: tructl subjectmappings list
   • Description: Lists all subject mappings.
   • Examples:
     • tructl subjectmappings list

2. Get SubjectMapping

   • Command: tructl subjectmappings get <id>
   • Parameters: <id> - The unique identifier of the subject mapping.
   • Examples:
     • tructl subjectmappings get 123e4567-e89b-12d3-a456-426614174000

3. Create SubjectMapping

   • Command: tructl subjectmappings create <attribute_value_id> <operator> <subject_attribute> <subject_attribute_values_json_array> <metadata_json>
   • Parameters: <attribute_value_id>, <operator>, <subject_attribute>, <subject_attribute_values_json_array>, <metadata_json>.
   • Examples:
     • tructl subjectmappings create 123e4567-e89b-12d3-a456-426614174000 EQUALS "role" '["admin", "user"]' '{"description":"Mapping for a subject"}'

4. Update SubjectMapping

   • Command: tructl subjectmappings update <id> <attribute_value_id> <operator> <subject_attribute> <subject_attribute_values_json_array> <metadata_json>
   • Parameters: <id>, <attribute_value_id>, <operator>, <subject_attribute>, <subject_attribute_values_json_array>, <metadata_json>.
   • Examples:
     • tructl subjectmappings update 123e4567-e89b-12d3-a456-426614174000 123e4567-e89b-12d3-a456-426614174001 NOT_EQUALS "department" '["HR", "Finance"]' '{"description":"Updated subject mapping"}'

5. Delete SubjectMapping

   • Command: tructl subjectmappings delete <id>
   • Parameters: <id> - Identifier of the subject mapping to delete.
   • Examples:
     • tructl subjectmappings delete 123e4567-e89b-12d3-a456-426614174000

Deployment of releases has some rough edges.

Details

Signing binaries

Binaries built with Go cannot be executed easily across Apple environments due to the lack of signatures. We need to set up signing certs to ensure our releases are executable.

https://www.kencochrane.com/2020/08/01/build-and-sign-golang-binaries-for-macos-with-github-actions/

Ref: https://github.com/gohugoio/hugo/releases/tag/v0.124.1

Compressing

Some environments have issues with downloading executables. By compressing them, they can be downloaded. Compression formats should be familiar to the platform.

• windows: zip
• macos: tar.gz
• linux: tar.gz

Calculate checksums

Example:

cat tructl-0.2.0-darwin-arm64 | gzip -1fc | tail -c8 | od -t x4 -N 4 -A n | xargs

Acceptance Criteria

• sign binaries for required platforms
• compress the binaries so that they can be downloaded on any platform
• calculate checksums
• test the binary by downloading

Description

User's who are evaluating DSP and OpenTDF need help to understand how the system works and what their role will be when administrating the platform.

Non-fed scenario context:

• medical

Dependencies

• Create new CLI command
• Scaffold basic TUI interface
• ...
• Demo scenarios
  • Starting up OpenTDF (booting the services, using the CLI)
  • Experience Control (adding attributes, encrypting, decrypting, removing attributes, test)
    • Add an attribute
    • Entitle someone with the attribute
    • Try decrypting data
    • Inspect policy (see what the data looks like and who would have access)
    • Inspect entity (see what the entity would have access to)
  • Visibility (execute small scenarios and see audit change)
  • Simulate sharing with another entity
    • User A creates data
    • User A sends data via email to User B
    • User B does not have access and responds to email
    • User A makes request with Admin
    • Admin grants User B with attributes
    • Admin let's User A know
    • User A let's User B know
  • ...

Feedback

@astanley1 - has used some "learn to code" websites and finds the demo and live experience very helpful

@suchak1 - feels that it will be helpful and having self-contained documentation would be very useful. Recommends having tests to ensure the demo doesn't break.

@jakedoublev - finds it "pretty sweet" but wants more clarity about where each CLI will live

There is a JSON parse error being caused by improper handling of zero values and nil JSON resulting from the empty string flag for a new subject condition set when creating a subject mapping.

Add CLI commands for CRUD of attribute-values. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• add create attribute value to the create attribute request
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment

Background

After #67 closing #10, there is a need to allow creation of a Subject Condition Set while a Subject Mapping is being created.

Dependencies

Blocked by: #71

Acceptance Criteria

1. flags are utilized so that a SCS can be created simultaneously while policy subject-mappings create is invoked
2. if a new SCS is not created when the SM is created, an existing id is still utilized instead
3. the user receives an error state if they provide both the SCS id flag and the values to create a new SCS simultaneously on SM create
4. context about the created SCS is also provided to the user along with the create SM response

Background

As a policy administrator, I need help visualizing how my Policy Objects relate to one another so I can understand what an ABAC platform actually does regarding my data.

There is a powerful visualization library in Javascript built expressly for data visualization: D3.js (see trees and clusters).

Dependencies

• opentdf/platform#110

Acceptance Criteria

1. Determine a path forward, taking into consideration:
   • comparative LOE to build a D3 visualization into an SVG that is rendered in the terminal with interactivity
   • comparative LOE to build a static HTML file a user can double-click to render in their browser
2. A self-documenting CLI command that builds the visualization with real data (see note: could be real data from DB or provisioned fixtures)
3. Based on the outcome of 1, build the visualization with D3

Add CLI commands for CRUD of kas-registry. Commands:

• create
• get
• list
• update ^{1 2}
• delete ³

Acceptance Criteria

• add CRUD commands
• use flags to drive properties for create and update
  • cmd create --property <prop-value>
  • cmd update --property <prop-value>
• use flags to drive selectors for get and list (if exists)
  • cmd get --status inactive
  • cmd list --status inactive
• leave test instructions as issue comment