Trust Chain Retrieval API Restrictions

[DyrellC]

Problem description

When using the /trust-chain api as highlighted in the swagger files, I noticed that only an Auditor role account is allowed to use it. This seems an odd choice as the trust chain is relevant for other user roles such as Project Proponents and VVB's as examples. Even the Standard Registries cannot use this API, and instead use other API's in order to see the blocks more directly from the policies api. These API's are locked to the Standard Registry role.

These restrictions don't necessarily reflect user flows as they would be expected with relation to trust chains. The Auditor role restriction for the /trust-chain API for example restricting access for the Project Proponent means that there are limited options available for a data producer to monitor the state of trust chains and minting processes that are a direct result of the data that they are producing. From the Demia end, as highlighted in this HIP proposal discussion, we are looking to connect the data producers into the submission process via our platform, but in order to retrieve the results of those submissions, our user instance has to be tied to the Registry or Auditor roles (for the blocks search or trust-chain api calls respectively), which doesn't really make sense as they are more aligned with a Project Proponent role.

A middle-ware solution can be used as a workaround process to navigate the trust chains within a guardian instance by tying into the Auditor or Registry roles via a third party API implementation, but this enforces a search through all trust chains within the connected Guardian instance to extract relevant information and return it to the end user, rather than the end user interact with the instance directly through their own guardian credentials. This extra step would not be required if the API restrictions are reduced, and Project Proponents can navigate either the policy blocks or the trust-chain api's themselves.

Requirements

The trust-chain api should not be restricted to only the Auditor role, and/or the policy block api's should not be restricted to only the Standard Registry role.

Definition of done

• [ ] API's become accessible from other roles
• [ ] A better documentation process of trust chain retrieval from different roles or documentation on how to provide those privileges within the policy generation for the specified roles

Acceptance criteria

• [ ] Clear definition of which API's can be used by which user roles and why there are restrictions if there are any
• [ ] Examples/Tests demonstrating the ability to access relevant policy and trust chain information from different user roles defined within a policy