Version of by Ain Aaviksoo
As per
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
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: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)
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”)
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 this the version 12.0 of Consent BB. These may be considered as potential future enhancements.
Non-reusable/single-action consent given in physical settings.
Consent to use data other than personal information on behalf of an organisation. For example, an organisation authorising an individual to consent to expose some organisation’s data is seen out of the scope of the consent building block.
Consent delegation: While being part of the Consent BB, this will be taken up in the future. For e.g. an individual is authorising another individual to consent on their behalf.
“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.
Relationships between multiple Agreements will allow for a single transaction to capture an individual’s signature on multiple Agreements.
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.
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.
Roles and scopes for IAM (Identity Management) and RBAC to be used within consent BB
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.
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.Implicit or legitimate consent could be considered for future use cases and ultimately for the specification. There are scenarios where an 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.