Future Considerations (Consent)

Version of Dec 7, 2023 by @Ain Aaviksoo

As per CON-41: Future enhancementIn Progress and Post partum & Infant Care Use-Case and discussion during BB meeting on Dec-1-2023 the suggested updates for the next release (v2.0) are as follows:

1. Extend Consent BB scope for extending the supported lawful basis of personal data use from just “consent” to any other (“contract”, legitimate use”) that requires signing by the Individual (data subject)
   This is already implemented in the existing API version of the Consent BB, but not yet reflected in the description of the spec.
   Other potential extensions of the BBs scope to consider while planning while considering the next release could be:

   1. implicit or legitimate consent could be considered for future use cases and ultimately for the specification (there are scenarios where implicit consent may require a verifiable transaction; there are also scenarios where tracking implicit consent in itself would constitute tracking, making this a complex field)

   2. to consider Consent BB to record and verify any informed approval by an Individual of an action by another person/entity (effectively to use it as a sort of “notary service”)

2. Consent delegation: a situation while an individual is authorizing actively or this is assumed implicitly (e.g. parent-child relationship or similar) that another individual to consent on their behalf.

The following use cases are left out of scope for the version 2.0 of Consent BB. These may be considered as potential future enhancements.

1. Non-reusable/single-action consent given in physical settings.

2. “Multi-Consent” is when consent can be given by more than one person or when consent is required to be given by more than one person. An example is given by the registration of a child whose consent is actually given by a parent or both in certain use http://cases.In the current version of the specification, muti-consent can be implemented at the business process level, with multiple calls to the Consent BB. One call per consent transaction. In the future, it is planned to extend the functionalities of the BB to provide support for multi-consent.

3. Relationships between multiple Agreements will allow for a single transaction to capture an individual’s signature on multiple Agreements.

4. Consider individual rights (E.g. as per GDPR / Data Protection Act etc.), potentially amending Scenarios 4.x, API endpoints functionality and the capture of Consent Records.

   • The right to be informed

   • The right of access

   • The right to rectification

   • The right to erasure

   • The right to restrict processing

   • The right to data portability

   • The right to object

   • Rights about automated decision-making and profiling.

5. The elaborated lifecycle for Consent Agreement amendments: Data Policies and Consent Agreements may change over time. Such events are sensitive to existing Consent Records.

   • Notifications for any consent agreement changes; Individuals and Data Consuming and Data Providing Systems.

   • Notifications of Consent Record changes in bulk and separate: Data Consuming and Data Processing Systems.

   • All lifecycle events of Consent Agreements and Consent Records are mapped as Audit Event Types, and the external auditing system is notified.

6. Roles and scopes for IAM (Identity Management) and RBAC to be used within consent BB

7. We need to enable audit logging capabilities aligned with the overall GovStack goals. Issues to be addressed include audit log access control, the type of information captured in the audit log, and taking care of sensitive data or meaningful metadata.

8. Certain update use cases (e.g. modify consent agreement) might result in invalidating a previously acquired individual consent. This will be investigated for future releases.