Ability to setup Sunbird with 'optional' features / modules

[amarts]

Usecase

1. I would like to keep my revocation registry based on a distributed ledger.

Sunbird RC contains most of the modules to manage Verifiable Credentials. But, to keep the state of the credential after its issued to the holder, I would prefer to use a distributed ledger (aka, blockchain). This may not be a feature which is needed for every deployment, but if one wants it should be easier to enable in the setup.

Example, as of now, the docker-compose file is containing many services, which can be taken out if one doesn't need it. Similarly, this can be feature inside of the same process, but mostly controlled by ENV variables. (We can discuss the design possibilities separately).

2. modular VC output options

While VC standard defines how the VC fields are to be used, the specifics of how one uses each fields (for example, issuer can be a DID, or an object with name and email, or an uri / urn defining specific entity. Same applies for schema definitions. Schema used for the credentialSubject verification can be a resolvable identifier, url or embedded completely in the same VC object itself.

Soon, Sunbird RC may have more than 1 way of generating this VC output, and we surely need to make it modular, and easy for one to pick the VC output module.

3. I am using optional DLT feature, but I want to use some other DLT project than the one provided here?

This should be easy to achieve with code changes limited to just one file, and basic RPC call/ SDK integration for those specific chain.

One thing to look for here is, due to the new DLT, none of the VC format, nor the internal APIs should change.

---

I am a n00b w.r.to Sunbird code, even though I am aware of the trust ecosystem (VC/DID/issuers/holder/verifiers etc). opened this discussion thread to get started on possible discussions on these pluggable module architecture. Also as I understand Sunbird RC doesn't want to mandate the usage of DLT as a requirement for every deployment, so, even if the feature is provided, it should be optional only.

Considering many institutes are using Sunbird RC, and some of the projects would ask for possible DLT integrations at the later point of the time, my thought of opening this discussion was to have DLT thought process into Sunbird as an option, so project expansion if the developers / users needs at some point in time later, becomes easier without any architectural changes to existing deployment).

Happy to hear what others think. I will be updating this thread with my findings, and some proposals on how this can be achieved, and once design / thought process is in agreement, me and team would like to contribute to that section.

[sankarshanmukhopadhyay]

This work has come about considering the "verifier experience" and the challenges recipients have around credentials created/signed with older keys. The introduction of a DLT and a credential issuance workflow enables easier key management and recognition of all sets of keys (both old and new). The DLT also enables a defined endpoint for verifiers when credentials issued across multiple ecosystems must be considered.