Implement a multi-tenant OrgBook Issuer Service (OBIS)

swcurran commented 3 years ago

Implement a multi-tenant OrgBook Issuer Service (OBIS) that supports multiple trusted issuers to issue credentials to OrgBook BC. This effort will combine a number of capabilities recently added to ACA-Py, and will likely uncover additional features that will need to be added to the functionality.

Basic Architecture

This shows the basic architecture of the Issuer using Buy BC as an example issuer:

Components

Some components that are expected to be needed are listed below.

Admin API

An admin API will be used to manage the activation and deactivation of issuers. A UI will (eventually) use the Admin API to manage the full set of issuers. In creating a new issuer in the service, a unit of storage (aka wallet) will be created for the issuer within the OBIS.

Issuers starting by using the OBIS may later want to run their own issuer. It should be possible to export the storage for an issuer from the multi-tenant instance and import the contents into a single-agent storage container, allowing an issuer to run their own instance. This doesn't have to be automated or even easy, but should be thought through and tried as far as possible.

Issuer API

An issuer API will be used by the issuers to:

Configure their issuer.
Register with the OrgBook BC
Issue configured credentials

Each issuer will:

Use their own storage in the multi-tenant issuer.
Manage their own OrgBook Issuer configurations — credential schema, OrgBook mappings, language translations, etc. While the configurations will be in the issuer, the operations around publishing the necessary transactions to the ledger will be handled by the OBI.
The issuers will have their own DID and create other ledger objects, as necessary. Since the issuers will not (usually) be Sovrin Endorsers, most will have to use the "Please Sign This" protocol to have their objects signed before being written to the ledger.
Issue credentials as required by the credential lifecycle and the business logic of the issuer organization.

Endorser Service

Since transactions need to be signed be an endorser an "Endorser Service" must be deployed and access to the Endorser managed. To be determined if the service is built into the OBIS or is external.

esune commented 3 years ago

@swcurran how are we planning to deal with revoking a credential?

Currently, credentials are not "really" revocable and it is a state that is managed by issuing a new credential for the same topic/cardinality values, with a different state (an attribute). It is not possible to just revoke a credential without issuing a new one - this use case seems like it would be pretty important for certifications, licenses, etc.

Supporting "real" revocation would not only require the supporting code on the consumer's controller end, but updates to Aries VCR to support that.

swcurran commented 3 years ago

For the OrgBook Issuer/Aries VCR use case there is no revocation and it is up to the business logic as you mentioned above.

When we get to the general MT issuer that supports issuing to wallets, revocation can and will be used. But in that case, there will be no Aries VCR component, and so that won't be an issue.

esune commented 3 years ago

For the OrgBook Issuer/Aries VCR use case there is no revocation and it is up to the business logic as you mentioned above.

Ok, thank you for the clarification. This kind-of simplifies the scenario a bit as I will NOT have to worry about this.

I am still wondering, however, whether we should support revoking a credential without issuing a new one: from a timeline perspective it would be nice to be able to see an end date and/or gaps between the same license being issued, expiring and re-issued. One example of this could be the relationship credentials for directors, see this view: https://dev.orgbook.gov.bc.ca/en/organization/registration.registries.ca/BC0481127

Probably not something I will worry about at this time, but something that we may note.

esune commented 1 year ago

This was addressed by https://github.com/bcgov/aries-vcr-issuer-agency. Next steps will be integrating it with https://github.com/bcgov/traction as an option to using its own tenant management.

bcgov / von