Additional settings to handle connection requests in endorser service

[esune]

The dts-endorser-service instances used by BC Gov do not currently support auto-accepting connections from tenants in an "approved" managed instance (e.g.: Traction). This causes friction with tenants self-managing their settings, as well as delays in having an "enabled" issuer, especially for lower environments such as dev, test.

We need to improve the endorser API (found in https://github.com/hyperledger/aries-endorser-service) to be potentially able to auto-accept connections from a whitelist (all agents in an agency will have the same public endpoint) in order to streamline this process.

I believe the following describes the desired state:

• an unknown agent requests to connect with the endorser (using its public DID): the connection request is approved/denied manually by an admin using the API
• an agent from an agency in an allow list (e.g.: Traction instance) requests to connect with the endorser: the connection request is accepted automatically.

In Traction we are deciding upfront whether a tenant can/cannot connect to an endorser and therefore become an issuer and have endorsement requests accepted. Once an agent is connected to an endorser, all endorsement requests will be automatically approved (i.e.: no admin should have to action an API to approve a new schema/creddef, etc.).

Governance question: does this reflect where we want to be with BC Gov (have we even thought about this?), or a different pattern has been envisioned? I think this is the path of least friction and effort to manage resources, and accepting the request for a tenant (and allowing them to be an issuer or not) will act as proper governance "gate". Looking for input from @krobinsonca, @swcurran, @WadeBarnes and others.

[WadeBarnes]

@krobinsonca, @CharlesMacpherson, are the CANdy governance documents publicly available yet? If not can @esune get access to review?

[esune]

We had a chat yesterday, I will be creating a document with requirements base on my understanding of what we need to support for different use-cases.

[CharlesMacpherson]

emailed the GF to you both.

[CharlesMacpherson]

Sorry, the CANdy governance does not cover provincial operation of the endorser, only reference that is in their jurisdiction to manage it. We do not yet have any business rules for how we endorse. As a place holder, we should have business level decision on endorsing an agent DID, creddef or schema, and ensure it is aligned with DITP plans. Delivery team is best contact for those decisions via email. Obvious prod needs more robust approval processes. Dev and Test are less important, but we'd want test data that gets endorsed to be in line with what will go into prod

[swcurran]

I think we want to separate the technical capability — here is how and where we control access — from the application of the policy — the governance rules. We need a rough idea of the granularity of the access control, and the technical solution should enable those. From yesterday we got:

• No endorsement — no ability to write to the ledger
• Full endorsement — a DID created and the ability to write any other object
• No schema endorsement — a DID create and the ability to write any object except a schema (an issuer using a common schema).

Once the technical capability is there, “the province” can decide how to use the capability to enforce the governance rules.

[CharlesMacpherson]

I would put schema and creddef in the same category. once a DID is endorsed we may not want them to create a creddef related to an existing schema. It is as risky as them creating their own schema.

[swcurran]

If they can’t create a Cred Def, they can’t be an issuer, and they would fall back into the “No Access” territory. I don’t think we need to differentiate that.

Ah, wait...perhaps the access modes should be:

• None - no DID created.
• NEW Public DID (DID created, can update the DID and write an ATTRIB)
• Issuer no schema - DID, ATTRIB, CredDef, RevReg
• Issuer schema - same, plus Schema

I guess we might as well just have an on/off for all the object types - DID, ATTRIB, SCHEMA, CREDDEF (which included RevReg).

[CharlesMacpherson]

Right, I just mean no automatic endorsement. Would want issuer parties to be able to author these things, but would want manual intervention to approve them in the endorser. Likely the main thing we'd want to have auto-endorsed it a revreg entry from an approved issuer.

[swcurran]

Whoa…that’s a different plan than we talked about yesterday. What is planned is that on creation of a new Tenant, it would connect to an Endorser and be given (or not) access to write to the ledger.

Are you saying that each write transaction (other than RevReg operations) have to be individually reviewed and accepted?

That’s quite different than what we left yesterday’s meeting.

[swcurran]

With the follow up question — do we need that full control to be implemented now, or in the future? I don’t know if that would change the effort to implement the capability — if we need an approval of one type of request, I suppose it is not much different to get a approval for multiple types. Either way, a UI/review/accept/reject capability is required.

[CharlesMacpherson]

I'll talk to Kyle in the morning to get aligned.

[esune]

I see a couple of challenges in developing "full" access/permission control logic for the endorser:

• time (to develop the solution and then maintain it)
• user experience when triggering an action (i.e.: I request to create a new schema/creddef, but nobody is around and I wont get a response until the next day)
• operational load and coordination to be on top of auditing/approvals (btw, WHO would be responsible for deciding if something can be approved, regardless of who actually pushes the buttons?)
• overlap with other solutions (e.g.: Traction) and onboarding/Governance agreements that already cover at least part of the problem

A solution with the "minimal" set of access control rules required , as suggested by @swcurran , is probably the better way to go for now.

[swcurran]

Hmmm…how about this — we use a GitHub repo to handle the approvals? The Endorser would simply check on whether a certain GitHub repo contained the data to be approved, in the right place. No UI for the endorser — just an HTTP request to check if a file is in the right place, perhaps with some checking that it contains the right content. All the UI/approvals happen in GitHub.

This has the added bonus that the schema and issuer information can be published in a human consumable website.

[esune]

I'll gather my thoughts, but my initial feeling is that this is not less complicated than adding a configuration file that the endorser service API can use to drive its decisions. I still think we shouldn't have to approve everything, every time and the logic to handle automatic/known actions still needs to be implemented in the endorser API regardless of where that information is stored.

[CharlesMacpherson]

I discussed with Kyle and Stephen today. I am in favour of the github idea while we have low volumes. No need to build out a UI until we are really scaling. Retaining DIPT control of what is endorsed is important to me.

[swcurran]

Emiliano nicely refined the idea such that the Endorser will just know about files that are allowlists for writing transactions. Those files must be accessible over the Internet, but where are there is an Endorser deployment configuration.

For our uses, the files will be hosted in a Governance GitHub repo, and generated when a merge is done into the repo. This is similar to how the OCA Bundles repo works today where OCA bundles are submitted as PRs, verified (automated and human review), and approved/rejected. When approved, a script generates a list of OCA Bundles that a holder can load.

The allowlists will have enough detail such that when the Endorser receives a request to endorse a transaction, it will extract the details and look up in the allow list if the transaction has been approved. If in the allowlist — approved, otherwise rejected.

[esune]

Posted an issue with details: https://github.com/hyperledger/aries-endorser-service/issues/32

[esune]

Development work is completed as part of the previously referenced issue, updates to the services will be completed as part of https://github.com/bcgov/DITP-DevOps/issues/138