Yes, we can treat the Sunbird-registry as a master registry (a layer above the source databases), which is updateable (hence, “live” at all times) by any approved changes in the source databases. However, what constitutes an “update” and how should a “change in the source database” result in an “update” in the master-registry is determined by the business processes & rules established by the program. Technically, this is feasible.
Yes, this can be done through scripts that allow bulk import of the source data into the registry.
Yes, since SunbirdRC supports defining a registry schema using a JSONSchema format, the properties can be defined with validations like mentioned here: https://json-schema.org/draft/2019-09/json-schema-validation.html#:~:text=JSON%20Schema%20validation%20asserts%20constraints,descriptive%20metadata%20and%20usage%20hints.
Yes, the SunbirdRC UI supports the generation of dynamic forms, based on the schema created; as well as support creating “approval” workflows to aid the attestation & subsequent persistence of the “data” into the registry.
No, it doesn't support versioning now. This needs to be handled manually outside Sunbird RC 2.
Yes, field and user interface level validations can be defined
The schema needs to be created first, before seeding the data to the registry
Yes, Sunbird-RC supports “user login” and also ownership management for a schema. Hence if the registry needs to have “citizen” access; it can be enabled. Just a point to reiterate, the purpose of a registry can be non-individual centric as well (in which case, the authorized “user”, can be institutional staff roles as well).
Can we we use single sign on? or use any other authentication?
Currently, Sunbird works on Keycloak OAuth. However, we can write a custom service to authenticate the user, with other authentication methods.
Currently, consent is given by an individual to the entities that he/she has ownership of (i.e. to the entities which were created by him/her). Consent can be given to one or more attributes that are part of the schema.
Currently, consent can only be revoked manually. For time/count-based revocation of consent, we need to build a custom service to handle it.
Yes, attestation can be done with an external system. We need to write the functionality to enable data exchange between these two systems.
We have three services that uses Postgres.
- 1.Keycloak: Data related to user management, client management, realm management, consent etc will be stored
- 2.Registry core: All data created under the schemas will be stored.
- 3.Claims: All data related to attestation flows(claims) will be stored.
Sunbird RC can work on the below DBs:
- 1.Graph database (Neo4J)
- 2.Relational databases (Postgresql, HSQLDB, H2, MariaDB, MySQL, MSSQLServer)
- 3.NoSQL databases (Cassandra)