Future Considerations (Digital Registries)

DRS-3 Add fields to DB schema. 

Does that means that collection types are not supported? For example, I want Applicant to submit her employments records history and I will define fields for one employment and then I want to define a history object, which is collection of employment records sorted by time. Then I want to add some validation rules not to a field but to a collection. Can I do that? How can I do that?

In most cases, the validation is done upon capturing data (Registration BB).

In Digital Registries basic validation rules for single records are in place (required, unique). 

When the use case requires adding more validation functionality (e.g. to collection types), it will be added in the next iteration. 

Done

Associated meta data against (for) these actions (Enrol, Authenticate, Consent, Attest, Claim, Discover and Update actions ) MUST be part of the registry to bring in the authenticity and non-repudiability of registry data.

The UI and API has all necessary functions. If new functions are needed then these will be added during  develop time. 

11.1 Integration with a blockchain solution to guarantee the integrity of the data and logs. The function would notice unauthorized changes in data. This option may be available with a fee therefore should be optional. 

Registries MUST support verifiable credentials (W3C VC) services using the trusted registry data as an integrated service with in this BB. This VC SHALL work both in Online and Offline modes.

11.8 Enable to connect Digital Registries BB to Verifiable Creden tial networks   (W3C VC). 

Data MUST be secured during capture, transmission and rest with right encryption along with integrity protection.

Data is secured when in transit by Information Mediator (BB). The communication uses encryption in all endpoints.

Data in rest will be taken as a next challenge in V2. 

Integrity protection is planned in V2 as well. 

12.9 Analyse a way to enable analyst to decide which data must be encrypted while in rest. The goal is to secure data while in rest.  

Data MUST be protected for privacy with appropriate roles and access permission for downstream consumption. This SHALL be using other BBs.

Yes, in Key Digital Functionalities chapter we describe it like this: 

12. Manage access to registry data. Authorize users to see and edit registry records or data field (ABAC based access management). 

DRS-6- Authorization to create and manage databases, API usage and access to DATA. 

Additional requirements will be added based on real Use Cases. 

Data MUST be protected by proper anonymisation with analytics and related reporting functions.

11.10 Data MUST be protected by proper anonymisation with analytics and related reporting functions. Proper analysis and user requirements mapping must be done based on a real use case.  

The scope is limited to simple registries. In real life, we are likely to have registries that require a multi level structure. In RDBMS terms, the data for a registry may need to be stored in multiple tables. It is not easy to handle such entities by defining foreign keys among tables. There should be a clear mechanism identified to handle digital registries that have a multi-level structure.

While it may appear easy to create a new API end point for every version, this places undue burden on the calling systems. Whenever a new API version is launched, the calling system will have to be modified to refer to the new API end point. 

It is also quite difficult to invoke different API end points from the same front-end. Instead of this, the API end point should remain the same and the payload should indicate the version.

The requirements are based on a USE CASE with minimal viable product methodology. Therefore the complex database structure was not needed, thus the requirements focused on simple case. However the requirements to build more complex data storing structures can be added when use cases require it.  

Digital Registries enables to create multi level registries. 

For example if we rename a database to a table, and tables can be linked with foreign keys, then we have a multi level registry. In Digital Registries description we decided to name the tables as databases because this improves the user experience.  See example illustration below: 

Open

 The issue with API endpoint versions may need some clarification in the specification. 

Currently we have written (DRS-4):

“Publish uses versioning. Every publish creates a new version of the database schema;   

Old database schemas must be available to the users;

Data stored in the old database versions must be usable in old versions and in new versions; “

This description should be clear enough to explain that the users can still work with old API versions and do not have to switch to new API versions right away. However there is a risk that large schema changes may influence the old APi versions and therefore the system has a limit. We will analyze the risks and schema version options in the V2. 

2.2 Event based notifications.

I see that as an issue. Subject of the Registry record may have specific life-cycle and on event of life-cycle there is a need to do some things, which is the reason why Registry even exists. For example, when driver license is expiring and state cannot notify person about that - I would say it is dysfunctional registry of driver licenses.

Yes, this function will be added in the iteration 2. Use cases did not require such functionality right away.

11.4 Event based automated data export from Registries BB to legacy databases. Connection with messaging and workflow BB is required. Done- See req. DRS-35.

Done

DRS-3

you should add also time range

Modifications acceptable but to be taken up in future version

DRS-3

what kind of language should analyst to learn in order to express all that? One may provide, for example, embedded JavaScript editor. Will it be OK for being compliant with the spec?

We have no-code policy. Therefore, all functions must be available via user interface (and API). Advanced regex, JavaScript options could be added, but this is the decision in the implementation phase by the implementers.  

Modifications acceptable but to be taken up in future version

DRS-4 

before publishing I would recommend to have option for testing

Noted. Will be added to the future functionality.

1. Registries MUST support Enrol, Authenticate, Consent, Attest, Claim, Discover and Update actions using Registry and/or other BBs. Discover and update SHALL naturally fit into Registry BB.

Enroll, Authenticate is solved by Information mediator and Security BB. Additional IAM system will be available for authorization. 

Consent is in the scope of Consent management BB. Integration will be added in V2.   

4.4

there are couple of important technical requirements missing with regard to API. For example, see Payments BB section 6.1.1 API management Gateway. I suggest to have generic API requirements description and here just refer to that.

To be analyzed in V2. 

API Management Gateway 

Handles all the API messaging calls and API access control verification from other BBs to the Payment BB and vice versa as well as within the Payment BB. All requests from other BBs first go through the API gateway. The gateway then routes requests to the appropriate application/service. The API Management gateway will:

• Use Identity and access management for authentication
  
  

• Perform input validation checks to prevent oversized message attacks, SQL injection attacks as well as JSON and XML threats,
  
  

• Require authentication for all API users;
  
  

• Manage access quotas and throttling;
  
  

• Logging of all API calls made
  
  

• Allow API providers to limit the rate of consumption for all API users.
  
  

• Transform backend error messages into standardized messages so that all error messages look similar; this also eliminates exposing the backend code structure.

The authors try to treat analyst and administrator as one user category and applicant as another user category. It could be a better idea to have three distinct roles viz., analyst, administrator and applicant. The analyst should be responsible for preparing the design and he/she should control the database design. The analyst should have no role to play in data administration. That responsibility should be with the administrator. Otherwise, we may be combining the responsibilities of architects and operators.

Use cases currently do not require administrators. These role descriptions can be added later during implementation phase.  

11.11 Maintenance functionalities and roles to help everyday operations of registries. 

6.3 Conflicting - Earlier in the doc, it mentions views for personal data, but no information on how personal data should be accessed

Generic Comment - No ability to get user consent while accessing personal data.

According to our vision, personal data is like any other data that can be accessed by API or via user interface. Respective authorization must be granted in order to CRUD Personal data.  

The principles of user consent is governed by Consent Management BB. 

Modifications acceptable but to be taken up in future version. 

Decisions: I added a line in the Future scope for the Consent Management. 

11.7 Personal data usage in Digital Registries in synchronization with Consent Management BB capabilities.