Define Architecture for LOB OrgBook Issuer

[hiteshgh]

We have the following ways to do a OrgBook Issuer:

• Standalone issuers that have their own ACA-Py deployment, and integrate the issueance of their credential into their own app, calling the DITP-managed ACA-Py deployment.
• The partially complete OrgBook Issuer Agency — a multi-tenant app purpose built to support multiple OrgBook Issuers. There is some UI for setting up the OrgBook Issuer, and an API for integrating into an LOB to carry out the issuances.

We also have Traction that could be used in the scenarios above:

• Instead of a standalone deployment of ACA-Py, we use a Traction instance, and everything else is done on the LOB side.
• We create a multi-tenant “Agency” app that knows about OrgBook Issuing, uses the Innkeeper interface to create the ACA-Py part of a tenant, and the Agency app handles the specialized OrgBook Issuer features. The LoB API remains the same.

Given where we are, if we had a new OrgBook Issuer arrive today, how would you deal with it? Assume you have a couple of months for the deployment, what would you do to enable the best long term solution?

Bonus points: A whole set of OrgBook issuers could operate by uploading Excel spreadsheets of their permits/licenses. How would you deal with that model? Imagine a town arriving, and wanting to define their credential, and then every week sending a spreadsheet of their licenses. The app checks any changes (additions, deletions, updates) and then updates are made to OrgBook via ACA-Py issuances.

[swcurran]

Updates to the description made @amanji @esune

[hiteshgh]

Assigned to Emiliano, Lucas and Stephen for review

[loneil]

Yeah I think the info above makes sense. Not sure if there's any further architecture to review or anything. I haven't seen the "partially complete OrgBook Issuer Agency"

If the Issuer Agency app is keeping a variable amount of tenants that could be used

• Is there persistence (a DB) planned for that app? Or would tenant secrets be environment/config?
• Does a single user or consumer of the Issuer Agency app have access to use any tenants the app has? Or is there a user/consumer>tenant mapping?

[esune]

The aries-vcr-issuer-agency was basically feature complete, when @amanji and I finished development. It is specific for OrgBook issuers and our thought was to see if/how we can hook-up Traction tenants rather than have the agency manage tenants independently (i.e.: the controller is managing all of the multi-tenancy stuff and exposing an api-key for each tenant to hide keys from them).

[loneil]

I've always had this "grand vision" that there could be some "Common Hosted VC Service" or something that allows different BC Gov areas that don't have ability to build or heavily edit their own LOB apps to do issuance/holding/verification through a secured common app. Kind of like how CHEFS works (and that gets heavy usage now) but with a lot more.

It could have

• persistence to securely keep Tenant access and other business config
• Keycloak (+ VCAuth) integration to have team management for tenants
• Some workflow engine that could import/integrate LOB data (API calls, ingestion jobs, spreadsheet imports like Stephen mentioned)
• Workflows to track issuance and verification jobs and intervention steps and stuff
• Custom forms creation for data input and things

Some hybridized ideas from CHEFS and NB Orbit enterprise platform. Tenant UI is still there as the tenant management console (just like Keycloak console interface), but some much more complex app that lets people actually do the things we don't want them doing in the Tenant UI.

But anyways, rambling... 😄 Would be a pretty big project, would need a lot of business use onboarded for any decent ROI.

But this issuer agency seems to have some of the beginnings of that concept.

[esune]

Yes, the idea is shared - also agree that the effort required is more than what we can spare right now as things get quite complicated quite fast.

For this issue, I think what we need to consider is how to integrate the existing aries-vcr-issuer-agency with traction: the issuer agency is a solution specific for OrgBook issuers, it already handles multi-tenancy (natively, not through traction) and provides a more user-friendly set of configurations (as well as a helper to put them together) than the aries-vcr-issuer-controller does. Now, we could stand-up the project as-is just to handle OrgBook issuers, however it would be nicer if we can use the traction agency and connect the API service to it.

I think the focus of this should be on:

• the issuer-registration plugin needs to be installed and work alongside the traction plugin (see https://github.com/bcgov/traction/pull/424 for reference).
• what changes would be required in aries-vcr-issuer-agency to use a traction agency, instead of a standalone one
• note that the issuer agency does all the handling for endorsement and DID registration, which would not be necessary with traction, we would just use the APi as issuing proxy (it has batching capabilities built-in) and to trigger the issuer-registration protocol when needed (schema mappings creation/update for orgbook)
• a gate to become an OrgBook issuer is to have a connection with the OrgBook agent: all tenants would have theplugin installed, only the tenants who receive and accept a connection invitation with the OrgBook agent would be able to do anything related to issuing to OrgBook

[hiteshgh]

@esune to advise on state of this ticket

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.