First developed by: Ain Aaviksoo (Estonian Telecommunications Union), Benjamin Balder Bach (fmly Danish Tax & Revenue), Lal Chandran (MyData Global, iGrant.io), and Philippe Page (MyData Global, Human Colossus Foundation) With advisors: Dr. P. S. Ramkumar (ITU), Max Carlson (GovStack), and Sasikumar Ganesan (MOSIP)

Authors to this version: Mikael Linden (Gofore), and David Higgins (Brook IT Consulting)

Contributors: Charity Chirowamhangu, Antony Muriithi, Daniel Abadie, Norbert Nahayo, Rounak Nayak, Eric Ramirez, and Mary Metias

Reviewers: Yuliia Kravchenko (GovStack), and Smita Selot

Editor: Ali González-García

Version 1

v1.3.0

Version Date: December 2025

Authors: Mikael Linden and David Higgins and Ali González-García

1. Overview

This release of the Consent Building Block was developed between September and December, 2025 by the Cross-Functional ID Infrastructure Working Group, a super-group of all the key Identity and Trust-related Building Blocks in GovStack (e-signature, identity, Wallet, Consent).

Release 1.3 of Consent is the result of a review of all 4 specifications to ensure their are aligned and consistent to a single Identity Universe.

2. Changes

Section 1 - Version History

• Removal of unpublished versions. See

• Inclusion of release notes and removal of link to confluence change log that was not maintained

• Update of Authors

Section 2 - Description

• Addition of explanation on GDPR and Public Authorities

• Use of term Data Controller was added

• The updating of ISO/TS 17975:2015 to ISO/TS 17975:2022 definition of concern on the body (missed on version 1.1.0, where this update was introduced) gave change to a more contextualized definition of concern for which amendments were introduced.

Section 3 Terminology

• Updated to indicate common terminology

• Removal of the entry for Legal Entity, as it overlaps to the entries Data Provider, Consumer, and Processing Auditor.

Section 4 Key Digital Functionalities

• Use of term Data Controller was added

• Updated table structure for Use-cases so that now Operation and Functionality are visible

• Corrected the Use-cases links to use the version corresponding to the current specification (it was previously linked to the ones on version 1.0). Whenever the use-case operation was not available, removed the link and noted the unavailability so readers are not directed to non-existent content.

Section 6 Functional Requirements

• Ensured use of Required/Recommended in requirements in line with .

Use-cases

• Added a "For consideration of Future Log" notice to UC-C-PIC-A-003, UC-C-PIC-A-004 and UC-C-PIC-A-005 as they were empty.

• Removed the content of UC-C-PIC-I-004: Consent agreement change notification as it was an exact copy of UC-C-PIC-I-003: Withdraw or update existing consent and placed a "For consideration of Future Log" notice

3. Editorial note

Author: Ali González-García

Release 1.3 reworks the previous versioning system from to as a strategic decision that follows , as well as a revamped Version History section that includes key version information, such as publication dates and richer comments.

It removes from the version history page all unpublished versions, because they denote internal GovStack revision and processes and cannot be consulted as standalone versions themselves. On future versions, this metadata will be published as part of the documentation of the GovStack project that belongs to the specification publishing which will include richer information such as working group composition, meetings and key decision information.

The current release notes section is also an addition to this batch. The purpose is to provide implementers with a quick and clear reference of changes and additions between versions, among with context as to why the GovStack community has decided to publish the release.

The Terminology section now uses Heading tags for definitions instead of a table. This adds semanticity to each definition and makes it linkable, as each definition is provided with an HTML id attribute.

We hope the provided changes make for a better legibility experience of this specification.

v1.2 (known as 23Q4.1)

1. Overview

Version 1.2 represents a simplification and standardization effort, focusing on:

• Consistent camelCase naming throughout APIs

• Reduced complexity in data models

• Streamlined API surface area

2. Changes

2.1 Field Name Updates (snake_case to camelCase):

The API specifications changed field naming conventions from snake_case to camelCase:

2.2 API Response Structure Changes

Version 1.1: API responses returned objects directly wrapped in response objects

Version 1.2: Some API responses changed to return arrays instead

2.3 Data Model Simplifications

Removed:

• Purpose object structure (which had id, name, description, serialized_hash)

• Lifecycle object references in Agreement structures

Simplified:

