dynamic ledger authorization table lookup for endorsers

[burdettadam]

Currently, assumptions are made about the auth table stored on indy ledgers during checks for an endorser. For example, the role of an endorser will always have the authority to endorse new did (nyms) transactions. This assumption does not hold true for all indy ledgers since Indy ledgers allow customization of the auth table.

We could instead, retrieve the auth table from a ledger and encapsulate permissions logic to act accordingly. It is also worth noting if a ledgers fee table is active, the auth table behavior can change as well.

This issue hinders multi-ledger support.

[swcurran]

I'd like to have a discussion about this if you are interested. What I've been thinking:

• create a repo that is "aries-endorser-service" that is an endorser controller implementation.
  • For local dev and testing, there would be a docker-compose of an ACA-Py agent and the controller and perhaps an simple issuer for testing
• Have an implementation of a controller that implements the "--auto" behaviour, so it has all the webhooks received and handled, but with no business logic for making decisions.
• Have an implementation of a controller with business rules that includes a web-based UI for handling endorsement requests
  • If the author has never been heard of the author before or there is no "auto-approve" rule in place (see later), put the request in a queue to be handled by humans
    • NOTE: this might be where we consider a rules engine with a built-in interface...
  • Allow the human to add metadata about the author
    • TBD -- can metadata about the author be automagically collected before passing to the human?
  • Allow the human to accept/reject the request.
  • Provide some auto-processing options for the human to apply to future requests from the author (e.g. always ask, always approve, approve the next N requests, notify when N - X have been processed so I can decide to approve some more....)
• Add support for multiple ledgers so that the endorser can approve requests for issuers to write to multiple ledgers.
  • This requires that the Public DID of the Endorser can be different from the Endorser DID.
  • Include in the request from the author the target ledger (once we have did:indy, this is automatic...)
  • The Endorser would have to have multiple Endorser DIDs, one per ledger the authors can use.

Note that this service can also be a Trust Registry, that might give a VC to the authors to indicate their authority to issue credentials and/or respond to requests for information about issuer DIDs about their authority to issue credentials.

We (BC Gov) think we need this such that we have one Endorser across all of BC Gov, so it is aware of all issuers in the Enterprise and serves as a central repository (Trust Registry) for BC Gov. We think this can be built relatively generically, so that it can be deployed in other organizations and tuned as needed.

[burdettadam]

Brilliant! You have put a lot more thought into this than I have, but I recognize the need. ACA-Py would still need a process for looking up the auth table and then retrieving the required signatures/fees for a transaction. Separating concerns of an endorser into an "aries-endorser-service" would make things easier to implement. @frostyfrog has put some thought into the endorser's topic as well. @frostyfrog, do you have any insights to share?

[TheTechmage]

Funny that this was brought up, @dbluhm had recommended that I code up something similar to the aries-mediator-service as an endorser service. The initial goal of which is to handle endorsement requests in an automated manner. As I've been experimenting with ACA-Py to figure out Author/Endorser transactions, however, I've noticed that there are inconsistent responses from ACA-Py. Particularly when publishing SCHEMAs and CRED_DEFs. For instance, when I'm working directly against an agent with ENDORSER privileges to create a SCHEMA, I get a SchemaSendResultSchema formatted response. However, when I work against an agent with AUTHOR privileges, I get a TxnOrSchemaSendResultSchema formatted response with the sent property being UNSET.

The inconsistent behavior means that you can't have one code path in an application that's written against ACA-Py. As soon as an agent host switches to using the Author-Endorser workflow, the code in applications that rely on certain API calls may break if they don't account for the change in behavior.