Approaching Identity with the GovStack Building Block Approach

Authors: Mikael Linden (ID Lead), David Higgins (Community Lead), Ali González (Specifications Editor) and the Cross-Functional ID Infrastructure Working Group.

Identity is one of the GovStack’s foundational building blocks. From September to December 2025, the Cross-Functional ID Infrastructure Working Group, a super-group overseeing the topic of Identity and Trust in GovStack, developed the first iteration of our approach to managing digital identity by taking the first step and updating the family of identity-related building blocks:

• Identity BB went from version 1.1 to 2.0
• Wallet BB went from version 1.0 to 1.1
• Consent BB went from version 1.2 to 1.3
• eSignature went from version 1.0 to 1.1

By far, the biggest change went to Identity BB, but they all represent the first step of the GovStack initiative in providing a holistic approach to digital identities. This document is a first look at how the Working Group views the interaction between the blocks and some views on how we expect to keep developing during the year.

Identity means a collection of attributes describing an entity (currently a natural person). The GovStack Identity building blocks focus on foundational identity, which is the identity for the general population and provides credentials that serve as proof of identity for a wide variety of public and private sector transactions and services. Common types of foundational identity systems include civil registries, universal resident or national ID systems, and population registers. In contrast to foundational identity, countries may also have functional identity systems that serve only a particular sector or purpose, such as education, healthcare or voter identification.

One can think of an identity as a record in a register, which contains sufficient information for identifying an individual i.e. distinguishing them from others. In contrast, identity verification (also known as authentication) is the process of making sure a person coming face-to-face to a counter or logging in to a service online is the true holder of the record. The reliability of that process is known as identity assurance. 

The diagram below describes the Identity building block in a high level. It consists of six services in two categories:

• Identity management is a back-end service that is used for managing (creating, updating, deleting) and making queries on individuals’ identities without their active involvement. In GovStack, that is done by trusted partners who are separately authorised to call the Identity building block’s APIs for it.
• Identity presentation is a front-end service that users can use to present their foundational identity to those who rely on it (called relying parties).

Those six services are described below.

1. 1. Enrollment/update is an API that trusted partners can call to enroll a foundational identity for an individual or update the identity. Depending on the local practices, the clients of that API are supposed to be, for instance, immigration authorities or hospitals where births are given. It is assumed those partners have carefully designed processes for identity enrollment/updates as their integrity defines the quality of the foundational identities.
   2. Identity queries is an API that enables trusted parties to have read access to the foundational identity. It is assumed to be used by other government services who have legitimate access to foundational identity. This can, for instance, be used for fetching user’s details for an administrative process or for an application form in order to avoid asking those details directly from the user. User involvement or consent is not assumed to be necessary for an identity query.
   3. Event notifications are push-type of change notifications that trusted partners can subscribe to. A life event, such as a birth, reaching a legal age or death, can trigger an event notification to be sent to public or private partners that need that information for their services. Like identity queries, being able to subscribe to events requires a separate authorisation that depends on the local policy and practice.
   4. Upstream federation is an API that can be called by a trusted partner to link a user’s external identity to their foundational identity. External identity can be a functional identity, commercial identity or a foreign identity in another country. For instance, in eIDAS regulation (article 11a), the functionality is called cross-border identity matching and enables the user to use other member states’ eID for authentication. For upstream federation, attention needs to be paid to avoid identity assurance erosion during the linking process.
   5. Credential management API can be called for exporting user’s identity e.g. as a paper-based credential. It also covers issuing verifiable credentials, although the Wallet building block has later been published as a specification parallel to the identity building block. We may decide to deprecate this API later to foster the Wallet building block as the GovStack approach for verifiable credentials.
   6. Identity verification is the API for relying parties to verify the user’s identity and retrieving their foundational identity attributes. It uses a well-established OpenID Connect flow and enables the user to be informed about processing their personal data and, when appropriate, asking the user to consent to the release of data. The relying parties can be government services or, depending on the local practices, also private sector services. The relying parties and the classes of attributes (dubbed as claims in OpenID Connect) they request are supposed to be registered beforehand. Nevertheless, the registration as a relying party can be less stringent than registration as a trusted partner as the relying party has read access only to a limited set of attributes and there is always the user involved in the identity verification flow.

