...
Source ID/Section | Comment | Feedback Type | Jira Issue |
|---|---|---|---|
4.1 - Assumptions | Section 4.1 should outline the key digital functionalities for this BB. As noted in the template, we can also define the components here in a section 4.2. Could this move to section 4.2? | Now | Task for Valeria/Steve/Wes |
4.3 - Interactions with other BBs | This section may also be best placed in section 4.2. In the table in this section, suggest a couple of changes: ID Building Block - this relationship is not clear. I assume the Consent BB will query the ID BB to verify a foundational ID as is shown in the diagram Digital Registries - can we also indicate that the consent may be stored either in a digital registry or in an app-specific data store/database (per TC conversation last week) | Next | |
4.4 - Functionalities | This should become section 4.1 and can be broken down by Key Digital Functionality. The links in this section should go to govstack.gitbook.io rather than app.gitbook.com The use cases and links provided here should be moved to Section 6 | Now | Task for Valeria |
5 - Cross-cutting requirements | I like the table outlining requirements from other building blocks. Could you provide a brief description of what this table is? Also in this section, there is one link to the security requirements. This link should be to http://govstack.gitbook.io rather than http://app.gitbook.com | Now | This needs to be reviewed across all BBs and brought in line with the template, after Arch Requirements are complete |
6 - Functional Requirements | Could we change the format to reflect the template here: https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/ugHOCsaCJ3B29gavXcd8/6-functional-requirements Also, could we use REQUIRED, RECOMMENDED, OPTIONAL instead of MUST/MAY. We are trying to move to this language across all BBs | Now | |
9 - Internal Workflows | Link to Workflow specification goes to Google docs. Can we update to point to the Workflow spec at govstack.gitbooks.io | Now | |
9 - Internal Workflows | Is the Workflow BB necessary for all Consent interactions, as shown here? Can an application access the Consent API directly or are we mandating the use of Workflow BB? | Next | |
6.3 - Consent audit requirements | In requirement “View and verify consents“ in description there is type: should be “verify consent“ instead of “consent agreements“ | Now | |
7.4 - Data Model | The referenced Appendix A does not provide clarity on how Revision of Agreement can be used to verify that valid Consent Record is done based on last valid update of Agreement: Agreement has a version attribute and Update operation. That means that after update it will get new version ID - unique identification seems to be ID + version ID. However, in the Revision there is only reference to the object ID, while unique key includes also version ID. That makes things unclear. I suggest, in the consent record you should use reference to agreement version or change definition of Revision. In data model it should be clear that Agreement and consent record consistency should be possible to verify before and after an update. Another option is to drop an Update operation for Agreement. | NowNext | |
8 - Service API-s /config/agreement/{agreementId}/PUT | The description for the PUT operation for the Agreement resource stipulates that “existing Agreement object is created“. PUT is used for update not for creation. If this operation will update existing record of existing Agreement, then one should describe, what will happen with consent records, which were created based on this Agreement. My understanding, that all consent records should be invalidated and notifications should be sent to individuals. | NowNext | |
8 - Service API-s /config/policy/{id}/PUT | In the policy PUT operation stated that existing Agreement is not affected. But data model in the Appendix A does not support that claim: it does not have reference to Agreement version | NowNext | |
8 - Service API-s | I do not think that Update operation for Policy and Agreement are good operations. However, if it is needed, then to support bulk invalidation of consent records on update of Policy or Agreement one should add PUT or DELETE operations to invalidate all consent records, which are done based on changed Policy or Agreement. | NowNext | |
7 | numbering of subsections should be corrected. There are now only sections 7.1 and 7.4 |