Status: Draft for discussion
Date: 2026-05-05
This proposal is the results of discussions that have arisen on Cross-Functional ID Building Block while reviewing the Wallet specification, Payments BB while separating Payment Orchestration from Payment Gateway capabilities, Registries and Registration WG when discussing how these 2 BB communicate together. These implementations pointed to a missing piece in the GovStack Architecture that so far we have named a "framework". This is a proposal for discussion to evaluate if it makes sense for inclusion.
1. Problem Statement
The GovStack Architecture defines two well-established concepts:
- Building Blocks: autonomous, generic, interoperable software components that each provide a reusable digital service capability.
- Digital Service Systems: combinations of Building Blocks assembled to deliver a specific government service.
There is, however, a conceptual gap between them. Some Building Blocks only achieve their intended purpose when operating together with other Building Blocks, and when the organizations that operate them have agreed on shared rules, semantic standards, and governance. A digital wallet, for example, is not useful in isolation: it requires credential issuers, credential verifiers, and an identity provider. Each of those may be a separate, autonomous Building Block, but their combined usefulness depends on a shared set of rules that none of them, individually, defines.
The Generic Interoperability Framework described in Chapter 4 establishes the four cross-cutting layers —organizational, semantic, technical, and infrastructure— that enable systems to work together. What is missing is a concept for how those four layers are instantiated within a specific domain to coordinate multiple Building Blocks into a coherent, government-wide capability.
This proposal introduces Domain Frameworks as that missing concept.
2. Definition: What is a Domain Framework?
A Domain Framework is a domain-scoped set of governance rules, semantic standards, role definitions, and reference compositions that specifies how multiple Building Blocks and their operators must work together to deliver a coherent whole-of-government capability in that domain.
A Domain Framework is not software. It does not replace or supersede Building Blocks. It is the agreement layer that sits above individual Building Blocks and below the Digital Service System. It defines:
- Which Building Blocks are relevant to the domain.
- What roles those Building Blocks play (e.g., issuer, verifier, holder, registry, payment initiator).
- What semantic standards apply to data exchanged between them.
- What organizational and legal agreements must exist between operators.
- What infrastructure prerequisites are required.
- What the minimum viable composition looks like for a functional service.
In short: a Building Block defines what a component can do; a Domain Framework defines how components must work together for a domain to function.
3. How Frameworks Fit in the Architecture
The table below positions Domain Frameworks against the existing architectural concepts:
| Concept |
Nature |
Scope |
Autonomous? |
Contains |
| Building Block |
Software component |
Single capability (e.g., identity, payment) |
Yes |
APIs, data models, functional requirements |
| Domain Framework |
Governance + reference architecture |
A domain (e.g., identity, payments) |
No — requires multi-party coordination |
Roles, semantic standards, BB compositions, governance rules |
| Digital Service System |
Implementation |
A specific service (e.g., birth registration) |
N/A |
Building Blocks, service application, repositories |
| Generic Interoperability Framework |
Cross-cutting governance |
All domains |
N/A |
Organizational, semantic, technical, infrastructure layers |
The relationship is hierarchical but not exclusive:
Generic Interoperability Framework
│
├── Domain Framework A (e.g. Digital Identity)
│ ├── defines roles: identity provider, attribute authority, relying party
│ ├── references: Identity BB, e-Signature BB, Consent BB
│ └── governs: semantic standards for person attributes, trust anchors
│
├── Domain Framework B (e.g. Digital Credentials)
│ ├── defines roles: credential issuer, credential holder (wallet), verifier
│ ├── references: Wallet BB, Identity BB, Registry BB
│ └── governs: credential schemas, revocation protocols, trust registries
│
└── ...
Digital Service Systems implement one or more Domain Frameworks
using specific Building Block deployments.
3.1 Building Block Autonomy and Systemicity
One of the concerns this proposal answers is that Building Blocks are defined as autonomous. In section 4.5.1 Criteria for Building Blocks they are defined as such so that they can be deployed independently, provide a standalone service, and be tested against its own specification without requiring other Building Blocks to be present. While autonomy is a deliberate design choice to ensure replaceability and reusage, at the same time, many Building Blocks only deliver their intended value when operating within a system of other Building Blocks.
It is the objective of this proposal to clarify how that distinction does not contradict, but rather harmonizes two levels of description:
- A Building Block specification describes what a component must do as a self-contained system.
- A Domain Framework describes the systemic context in a particular domain. The roles, actors, and contracts for how that component operates alongside others. Two examples illustrate why keeping these levels separate matters in practice:
3.1.1 Digital Credentials Framework
A Wallet Building Block specification can and should scope itself to the wallet function alone: storing, presenting, and managing credentials held by the holder. However, a wallet is not functionally useful without credential issuers and credential verifiers.
Scoping Wallet BB to include Issuers and Verifiers requires a compliance applicant (i.e. a software vendor) to implement a full ecosystem to prove conformance of a single component. The Digital Credentials Framework resolves this by defining the systemic context separately. The Wallet BB is tested against a reference-conformant credential issuer and a reference-conformant credential verifier, actors whose behavior is defined by the Framework, not by the Wallet BB specification itself.
Each component remains individually testable; the Framework defines the contracts between them. While there is currently no Credential Issuer Building Block or Credential Verifier Building Block, it becomes much easier and iterable to define these are actors within a Digital Credentials Framework that must interact with a Wallet under certain contract requirements, so that compliance testing for Wallet BB can be clearly defined. After this definition of contracts is clear, it becomes easier for the Working Group to define, should they decide to, such Building Blocks.
3.1.2 Payments orchestration
A government typically operates multiple payment gateways arising from bilateral agreements that different ministries have established over time with financial institutions. A Payments Building Block may handle a single payment channel well, but a Payments Framework is needed to define how those gateways are orchestrated, how a payment instruction is routed to the correct gateway, and how results are reconciled across systems. A
Additionally, government payment flows — particularly G2B (government to business) and B2G (business to government) — depend on authoritative identity records for both natural and legal persons, and interact with government registries to validate beneficiary or payer status. The Framework establishes which Building Blocks are involved in these flows, what role each plays, and what contracts govern their interactions with external payment infrastructure.
In both cases, Building Block autonomy is preserved at the specification level: each BB is specified, implemented, and tested as a standalone component. Systemicity — the property of operating correctly within a larger, coordinated system — is addressed at the Framework level. The Framework also defines the minimum set of conformant actors required to validate that a Building Block implementation works correctly within its intended system context, providing the basis for end-to-end compliance testing that no individual BB specification can provide on its own.
4. Framework Layers
Each Domain Framework applies the four interoperability layers from the Generic Interoperability Framework to its specific domain:
4.1 Organizational Layer
Defines the roles, responsibilities, and institutional relationships within the domain. Who may operate as an issuer? Who governs the trust registry? What legal basis authorizes data sharing between participants?
4.2 Semantic Layer
Defines the shared data models, vocabularies, and schemas used within the domain. This ensures that "identity attribute," "credential," or "payment instruction" means the same thing to every Building Block and every organization operating within the framework.
4.3 Technical Layer
Defines which protocols, API contracts, and integration patterns govern interactions between participating Building Blocks. This builds on the cross-functional interoperability achieved by GovStack CFR and BB specifications, but narrows the scope to the domain.
4.4 Infrastructure Layer
Defines the shared infrastructure prerequisites: trust anchors, PKI hierarchies, registries, directories, or ledgers that the domain requires to operate. For example, a Digital Credentials Framework requires a publicly accessible credential schema registry and a revocation registry.
5. Relationship to Whole-of-Government Interoperability
In the maturity model described in section 4.1, Domain Frameworks are the primary instrument for reaching State 3: Whole-of-Government Interoperability. A government that has implemented GovStack Building Blocks and achieved Cross-Functional Interoperability (State 2) still has systems that speak the same technical language but may carry different semantic meaning and operate under different institutional rules. A Domain Framework resolves this by establishing the semantic and organizational layer for a specific domain.
| Interoperability State |
Addressed By |
| State 1: Protocol Interoperability |
GovStack CFR (cross-functional requirements) |
| State 2: Cross-Functional Interoperability |
GovStack BB Specifications |
| State 3: Whole-of-Government Interoperability |
Domain Frameworks + PAERA governance guidance |
6. Proposed Possible Domain Frameworks
The following is a proposed initial set of Domain Frameworks. This list is not meant to be prescriptive and the ultimate decision to create a framework rests on both Working Groups and the GovStack Initiative. However it is presented as an initial list for open discussion.
6.1 Digital Identity Framework
Governs how a person's digital identity is established, asserted, and trusted across government services.
Core roles: Identity Provider, Attribute Authority, Relying Party
Key Building Blocks: Identity BB, e-Signature BB, Consent BB
Key governance concerns: identity assurance levels (IAL), authentication assurance levels (AAL), federation of identity providers, attribute release policies
Reference standards: eIDAS, NIST SP 800-63, W3C DID
6.2 Digital Credentials Framework
Governs how verifiable credentials are issued, held, presented, and verified — enabling citizens to carry portable, tamper-evident claims (qualifications, entitlements, licenses) that any relying party can verify.
Core roles: Credential Issuer, Credential Holder (Wallet), Credential Verifier, Trust Registry Operator
Key Building Blocks: Wallet BB, Identity BB, Registry BB, Consent BB
Key governance concerns: credential schemas and versioning, revocation mechanisms, holder binding, selective disclosure, trust registry governance
Reference standards: W3C Verifiable Credentials, OpenID4VCI, OpenID4VP, ISO 18013-5 (mDL)
6.3 Trust Framework
Governs how trust relationships between organizations and systems are established, maintained, and revoked — the precondition for any cross-institutional data exchange.
Core roles: Trust Anchor, Trust List Operator, Certificate Authority, Auditor
Key Building Blocks: Identity BB, Information Mediator BB, e-Signature BB
Key governance concerns: PKI hierarchy, trust list publication, certificate lifecycle, audit and compliance requirements, cross-border mutual recognition
Reference standards: ETSI TS 119 series, X.509, eIDAS Trust Lists
6.4 Payments Framework
Governs how digital payment instructions are initiated, authorized, routed, and settled across government services — covering both citizen-to-government (G2C) and government-to-person (G2P) flows.
Core roles: Payment Initiator, Payment Service Provider, Clearing House, Beneficiary Registry, Reconciliation Agent
Key Building Blocks: Payment BB, Identity BB, Consent BB, Registry BB
Key governance concerns: payment scheme rules, beneficiary deduplication, fraud prevention, reconciliation and audit trails, financial inclusion requirements
Reference standards: ISO 20022, GSMA Mobile Money API, G20 cross-border payments principles
6.5 Data Sharing Framework
Governs how personal and non-personal government data is shared between institutions — determining who may request data, under what conditions, with what consent mechanisms, and with what audit trail.
Core roles: Data Provider, Data Consumer, Consent Manager, Audit Log Keeper
Key Building Blocks: Information Mediator BB, Consent BB, Registry BB, Identity BB
Key governance concerns: data categories and classification, purpose limitation, data minimization, cross-border data flows, audit and accountability
Reference standards: GDPR / national data protection law, OECD AI Principles (for automated decisions on shared data)
6.6 Person Registries Framework
Governs how government registries pertaining to natural persons are structured, maintained, and made to interoperate — spanning civil registration, population management, health, social protection, education, criminal justice, travel documents, and any other domain in which the state holds authoritative records about a person.
While some registries are hinted at in Annex 3 of PAERA, this framework articulates the contracts and workflows that allow distinct, domain-owned registries to exchange and reconcile data, construct composite citizen files (sometimes called "360° citizen views"), support functional identity derivation where a foundational identity document does not yet exist, and facilitate registration processes that span multiple registries simultaneously (e.g., a birth event that triggers updates in the civil registry, health registry, and population register in a coordinated workflow).
This framework may operate independently of a Digital Identity Framework — registries often predate digital identity infrastructure — but it defines the interoperability surface through which a Digital Identity Framework can anchor to authoritative civil records once one is in place.
Core roles: Registry Authority (per domain), Civil Registrar, Population Register Operator, Data Reconciliation Agent, Citizen File Aggregator, Registration Workflow Orchestrator
Key Building Blocks: Registry BB, Identity BB, Messaging BB, Information Mediator BB, Consent BB, Workflow BB
Key governance concerns:
- Registry ownership and authority: each registry is owned by a specific institution; the framework defines data-sharing contracts between them without transferring ownership
- Unique person identifier strategy: whether a single national ID is used or functional identifiers are derived per domain
- Life-event notification workflows: birth, death, marriage, divorce, address change, naturalization — which registries must be notified and within what timeframes
- Deduplication and record linkage across registries with heterogeneous identifiers
- Rectification and dispute resolution for conflicting records across registries
- Access controls and purpose limitation: health data, criminal records, and social protection data carry distinct legal access regimes
- Offline and low-connectivity registration processes for remote populations
Covered registry domains (non-exhaustive): civil registration (birth, death, marriage), population register, health records, social protection beneficiary registries, education and qualification records, criminal and judicial records, passport and travel document records, disability and social care registers
Reference standards: UN Principles and Recommendations for CRVS, OpenHIE Community Health Information Framework, GovStack Registry BB specification
6.7 Legal Entities Framework
As in the Persons Registry Framework, some juridical entities are hinted at in Annex 3 of PAERA. A Legal Entities Framework Governs how legal entities, companies, cooperatives, non-governmental organizations, associations, sole traders, and other recognized private actors, are registered, identified, regulated, and represented in government systems throughout their lifecycle.
The framework covers entity registration and the authoritative registries that record existence and legal status, as well as the downstream systems that consume those records: business licensing, tax administration, regulatory compliance, procurement eligibility, and dissolution or insolvency. It defines the interoperability contracts that allow a single registration event to propagate correctly to the relevant registries and regulatory bodies.
Core roles: Business Registration Authority, Licensing Body, Tax Authority, Regulatory Agency, Entity Registry Operator, Authorized Representative (director, beneficial owner, agent)
Key Building Blocks: Registry BB, Identity BB (for directors/beneficial owners), Information Mediator BB, Messaging BB, Payment BB (for fees and taxes), Consent BB
Key governance concerns:
- Authoritative business identifier strategy (e.g., national business registration number, LEI for cross-border use)
- Beneficial ownership transparency and public disclosure requirements
- Lifecycle event workflows: incorporation, name change, address change, merger, dissolution, insolvency — which downstream registries and agencies must be notified
- Licensing and permit interoperability: a single business may require permits from multiple agencies; the framework defines how registration status feeds eligibility checks
- Cross-border recognition and equivalence of legal entity types
- Registry access tiers: some registry data is public, some restricted to authorized agencies, some protected (e.g., personal data of directors)
Covered entity types (non-exhaustive): corporations, limited liability companies, partnerships, cooperatives, NGOs and foundations, sole traders, professional associations, public enterprises
Reference standards: GLEIF Legal Entity Identifier (LEI), FATF Recommendations on beneficial ownership, W3C Verifiable Credentials (for machine-readable certificates of incorporation), OpenCorporates data model
6.8 Land and Property Framework
Governs how land parcels, property rights, spatial boundaries, and the transactions and obligations that attach to land are recorded, managed, and made interoperable across the government systems that depend on them.
Land data underpins a wide range of government functions — property taxation, urban planning, construction permitting, environmental management, disaster risk reduction, agricultural land management, and infrastructure investment. Because these functions are typically administered by different agencies with different mandates, the framework defines the interoperability contracts that link the authoritative cadastre and land registry to the consuming systems, and specifies the workflows for events (sale, subdivision, inheritance, mortgage, expropriation, rezoning) that trigger coordinated updates across multiple systems.
Core roles: Cadastral Authority, Land Registry Operator, Tax Assessor, Urban Planning Authority, Construction Permit Issuer, Property Rights Holder (individual, company, state), Surveyor, Notary or Conveyancer
Key Building Blocks: Registry BB, Identity BB (for linking owners to person/entity records), Information Mediator BB, Messaging BB, Payment BB (for transfer taxes and fees), Consent BB
Key governance concerns:
- Separation between the cadastre (spatial, geometric record) and the land registry (legal rights record), and the synchronization contract between them
- Unique parcel identifier strategy (cadastral reference number) and its stability across administrative boundary changes
- Ownership and rights event workflows: transfer of title, subdivision, consolidation, easement creation, mortgage registration, expropriation — which systems must be updated and in what sequence
- Linkage to the Business and Private Entities Framework when the rights holder is a legal entity, and to the Person Registries Framework when the holder is a natural person
- Valuation and taxation interoperability: how assessed values flow to tax systems and how tax status flows back to transfer eligibility
- Construction and planning permit lifecycle: from application through approval, inspection, and certificate of occupancy
- Risk and hazard data integration: flood zones, seismic risk, land-use restrictions — how these spatial layers are maintained and consumed by permitting and insurance systems
- Cross-border and informal tenure: recognition of customary land rights, participatory mapping, and adjudication processes in jurisdictions with incomplete formal registration
Covered sub-domains (non-exhaustive): cadastre and land registry, property valuation and taxation, urban planning and zoning, construction permitting, agricultural land management, environmental and forest land management, infrastructure corridors, disaster risk land-use restrictions
Reference standards: UN-GGIM Framework for Effective Land Administration, ISO 19152 LADM (Land Administration Domain Model), OGC standards for geospatial data, INSPIRE Directive (EU)
Status: Draft for discussion
Date: 2026-05-05
This proposal is the results of discussions that have arisen on Cross-Functional ID Building Block while reviewing the Wallet specification, Payments BB while separating Payment Orchestration from Payment Gateway capabilities, Registries and Registration WG when discussing how these 2 BB communicate together. These implementations pointed to a missing piece in the GovStack Architecture that so far we have named a "framework". This is a proposal for discussion to evaluate if it makes sense for inclusion.
1. Problem Statement
The GovStack Architecture defines two well-established concepts:
There is, however, a conceptual gap between them. Some Building Blocks only achieve their intended purpose when operating together with other Building Blocks, and when the organizations that operate them have agreed on shared rules, semantic standards, and governance. A digital wallet, for example, is not useful in isolation: it requires credential issuers, credential verifiers, and an identity provider. Each of those may be a separate, autonomous Building Block, but their combined usefulness depends on a shared set of rules that none of them, individually, defines.
The Generic Interoperability Framework described in Chapter 4 establishes the four cross-cutting layers —organizational, semantic, technical, and infrastructure— that enable systems to work together. What is missing is a concept for how those four layers are instantiated within a specific domain to coordinate multiple Building Blocks into a coherent, government-wide capability.
This proposal introduces Domain Frameworks as that missing concept.
2. Definition: What is a Domain Framework?
A Domain Framework is a domain-scoped set of governance rules, semantic standards, role definitions, and reference compositions that specifies how multiple Building Blocks and their operators must work together to deliver a coherent whole-of-government capability in that domain.
A Domain Framework is not software. It does not replace or supersede Building Blocks. It is the agreement layer that sits above individual Building Blocks and below the Digital Service System. It defines:
In short: a Building Block defines what a component can do; a Domain Framework defines how components must work together for a domain to function.
3. How Frameworks Fit in the Architecture
The table below positions Domain Frameworks against the existing architectural concepts:
The relationship is hierarchical but not exclusive:
3.1 Building Block Autonomy and Systemicity
One of the concerns this proposal answers is that Building Blocks are defined as autonomous. In section 4.5.1 Criteria for Building Blocks they are defined as such so that they can be deployed independently, provide a standalone service, and be tested against its own specification without requiring other Building Blocks to be present. While autonomy is a deliberate design choice to ensure replaceability and reusage, at the same time, many Building Blocks only deliver their intended value when operating within a system of other Building Blocks.
It is the objective of this proposal to clarify how that distinction does not contradict, but rather harmonizes two levels of description:
3.1.1 Digital Credentials Framework
A Wallet Building Block specification can and should scope itself to the wallet function alone: storing, presenting, and managing credentials held by the holder. However, a wallet is not functionally useful without credential issuers and credential verifiers.
Scoping Wallet BB to include Issuers and Verifiers requires a compliance applicant (i.e. a software vendor) to implement a full ecosystem to prove conformance of a single component. The Digital Credentials Framework resolves this by defining the systemic context separately. The Wallet BB is tested against a reference-conformant credential issuer and a reference-conformant credential verifier, actors whose behavior is defined by the Framework, not by the Wallet BB specification itself.
Each component remains individually testable; the Framework defines the contracts between them. While there is currently no Credential Issuer Building Block or Credential Verifier Building Block, it becomes much easier and iterable to define these are actors within a Digital Credentials Framework that must interact with a Wallet under certain contract requirements, so that compliance testing for Wallet BB can be clearly defined. After this definition of contracts is clear, it becomes easier for the Working Group to define, should they decide to, such Building Blocks.
3.1.2 Payments orchestration
A government typically operates multiple payment gateways arising from bilateral agreements that different ministries have established over time with financial institutions. A Payments Building Block may handle a single payment channel well, but a Payments Framework is needed to define how those gateways are orchestrated, how a payment instruction is routed to the correct gateway, and how results are reconciled across systems. A
Additionally, government payment flows — particularly G2B (government to business) and B2G (business to government) — depend on authoritative identity records for both natural and legal persons, and interact with government registries to validate beneficiary or payer status. The Framework establishes which Building Blocks are involved in these flows, what role each plays, and what contracts govern their interactions with external payment infrastructure.
In both cases, Building Block autonomy is preserved at the specification level: each BB is specified, implemented, and tested as a standalone component. Systemicity — the property of operating correctly within a larger, coordinated system — is addressed at the Framework level. The Framework also defines the minimum set of conformant actors required to validate that a Building Block implementation works correctly within its intended system context, providing the basis for end-to-end compliance testing that no individual BB specification can provide on its own.
4. Framework Layers
Each Domain Framework applies the four interoperability layers from the Generic Interoperability Framework to its specific domain:
4.1 Organizational Layer
Defines the roles, responsibilities, and institutional relationships within the domain. Who may operate as an issuer? Who governs the trust registry? What legal basis authorizes data sharing between participants?
4.2 Semantic Layer
Defines the shared data models, vocabularies, and schemas used within the domain. This ensures that "identity attribute," "credential," or "payment instruction" means the same thing to every Building Block and every organization operating within the framework.
4.3 Technical Layer
Defines which protocols, API contracts, and integration patterns govern interactions between participating Building Blocks. This builds on the cross-functional interoperability achieved by GovStack CFR and BB specifications, but narrows the scope to the domain.
4.4 Infrastructure Layer
Defines the shared infrastructure prerequisites: trust anchors, PKI hierarchies, registries, directories, or ledgers that the domain requires to operate. For example, a Digital Credentials Framework requires a publicly accessible credential schema registry and a revocation registry.
5. Relationship to Whole-of-Government Interoperability
In the maturity model described in section 4.1, Domain Frameworks are the primary instrument for reaching State 3: Whole-of-Government Interoperability. A government that has implemented GovStack Building Blocks and achieved Cross-Functional Interoperability (State 2) still has systems that speak the same technical language but may carry different semantic meaning and operate under different institutional rules. A Domain Framework resolves this by establishing the semantic and organizational layer for a specific domain.
6. Proposed Possible Domain Frameworks
The following is a proposed initial set of Domain Frameworks. This list is not meant to be prescriptive and the ultimate decision to create a framework rests on both Working Groups and the GovStack Initiative. However it is presented as an initial list for open discussion.
6.1 Digital Identity Framework
Governs how a person's digital identity is established, asserted, and trusted across government services.
Core roles: Identity Provider, Attribute Authority, Relying Party
Key Building Blocks: Identity BB, e-Signature BB, Consent BB
Key governance concerns: identity assurance levels (IAL), authentication assurance levels (AAL), federation of identity providers, attribute release policies
Reference standards: eIDAS, NIST SP 800-63, W3C DID
6.2 Digital Credentials Framework
Governs how verifiable credentials are issued, held, presented, and verified — enabling citizens to carry portable, tamper-evident claims (qualifications, entitlements, licenses) that any relying party can verify.
Core roles: Credential Issuer, Credential Holder (Wallet), Credential Verifier, Trust Registry Operator
Key Building Blocks: Wallet BB, Identity BB, Registry BB, Consent BB
Key governance concerns: credential schemas and versioning, revocation mechanisms, holder binding, selective disclosure, trust registry governance
Reference standards: W3C Verifiable Credentials, OpenID4VCI, OpenID4VP, ISO 18013-5 (mDL)
6.3 Trust Framework
Governs how trust relationships between organizations and systems are established, maintained, and revoked — the precondition for any cross-institutional data exchange.
Core roles: Trust Anchor, Trust List Operator, Certificate Authority, Auditor
Key Building Blocks: Identity BB, Information Mediator BB, e-Signature BB
Key governance concerns: PKI hierarchy, trust list publication, certificate lifecycle, audit and compliance requirements, cross-border mutual recognition
Reference standards: ETSI TS 119 series, X.509, eIDAS Trust Lists
6.4 Payments Framework
Governs how digital payment instructions are initiated, authorized, routed, and settled across government services — covering both citizen-to-government (G2C) and government-to-person (G2P) flows.
Core roles: Payment Initiator, Payment Service Provider, Clearing House, Beneficiary Registry, Reconciliation Agent
Key Building Blocks: Payment BB, Identity BB, Consent BB, Registry BB
Key governance concerns: payment scheme rules, beneficiary deduplication, fraud prevention, reconciliation and audit trails, financial inclusion requirements
Reference standards: ISO 20022, GSMA Mobile Money API, G20 cross-border payments principles
6.5 Data Sharing Framework
Governs how personal and non-personal government data is shared between institutions — determining who may request data, under what conditions, with what consent mechanisms, and with what audit trail.
Core roles: Data Provider, Data Consumer, Consent Manager, Audit Log Keeper
Key Building Blocks: Information Mediator BB, Consent BB, Registry BB, Identity BB
Key governance concerns: data categories and classification, purpose limitation, data minimization, cross-border data flows, audit and accountability
Reference standards: GDPR / national data protection law, OECD AI Principles (for automated decisions on shared data)
6.6 Person Registries Framework
Governs how government registries pertaining to natural persons are structured, maintained, and made to interoperate — spanning civil registration, population management, health, social protection, education, criminal justice, travel documents, and any other domain in which the state holds authoritative records about a person.
While some registries are hinted at in Annex 3 of PAERA, this framework articulates the contracts and workflows that allow distinct, domain-owned registries to exchange and reconcile data, construct composite citizen files (sometimes called "360° citizen views"), support functional identity derivation where a foundational identity document does not yet exist, and facilitate registration processes that span multiple registries simultaneously (e.g., a birth event that triggers updates in the civil registry, health registry, and population register in a coordinated workflow).
This framework may operate independently of a Digital Identity Framework — registries often predate digital identity infrastructure — but it defines the interoperability surface through which a Digital Identity Framework can anchor to authoritative civil records once one is in place.
Core roles: Registry Authority (per domain), Civil Registrar, Population Register Operator, Data Reconciliation Agent, Citizen File Aggregator, Registration Workflow Orchestrator
Key Building Blocks: Registry BB, Identity BB, Messaging BB, Information Mediator BB, Consent BB, Workflow BB
Key governance concerns:
Covered registry domains (non-exhaustive): civil registration (birth, death, marriage), population register, health records, social protection beneficiary registries, education and qualification records, criminal and judicial records, passport and travel document records, disability and social care registers
Reference standards: UN Principles and Recommendations for CRVS, OpenHIE Community Health Information Framework, GovStack Registry BB specification
6.7 Legal Entities Framework
As in the Persons Registry Framework, some juridical entities are hinted at in Annex 3 of PAERA. A Legal Entities Framework Governs how legal entities, companies, cooperatives, non-governmental organizations, associations, sole traders, and other recognized private actors, are registered, identified, regulated, and represented in government systems throughout their lifecycle.
The framework covers entity registration and the authoritative registries that record existence and legal status, as well as the downstream systems that consume those records: business licensing, tax administration, regulatory compliance, procurement eligibility, and dissolution or insolvency. It defines the interoperability contracts that allow a single registration event to propagate correctly to the relevant registries and regulatory bodies.
Core roles: Business Registration Authority, Licensing Body, Tax Authority, Regulatory Agency, Entity Registry Operator, Authorized Representative (director, beneficial owner, agent)
Key Building Blocks: Registry BB, Identity BB (for directors/beneficial owners), Information Mediator BB, Messaging BB, Payment BB (for fees and taxes), Consent BB
Key governance concerns:
Covered entity types (non-exhaustive): corporations, limited liability companies, partnerships, cooperatives, NGOs and foundations, sole traders, professional associations, public enterprises
Reference standards: GLEIF Legal Entity Identifier (LEI), FATF Recommendations on beneficial ownership, W3C Verifiable Credentials (for machine-readable certificates of incorporation), OpenCorporates data model
6.8 Land and Property Framework
Governs how land parcels, property rights, spatial boundaries, and the transactions and obligations that attach to land are recorded, managed, and made interoperable across the government systems that depend on them.
Land data underpins a wide range of government functions — property taxation, urban planning, construction permitting, environmental management, disaster risk reduction, agricultural land management, and infrastructure investment. Because these functions are typically administered by different agencies with different mandates, the framework defines the interoperability contracts that link the authoritative cadastre and land registry to the consuming systems, and specifies the workflows for events (sale, subdivision, inheritance, mortgage, expropriation, rezoning) that trigger coordinated updates across multiple systems.
Core roles: Cadastral Authority, Land Registry Operator, Tax Assessor, Urban Planning Authority, Construction Permit Issuer, Property Rights Holder (individual, company, state), Surveyor, Notary or Conveyancer
Key Building Blocks: Registry BB, Identity BB (for linking owners to person/entity records), Information Mediator BB, Messaging BB, Payment BB (for transfer taxes and fees), Consent BB
Key governance concerns:
Covered sub-domains (non-exhaustive): cadastre and land registry, property valuation and taxation, urban planning and zoning, construction permitting, agricultural land management, environmental and forest land management, infrastructure corridors, disaster risk land-use restrictions
Reference standards: UN-GGIM Framework for Effective Land Administration, ISO 19152 LADM (Land Administration Domain Model), OGC standards for geospatial data, INSPIRE Directive (EU)