These six services can be implemented alone or together with other building blocks. For instance, the Information mediation building block can mediate the API calls for identity queries or event notifications. Due to the user-facing nature of the OpenID Connect flow, the user’s web browser needs to be involved directly in that flow. 

The Identity building block can be seen as a large registry containing many individuals’ foundational identities that can be exposed to relying parties as paper credentials or OpenID Connect claims. Signature and Wallet building blocks in the diagram below introduce alternative ways for identity presentation to relying parties. 

Digital wallets are an emerging technology where users typically have an app called a wallet in their smartphone and can retrieve signed attributes (dubbed as verifiable credentials) to it and present them to relying parties. The verifiable credentials can be issued by public or private entities. The foundational identity attributes are good candidates for verifiable credentials that the Identity building block could issue.

Wallets have drawn attention in different countries and sectors, such as Canada and Singapore. In the European Union, the amendment of the eIDAS regulation is currently pushing adoption of wallets. There are also initiatives to issue a mobile driving license to a wallet to demonstrate driving permissions but in many countries also to verify the identity on-line.

The GovStack Wallet building block was first published in autumn 2025 and relies on a recent OpenID for Verifiable Credentials specification. Unlike the Identity verification service of the Identity Building Block, a wallet is better fit for protecting user privacy on-line. In a carefully crafted wallet architecture, the issuer of a verifiable credential cannot learn where the wallet holder later decides to present their credentials. Presentation of a credential from a wallet to a relying party always requires an active decision by the user. A wallet can also hold credentials issued by several actors, including public and private.

Using identity building block’s identity verification service or presenting credentials from a wallet are typically done in the beginning of an online session, and the authenticated identity is available until the session ends or expires. In contrast, an eSignature is a different kind of presentation of identity that is coupled to a transaction the user carries out. An eSignature is independent of a session but is attached to a document that exists even after the session has ended. It is typically used for expressing a user’s approval for a transaction, and some jurisdictions even have laws defining that an eSignature of a sufficient quality has a legal effect similar to a wet signature. Therefore, a typical use scenario for an  eSignature is signing a contract with a relying party.

eSignature building block defines eSignature a service that relying parties can call to initiate a process where the user views a document and creates a digital signature to it. The user authenticates against the Identity building block and, if necessary, the eSignature service creates a keypair and signing certificate for the user and uses the private key to sign the document. The document can be in different formats, such as PDF, Word, Excel, JSON, XML or image. 

In the GovStack context, consent is understood as a voluntary declaration by an individual to approve the processing of their personal data. The exact definition depends on the jurisdiction. For example, in the European Union, the General data protection regulation (GDPR) defines consent as a freely given, specific, informed and unambiguous indication of the data subject’s wishes. The data controller has an obligation to demonstrate a proper consent has been given while the user has the right to withdraw their consent any time. The Consent building block introduces a separately managed service and API for data controllers and data subjects to use.

The use of the Consent building block will vary depending on the jurisdiction and application.  For example, in the European Union, consent is one of the 6 legal grounds for personal data processing as defined in GDPR (article 6.1), but GDPR discourages the use of consent in public administration (see recital 43 and European data protection board’s guidelines 5/2020). However, in other jurisdictions, such as India, the Digital Personal Data Protection Act (DPDPA)2023 says data exchange requires explicit, free, informed and unconditional consent, which must be given through a clear affirmative action. Consent must be obtained before processing, be purpose-specific, and allow users to withdraw consent easily.  The GovStack Consent building block can provide these functions. Hence the Consent building block can be seen to provide key functions, however, it is important for an implementer to ensure its applicability to the specific jurisdiction and use scenario.

The GovStack Cross Functional ID Working Group identified a number of potential areas of focus for the specifications moving forwards, consolidating these around three main areas:

Out of all of these we have set a priority as follows for starting discussion in this season (the final specification update for some may take multiple seasons based on complexity), although we continue to refine this depending on skills and input that comes into the community:

If you are interested in joining the work we are doing please reach out to Mikael, Ali, Yuliia or David to get engaged.