Consent Feedback

4.3 - Interactions with other BBs

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)

Now

Create issue only once comment has been reviewed

4.4 - Functionalities

The links in this section should go to govstack.gitbook.io rather than app.gitbook.com

Now

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

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.

Now

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.

Now

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

Now

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.

Now