bcgov
Implement a multi-tenant OrgBook Issuer Service (OBIS)
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.
@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.
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.
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.
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.