• Agreement/ConsentRecord structures are less deeply nested

• Removed circular reference handling in some response examples

2.4 API Endpoint Changes

Removed:

• Data Agreement related endpoints (/config/data-agreement/, /service/data-agreement/)

• Consent Record detailed endpoints

• Webhook configuration endpoints (/config/webhook/

Retained core endpoints:

• Policy management (/config/policy/)

• Individual management (/service/individual/)

• Basic audit endpoints (/audit/consentrecord/)

v1.1 (known as 23Q4)

1. Changes

Section 1. Version History

• Removed v0.1 and v0.5 from version history and indicates potential future releases

Section 2. Description

Updated ISO Standards Referenced

Building Block Interactions Table

Removed for data storage.

Section 6. Functional Requirements Wording

Added: "It shall be possible to capture and sign all changes to Consent Agreements, Consent Policies and Consent Records in tamper-proof Revisions"

Removed:

From Design Components section

"RESTful APIs: All APIs are exposed as RESTful APIs. These are categorised into Organisation APIs, Individual APIs, and Auditing APIs."

Section 7. Data Structures

Added section:

7.3 Example data and mock application

• References "fixtures.json" file

• Mentions mock application availability

• Provides GitHub link to mock application

9. Internal Workflows Section

Title Changes:

"Consenting at initial registration (Pre-registration) using a centralised ID system" to "Universal workflow: Recording consent at initial registration (pre-registration)"

Key Removal: Version 1.0 specifies "using a centralised ID system" to clarify the ID approach.

Workflow Names:

"Consenting after the registration (Post-registration)" to "Universal workflow: Recording consent after the registration (post-registration)"

v1.0

First Publication

10.1 Key Decision Log

.

We recognise there are common terms across all ID related Building Blocks (Identity, E-Signature, Consent, Wallet). We define these .

In addition the following terms are specific to the Consent Building Block.

Configuration

Technical implementation of all the content and process conditions as defined by the Data Policy for Consent Agreement creation, reading, updating and deletion, as well as for providing all necessary actors with the required operations

Consent Agreement

The agreement to be signed by the and the Data Controller as prescribed by , based on which the Data Providing System may transmit the data to the Data Consuming System for the purposes described in the Consent Agreement.

Consent Record

The Consent Record created when an signs a . It represents a signed consent agreement.

Consent Reference

A unique identifier used to locate and verify the validity of the .

Data Providers

A legal entity that stores and provides access to an s data, which requires the Individual's consent for processing (outside of its primary purpose/location).

Data Consumers

A legal entity that requires the 's data from the according to the consent of the Individual.

Data Disclosure Agreements (DDAs)

A Data Disclosure Agreement (DDA) exists between two organisations where one organisation acts as a and the other as a . The DDA captures how data is shared between the two organisations and what role and obligation each party has.

Data Policy

Is a formal description of the purpose, nature and extent of consent-based processing, covering the configuration needs by Data Providing System and Data Consuming System and the conditions defined by law.

Data Processing Auditor

Is an legal entity (a person or an organisation) verifying the legitimacy of processing by Data Controllers and Data Processors based on the Data Policies and performed tasks. The entity is not to be confused with a data policy auditor that is independent of the actors involved in the operations of consent management and can engage directly with the Consent BB service operator.

Delegate

The person giving consent (signing ); on behalf of the ,

Individual

Is a person about whom the is stored in an information system (a.k.a. “Data Subject”) and who agrees or not with the use of this data outside of its primary purpose/location

Legal Entity

Personal Data

Is any information that

(a) can be used to identify the to whom such information relates, or

(b) is or might be directly or indirectly linked to the Individual ()

Regulations

Are broadly defined as rules followed by any system: could be laws, bylaws, ​norms or architectures that​ regulate a given system. The term and definition is inspired by .

7.1 Resource Model

The resource model shows the relationship between data objects that are used by this Building Block. Data objects are ultimately modelled as OpenAPI schemas, however as the relational model isn’t easy to understand from OpenAPI specification, we start by presenting two high-level Resource Models.

7.1.1 Simplified Resource Model

When an individual gives consent, it is implied that the Organisation from one side and the Individual from the other side digitally sign a Consent Agreement and a respective Consent Record is created. The alternative scenario may be that signing takes place offline on a paper, but in this case, for the Consent Building Block to function properly, it is the responsibility of the Organisation to digitise (e.g. scan) the signed document and create digitally signed artefact to represent the Consent Record.

This Consent Record is a digital instance referencing the Agreement which is consented to or subsequently has consent withdrawn from.

7.1.2 Elaborated Resource Model

This model expands the relationships between resources.

Revisions are maintained for Consent Records + Agreements and Data Policies, together with cryptographic signatures. This means that all changes are captured for auditability.

For a configured Agreement, data elements requiring consent are individually specified as Agreement Data. Agreement Data is not directly relatable to processes and internals of an external system. This architectural choice gives the consent model flexibility and greatly simplifies the architecture and consent lifecycle, but it does not contradict any additional features, allowing for relations to external systems.

• Individual changes Consent Record.

• Individual withdraws/revokes Consent Agreement.

• Consent Record expires.

7.2 Data models

This specification is seen as a minimum requirement, all further implementations may add more structure but should not compromise the minimal integrity laid out. All property types are generic, and a concrete implementation may add further specificity to these models.

The OpenAPI definition file is maintained in YAML format, and OpenAPI schemas may be interactively explored in the next section.

7.3 Example data and mock application

As part of this specification, a set of fully structured example data are provided as a fixtures.json file. These fixtures are maintained and released together with the specification's mock application.

The mock application is an operational Docker Compose environment that satisfies all verification tests.

5.1 Requirements

The cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the . Any implementation MUST adhere to all requirements from .

8 Service APIs

This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.

The GovStack non-functional requirements document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.

The tests for the Consent Building Block can be found in .

8.1 API specification

The following is an automated rendition of the .

You can see the latest unreleased version of the OpenAPI specification in .

8.1.1 Config APIs

8.1.2 Service APIs

8.1.3 Audit APIs

The Consent Building Block enables services for individuals to approve the use of their Personal Data by defining the principles, functions, and architecture of an information system. For organisations that process Personal Data​,​ it provides the ability to know the ​individual's will and legitimately process such Personal Data. The Consent Building Block is a process-oriented GovStack Building Block facilitating auditable bilateral agreements within a multi-agent environment that integrates with most other Building Blocks.

This specification has used several available and recognised open standards below and legal frameworks (such as the ) for laying the groundwork for its approach to consent.

• : Consent Specification

The functional requirements section lists the technical capabilities that this Building Block should have. These requirements should be sufficient to deliver all functionality that is listed in the Key Digital Functionalities section. These functional requirements do not define specific APIs, they provide a list of information about functionality that must be implemented within the Building Block. These requirements should be defined by subject-matter experts and don’t have to be highly technical in this section.

6.1 Administrator User Functionalities

Agreement Configuration Requirements.

Table of Contents

This section lists workflows that this Building Block must support. Other workflows may be implemented in addition to those listed.

9.1 About universal workflows

The Workflow Building Block triggers the need for consent as part of the general business flow. The assumption is that a consenting process never exists outside of a purposeful comprehensive business process. Hence, it is important to define and control the data processing activities as part of a holistic data service.

The Consent Building Block enables organisations to enforce data policies that require signed consent by individuals for the use of their personal data. Its key purpose is to allow individuals to view consent agreements and sign or withdraw their consent on what personal data is used and accessible to organisations. It also clarifies the data policy applied, such as the purpose, retention period, jurisdiction, third-party data sharing, etc.

The Consent Building Block implements the key functionalities described in the consent management lifecycle. It includes the ability to configure consent agreements by an organisation admin, present consent requests towards individuals, capture consents, enable queries if consent exists, or not, and enable independent audit of consents.

The functionalities are derived from the consent agreement lifecycle and categorised according to the actors described on chapter 2. While the consenting workflows are implicitly considered the centrepiece of the Consent Building Block, it is important to realise that the integrity of consent management can only be achieved if robust configuration before and auditing after the consent agreement signing and consent record verification activities are in place. Hence, the functionalities are described following the logical sequence of the consent agreement lifecycle and they are all equally important components of the Consent Building Block.

The consent process (creating and signing consent agreements and consent records) is initially managed in the application provided by the data controller. Since it can be either a organisation or a organisation, the Consent Building Block allows both to be able to verify their conformance with the underlying data policy, both organisations must be able to access and use the application.

While the actors generally fall in line with the categories of the functionalities, it is important to realise that “auditing” functions in the narrow sense, verifying if data processing is being (or has been) processed according to the data policy requiring a consent, is relevant to various entities involved in the data processing. For this reason, the generic “verification” activity may be executed as part of various workflows satisfying the needs of different actors.

Following is the first core set of key functionalities of the Consent Building Block.

4.1 Administrator User Functionalities

The Administrator (Data Provider or Data Consumer Admin) configures the Consent Building Block on behalf of the organisation. For simplicity, it is foreseen that one organisation involved in the data processing transaction (that is either Data Provider or Data Consumer) takes the responsibility for the configuration of the Data Policy and respective Consent Agreements(s), and so that the organisation’s Administrator maintains the required configurations.

The actions that the Administrator is expected to perform via Consent Building Block are:

• Configuring Data Policies, requesting and signing Consent Agreements with Individuals;

• Viewing (reading, exporting) the Consent Agreements and relevant reports;

• Event-driven (opt-in or opt-out) subscription to (notifications of) changes in Consent Agreements;

The table below summarises how these operations may look like as functionalities available to an organisation's Administrator. Organisations can be or , i.e. the organisations legally delegated the responsibility for collecting consent for the systems handling Personal Data processing. Operations on Use-case in the Context of Post-partum and Infant care is provided as a more extended description when available.

4.2 Individual User Functionalities

The capabilities for individuals that Consent Building Block supports are:

• viewing and understanding Data Policies applying to their Personal Data processing;

• agreeing and disagreeing with and toggling between the conditions of Personal Data use as described in the Consent Agreement;

• obtaining copies of their Consent Agreement(s);

The scope for the current version of Consent Building Block assumes that the Individual is acting for themselves. Ultimately the Consent Building Block will include in the Consenting Process the capacity to sign a Consent Agreement in the name of another individual - to act as the Delegate, which is used as the criterion for technical implementation. However, the Delegate and the Individual relationship is expected to be maintained outside of the Consent Manager, which assumes that the person signing the Consent Agreement (i.e. Consenter) has been authorised to do so.

The table below summarises how these operations may look like as functionalities available to an . Actions on Use-case in the Context of Post-partum and Infant care is provided as a more extended description when available.

4.3 Data Processing Auditor User Functionalities

Important note: In the Consent Building Block, we define the Data Processing Auditor's role (see 1.3 Terminology and 1.5.3 Actor definition) as an organisation's auditor implementing the Consent Building Block. The auditor role will most probably be akin to a Data Protection Officer (DPO), possibly from an external third-party organisation and involve activities outside of the Consent Building Block.

To avoid ambiguity, we use the precise term Data Processing Auditor to stress the specificity of tasks to be performed by and for the Consent Building Block; all other actions not within the Consent Building Block's scope are considered as an external prerequisite and as a “black box” activity. With respect to audit, this role is distinguished from the data policy auditor. The Data Processing Auditor relies on an audit universe defined by the control and risk management of the specific project and context (i.e. outside the Consent Building Block). “Who needs to consent to what” is the outcome of a DPIA (Data Protection Impact Analysis), ensuring that the data policies are compliant with the relevant data protection regulations for the project.

The main actions a Data Processing Auditor (or Data Protection Officer, DPO) is expected to perform via Consent Building Block are:

• Auditing tracking the consents (opt-in/opt-out);

• Auditing tracking Data Policy changes and configuration conformance with it;

• Viewing (reading, exporting) the Consent Agreements and relevant reports in a verifiable form.

For the implementation of a specific use case, it is important to distinguish the Data Processing Auditor, an actor described here, from a data policy auditor, an actor of the risk organisation. It is expected that the two roles are coordinated in the risk management process. Within the Consent Building Block, the Data Processing Auditor performs the tasks that will allow a data policy auditor to confirm that the implemented system complies with existing regulations demanding consent.The table below summarises the key use cases identified for the Data Processing Auditor.

Also to consider: “READ CONSENT STATUS” use-case is also used by any workflow (and Actor) that requires verification of the consent status (for example, before executing the data transfer from Data Providing System to the Data Consuming System).

Scenarios: Consent and Data Access

As described above under , there may be an unlimited number of business processes that require consent. The following scenarios are but a few examples illuminating how appropriate access to data can and should be handled when processing or consuming data with the support of Consent Building Block functionalities.

Table of Contents

Table of Contents