
_Figure 01: The EU Digital Identity Wallet ecosystem._
That openness is both the value and the challenge. The issuer almost never built the wallet. It is being asked to place a credential into software made by a different organisation, running on a device it does not control, possibly in another country.
In a closed system this barely arises: if the same company makes the app and runs the service, it trusts its own software and the question never comes up. EUDI is the opposite by design, so trust has to cross organisational and national borders. What is needed is a portable, standard way for any wallet to prove itself to any issuer, with no prior relationship between them.
When a Person Identification Data (PID) Provider or a Qualified Electronic Attestation of Attributes (QEAA) issuer is about to release a high-value credential, it faces a simple but critical question: *is the thing asking for this credential a genuine, certified wallet, and will the credential be bound to keys that live in secure hardware?* A username and password cannot answer that. Neither can a TLS connection on its own. The answer is the **Wallet Unit Attestation (WUA)**.
The WUA is a signed statement, ultimately rooted in the Wallet Provider, that vouches for two things at once: the **authenticity of the wallet instance**, and the **protection level of the cryptographic keys** that will hold the credential. The ARF defines it as the wallet's trust anchor towards issuers and, where required, relying parties [1]. Without it, an issuer cannot distinguish a certified Wallet Unit from a convincing but rogue application.
This article unpacks the WUA into its two building blocks, shows how each is carried during OpenID4VCI issuance, explains how the EUDI TS3 profile tightens the generic OpenID4VCI rules, and walks through how an issuer verifies a WUA and how it behaves over its lifecycle.
This article focuses on the WUA at credential issuance, where it is defined and most visibly used. Wallet authentication towards a relying party at presentation time relies on a separate mechanism and is out of scope here.
## 2.0 What problem does a WUA solve?
Issuing a credential is an act of trust extended by the issuer to the wallet. Three concerns have to be settled before that trust is warranted:
- **Is the wallet genuine?** The issuer needs assurance that the requesting software is an instance of a Wallet Solution that has been certified and is operated by a known Wallet Provider, not a clone or a tampered build.
- **Are the keys safe?** A credential is only as trustworthy as the protection of the private key it is bound to. The issuer needs assurance that the binding keys were generated in, and cannot leave, a suitably certified Wallet Secure Cryptographic Device (WSCD) or key storage component, at the level of assurance the use case demands (for PID, the high level).
- **Can trust be withdrawn?** If a wallet instance or a key store is later found to be compromised, there has to be a way to revoke the attestations so that issuers stop trusting it. This is the subject of ARF discussion Topic C [2].
The WUA answers all three. It lets an issuer make a risk decision on solid, cryptographically verifiable grounds rather than on assumptions. Conceptually, you can explore the "why" behind these requirements on the playground's [Get started](https://eudi-wallet-wua-playground.igrant.io/docs) page.
## 3.0 The two building blocks of a WUA
A WUA is not a single token. It is composed of two attestations, both originating from the Wallet Provider but answering different questions.

_Figure 02: The WUA is the combination of a Wallet Instance Attestation and a Key Attestation, both rooted in the Wallet Provider._
### 3.1 Wallet Instance Attestation (WIA)
The **Wallet Instance Attestation** answers *"is this wallet instance genuine and healthy right now?"*. It is issued and signed by the Wallet Provider to a specific wallet instance after the instance has passed the provider's integrity checks. The wallet then proves it controls that instance with a separate proof of possession (the client attestation PoP), signed by the instance's own key [5]. During issuance it is used as **client authentication** at the OAuth 2.0 token endpoint, following the OAuth 2.0 Attestation-Based Client Authentication mechanism (media type `oauth-client-attestation+jwt`) [5]. OpenID4VCI v1.0 normatively references draft 07 of that mechanism [4][5].
Because the property it asserts ("this app is genuine and healthy") can change quickly, the WIA is deliberately **short-lived**: TS3 requires its time-to-live to be under 24 hours (TS3 §2.2.1.1) [3], so the wallet obtains a fresh WIA frequently. You can inspect a decoded WIA on the playground's [Wallet Instance Attestation](https://eudi-wallet-wua-playground.igrant.io/wallet-instance-attestation) page.
### 3.2 Key Attestation (KA)
The **Key Attestation** answers *"are the keys that will hold this credential in certified secure hardware?"*. It is a JWT, signed by the Wallet Provider, that lists one or more public keys in an `attested_keys` array and asserts that they were generated in, and are bound to, the **same** WSCD or key storage component, at a stated attack-potential-resistance level. In generic OpenID4VCI this is the `key-attestation+jwt` structure defined in Appendix D [4].
Crucially, the KA is the part that scales: a single KA can attest **many** keys at once, which is what makes batch issuance possible (Section 4.2). You can decode a KA, and toggle the TS3 profile, on the playground's [Key Attestation](https://eudi-wallet-wua-playground.igrant.io/key-attestation) page.
## 4.0 How a WUA is used during credential issuance
The two building blocks enter the OpenID4VCI flow at two different points.
```mermaid
sequenceDiagram
participant WU as Wallet Unit
participant AS as Authorization Server
participant CI as Credential Issuer
rect rgb(227, 242, 253)
Note over WU,AS: Stage A: authenticate the wallet (WIA)
WU->>AS: 1. Token request, client authentication with the WIA

_Figure 04: The WUA lifecycle. From the Issued state the attestation is kept current (revocation re-checked at least every 24 hours; re-issuance with a fresh single-use WIA and KA), until it becomes Revoked (status set to revoked) or Expired (WIA time-to-live elapsed)._
- **The WIA is short-lived.** Its time-to-live is under 24 hours (TS3 §2.2.1.1), so the wallet refreshes it frequently. This is appropriate because "the app is genuine and healthy" is a fast-changing claim.
- **The KA is single-use and describes a fixed fact.** "These keys are in this kind of certified secure hardware" does not change day to day, so the KA is not given a short expiry. Instead, a new, previously unused KA is sent on each re-issuance (TS3 §2.4.2).
- **Revocation is the safety net.** A PID Provider must re-check the revocation status of both the WIA and the KA at least once every 24 hours for the credential's validity period (TS3 §2.4.3). A KA must be revoked if a security vulnerability affecting the WSCD or key storage is identified (TS3 §2.5.2), and a Wallet Provider can revoke a wallet instance's attestations when it is no longer trusted [2].
- **Device and app updates.** TS3 does not define triggers specific to an operating-system update or a Wallet App update or reinstall. In practice, change is governed by the mechanisms above: the sub-24-hour WIA means a fresh WIA is obtained soon after any change, and whether a new KA or re-attestation is needed depends on whether the update alters the instance identity or the WSCD keys, which is implementation-specific.
The playground's [FAQ](https://eudi-wallet-wua-playground.igrant.io/faq) collects these lifecycle questions with their exact TS3 section references.
## 8.0 WUA in practice: real-world scenarios
The mechanics above play out in a handful of recurring patterns.
### 8.1 Issuing a PID at the high level of assurance
A government PID Provider receives a Credential Request from a wallet. Before it releases the PID, it authenticates the client with the WIA, validates the KA and its `x5c` chain to the Wallet Provider Trusted List, and confirms that `key_storage` and `user_authentication` report `iso_18045_high`. Only if the keys are shown to live in a high-assurance WSCD does it bind and issue the PID. If the assurance signals fall short, the issuer denies the request. Here the WUA is acting as the issuer's risk gate.
### 8.2 Batch issuance for unlinkable presentations
A wallet wants several copies of the same PID so it can present a different key to each relying party and avoid being tracked. It attests five keys in one KA and sends a single `jwt` proof. The issuer reads `attested_keys`, applies its `batch_size`, and returns one PID bound to each key, up to the cap. One user gesture, one proof, several single-use credentials.
### 8.3 A Wallet Unit Attestation in a European Business Wallet
WUAs are not limited to personal wallets. When a [European Business Wallet](https://docs.igrant.io/concepts/european-business-wallets/) requests an organisational attestation, the same two building blocks apply: a WIA authenticates the business wallet instance, and a KA attests the keys that will hold the organisational credential. The issuer's checks are identical in shape, which is why the lifecycle generalises across individual and business identity.
### 8.4 Withdrawing trust after a key-store vulnerability
A vulnerability is found in a particular WSCD model. Under TS3, the Wallet Provider must revoke the affected Key Attestations (TS3 §2.5.2), and because a PID Provider re-checks the revocation status of the WIA and KA at least every 24 hours (TS3 §2.4.3), the issued credentials stop being trusted without anyone having to reach into each wallet. This is why the WUA is not only an issuance-time check but a standing trust relationship.
## 9.0 Try it: the interactive WUA Playground
Reading about a WUA only takes you so far. The **[EUDI Wallet WUA Playground](https://eudi-wallet-wua-playground.igrant.io/)** lets you generate and inspect the real payloads in the browser, with nothing to install:
- Open the **[WUA Playground](https://eudi-wallet-wua-playground.igrant.io/home)** to set the number of keys and the `batch_size`, then click any **KA**, **proof**, **credential**, or **Credential Request** to read its JSON.
- Toggle "Show the TS3 profile" to diff the generic OpenID4VCI Key Attestation against the EUDI-profiled one, field by field.
- Watch the counters for credentials, WSCD signatures, and bound keys respond as you change the inputs.
It is an illustrative teaching aid: every payload is generated and signed client-side, and every detail links back to the source specification.
## 10.0 Conclusion
The Wallet Unit Attestation is what turns "trust me, I am a wallet" into something an issuer can verify. Its two parts answer two questions: the **WIA** proves the wallet instance is genuine and healthy, and the **KA** proves the binding keys live in certified secure hardware. Together they let an issuer release a PID or a (Q)EAA on solid, cryptographic grounds, support batch issuance from a single proof, and be withdrawn through revocation if trust is lost. TS3 sharpens the generic OpenID4VCI rules for the EUDI ecosystem, most notably by anchoring identity in the Trusted List via `x5c`, mandating high-assurance signals, and standardising on a single proof signed by the first attested key. The interactive playground is the fastest way to build intuition for how all of this looks on the wire.
## References
1. European Commission (2026), 'The European Digital Identity Wallet Architecture and Reference Framework (ARF) 2.9.0', Available at: [https://eudi.dev/2.9.0/architecture-and-reference-framework-main/](https://eudi.dev/2.9.0/architecture-and-reference-framework-main/)
2. European Commission (2026), 'ARF Discussion Topic C: Re-issuance and Revocation of Wallet Unit Attestations', Available at: [https://eudi.dev/2.9.0/discussion-topics/c-rr-wallet-unit-attestations/](https://eudi.dev/2.9.0/discussion-topics/c-rr-wallet-unit-attestations/)
3. EU Digital Identity Wallet (2026), 'Technical Specification 3 (TS3): Wallet Unit Attestation', Available at: [https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts3-wallet-unit-attestation.md](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts3-wallet-unit-attestation.md)
4. OpenID Foundation (2025), 'OpenID for Verifiable Credential Issuance (OpenID4VC) 1.0', Available at: [https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
5. IETF (2025), 'OAuth 2.0 Attestation-Based Client Authentication (draft-ietf-oauth-attestation-based-client-auth-07)', Available at: [https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-07](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-07)
6. ETSI (2026), 'ETSI TS 119 472-3 V1.1.1: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 3: Profiles for issuance of EAA or PID', European Telecommunications Standards Institute.
7. European Parliament and Council (2024), 'Regulation (EU) 2024/1183 (eIDAS 2.0)', Available at: [https://eur-lex.europa.eu/eli/reg/2024/1183/oj](https://eur-lex.europa.eu/eli/reg/2024/1183/oj)
8. iGrant.io (2026), 'EUDI Wallet WUA Playground', Available at: [https://eudi-wallet-wua-playground.igrant.io/](https://eudi-wallet-wua-playground.igrant.io/)
---
# What are EU Digital Identity (EUDI) Wallets
Source: https://docs.igrant.io/concepts/what-is-the-eu-digital-identity-wallet/
---
id: what-is-eudi-wallet
title: "What are EU Digital Identity (EUDI) Wallets"
hide_title: false
description: "Learn what EU Digital Identity (EUDI) Wallets are, what they store, who runs them, and when certified national wallets arrive under eIDAS 2.0 rules."
sidebar_label: What are EUDI Wallets?
keywords: [EU Digital Identity Wallet, EUDI Wallet, what is the EUDI Wallet, EUDI Wallet explained, eIDAS 2.0, Regulation 2024/1183, EU Digital Identity Regulation, implementing acts, PID, Person Identification Data, QEAA, PuB-EAA, EAA, public sector EAA, electronic attestation of attributes, wallet provider, relying party, digital identity wallet, European Business Wallet, selective disclosure, is the EUDI Wallet free, when is the EUDI Wallet available, iGrant.io]
slug: /what-is-the-eu-digital-identity-wallet/
image: /img/cDocs/what-is-eudi-wallet.png
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
| #
|
Activity
|
Phase
|
Actors
|
| Assessment
|
| 1.0
|
Perform DPIA or similar privacy assessment (external or self-assessment)
Output: DA template consisting of usage purpose, data attribute etc as per the DA schema
|
Definition and preparation
|
Assessor, DS, DUS
|
| For DS: Lawfully expose data and demonstrate provenance
|
| 2.1
|
If the organisation wishes to expose personal data to a third party, it creates the DDA offer, If required, publishes to a data marketplace
Output: DDA is available and is ready for any DUS to sign.
Provenance: action to create an entity (DDA) by an actor (DS).
|
Definition and preparation
|
DS
|
| 2.2
|
Add DUS when they sign up
Output: DDA is updated with the DUS signatory info (during the DDA capture phase)
Provenance: action to update and sign off entity (DDA) by an actor (DUS)
|
Capture
|
DUS
|
| 2.3
|
Any interested party can check the signed DDA proof of compliant data usage.
Provenance: Query to view provenance metadata
|
Proof
|
Auditor, Individual, DS or DUS or any 3PP
|
| 2.4
|
Automated enforcement of DDA
Provenance: query provenance metadata to ensure the signing of DDA is permitted
|
Proof,
Capture
|
DS, DUS
|
| For DUS: Lawfully consume data and demonstrate provenance
|
| 3.1
|
If the organisation (DUS) wishes to consume data, it checks the available DDA offers in the marketplace.
|
Definition and Preparation
|
DUS
|
| 3.2
|
Organisation (DUS) signs up (Same as step 2.2)
|
Capture
|
DUS
|
| 3.3
|
DUS updates and register the DA based on the DDA
|
Definition and Preparation
|
DUS
|
| 3.4
|
Any interested party can check the signed DA proof of compliant data usage
|
Proof
|
Auditor, Individual, DS or DUS or any 3PP
|
---
# Explore the concepts of Data Disclosure Agreements
Source: https://docs.igrant.io/concepts/data-disclosure-agreements-versions
---
id: mdo-dda-vocab-versions
title: Explore the concepts of Data Disclosure Agreements
description: See how data disclosure agreement versions evolve to support transparent, auditable data sharing between individuals and organisations.
hide_title: true
sidebar_label: DDA Vocabulary
keywords: [data disclosure agreements, DDA vocabulary, schema, data sharing, data governance, transparency, auditability]
slug: /data-disclosure-agreements-versions
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
The Data Agreement Vocabulary provides terms to describe and represent information related to processing of personal data based on established requirements such as for the EU General Data Protection Regulation (GDPR).
The table below provides different versions of the data agreement vocabulary.
* [Data Disclosure Agreement vocabulary - version 1.0](/schema/data-disclosure-agreements/v1.0/)
---
# Overview of Data Intermediation Service Provider
Source: https://docs.igrant.io/concepts/disp-overview/
---
id: disp-overview
title: Overview of Data Intermediation Service Provider
description: Learn how a Data Intermediation Service Provider facilitates secure, consent‑based data exchange between individuals and organisations.
hide_title: true
sidebar_label: Overview
keywords: [Data Intermediation Service, DISP, data exchange, MyData, data operator, EU Data Governance Act, consent, data sharing]
slug: /disp-overview/
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
A data intermediation service provider (DISP) is a key entity under EU regulations designed to facilitate the structured sharing and accessing of data between various parties. DISPs offer platforms, databases, or other infrastructures enabling data exchanges between data holders and potential users. These services may include the creation of bilateral or multilateral data exchange environments, platforms for joint data use, and specific setups to connect data holders with users. Additionally, DISPs play a crucial role in assisting data subjects - individuals whose personal data is handled - by providing the technical means necessary to make their data available while ensuring the exercise of their rights under EU data protection laws. DISPs must notify the competent authority before offering their services, ensuring adherence to regulatory standards and conditions, which include maintaining separate operations for their data intermediation activities and upholding non-discriminatory access to their services.
## What is a MyData Operator
MyData operators, as described in the [MyData Global Operator whitepaper](https://igrant.io/papers/Understanding-Mydata-Operators.pdf), are a specialised type of Data Intermediation Service Provider (DISP) centred on human-centric personal data management. They provide an 'infrastructure' that ensures interoperability at the technical, informational, and governance levels, thus facilitating the seamless flow of personal data across services. This approach is in alignment with the EU data strategy's emphasis on creating "data spaces," where data can be securely and efficiently shared under a framework that prioritises individual data rights and governance. As outlined in the EU Data Governance Act (Article 12), MyData operators play a pivotal role in realising the human-centric approach to data intermediation, essential for implementing the broader vision of the EU's data strategy. Their role underscores the importance of developing systems that support data exchange and enhance individuals' control over their personal information.
## MyData Operator ecosystem
A MyData Operator ecosystem realised by iGrant.io is as illustrated below.

A typical MyData Operator ecosystem is composed of actors holding one or more of the roles described below:
* **Individual**: This is the role of **data subject** as represented digitally in the ecosystem. In a MyData Operator model, the individual manages the use of personal data about themselves, for their own purposes, and maintain relationships with other persons, services, or organisations.
* **Data Operator**: The role responsible for operating the 'infrastructure' and providing tools for individuals in a human-centric system of personal data exchange. Operators enable people securely to access, manage, and use personal data about themselves as well as to control the flow of personal data within and between data sources and data using services.
* **Data Source**: The role responsible for collecting, storing, and controlling personal data which persons, operators, and data using services may wish to access and use.
* **Data Using Service**: The role responsible for processing personal data from one or more data sources to deliver a service
:::note
iGrant.io does **not** hold any data from the Data Source but provides the ability to verify the authenticity to any Data Using Service
:::
## Data sharing and data exchange
In iGrant.io MyData Operator, personal data flows from a Data Source to a Data Using Service based on the data agreements. The data agreements can be, for e.g., based on consent.
In an **Active Data Exchange** (also referred to as **data sharing**), the user is actively involved in the exchange of data in real-time. E.g. data exchange using the data wallet functions.
In **Passive Data Exchange**, the data is exchanged between the Data Source and Data Consumption Service based on a data agreement that was mutually endorsed between the Individial and the organisations involved.
## Data operator value proposition
Today, a typical organisation is forced to make a choice between digitalisation and data compliance. In a MyData Operator model, such as with iGrant.io, an organisation can continue to digitalise whilst being compliant to respective data regulations. It creates a WIN-WIN scenario between the individuals and organisations. This is further illustrated below.

iGrant.io key value propositions as are as summarised below:
### Organisations
It helps organisations, both private and public, **unlock the value of personal data** in a regulatory compliant manner. The key enablers include:
> * Reduces risk of non-compliance with data regulation frameworks like for example, Europe’s General Data Protection Regulation (GDPR)
> * Provides API-centric tooling that can easily be integrated to existing IT systems
> * Empowers consumers to exercise their data subject rights thereby establishing and mantaining trust
> * Get access to higher quality personal data and larger data sets
> * Monetise their personal data assets apart from being able to leverage data as part of a personal data ecosystem
### Individuals
For individuals, it enables them to take control over their data via easy to use interfaces to exercise their data rights. Using a data wallet function, individuals are able to carry their data and reuse them where ever needed. E.g. Identity data or health certificates etc.
---
# High-level Architecture
Source: https://docs.igrant.io/concepts/mdoDocs/mdo-main
---
id: mdo-main
title: High-level Architecture
hide_title: true
sidebar_label: Architecture
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
The iGrant.io MyData Operator (Also known as the Data Intermediation service provider as per the [EU Data Governance Act](https://docs.igrant.io/regulations/reg-eu-data-governance-act)) user guide primarily describes the platform functions for organisations and individuals. The purpose of this is to help any organisation admins with the on-boarding proces onto the iGrant.io platform and use the various services offered as a MyData Operator.
## Architectural overview
The overall iGrant.io platform with software components delivering iGrant.io services are as illustrated below.

### User interfaces
iGrant.io supports Operator admins, Organisations admins (Data Source and Data Using Service admins) as well as individuals. The supported user interfaces are as given:
#### Operator interface
This is towards operator admins and super admins to allow infratructure owner roles.
#### Enterprise dashboard
The platform provides a SaaS admin portal for all Data Sources and Data Using Services to self-onboard to iGrant.io. Here, the administrator is able to perform admin functions that include:
* Self-onboarding and configuring the look and feel of organisational page for individuals
* Viewing/modifying/deleting data agreements and publish them to individuals
* Viewing/modifying/deleting data exchange agreements and compliance to the GDPR, and facilitating integrations between Data Sources and Data Using Services
* Simplifying admin queries for consents, with view/download options etc.
* Sending notifications to individuals (e.g., data breaches as per GDPR requirements)
* Configuring webhooks for a number of event types (e.g., GDPR data subject requests)
* Automated deployment of iGrant.io Cloudagents with trust anchor configured.
#### User preference center
Apart from providing all services as RESTful APIs, the platform also provides out-of-the-box mobile SDKs (iOS and Android) and ReactJS portals that can be automatically deployed once the data agreement models are defined in the Enterprise Dashboard.
##### Web portal
All functions with the mobile SDK are also available via a web portal (with multiple language support) and include a user preference centre, data rights management and the ability to view the data agreement logs.
### MyData Operator layer
#### RESTful APIs
All iGrant.io services are available as RESTful APIs that can be integrated to existing IT systems. The APIs are published at https://docs.igrant.io/docs/developer-apis/ and are segregated according to MyData Operator functional elements.
#### Core backend components
As a certified MyData Operator, iGrant.io platform components are mapped to the MyData Operator reference model as laid out in the MyData Global Operator whitepaper [[3](https://igrant.io/papers/Understanding-Mydata-Operators.pdf)]. iGrant.io is committed to adhering to the MyData principles of ensuring human-centricity in digitalisation and continues to drive a fully interoperable, decentralised network of data operators that enables consented data sharing and exchange within a personal data ecosystem.
### External systems
Apart from connecting to different Data Source (s) and Data Using Service (s), the platform provides integrations to external identity providers as well enable connections to third party ledgers (e.g. an organisations own ledger or nation wide or global ledgers).
## Onboarding
### For organisations
Once registered with iGrant.io,the MyData Operator platform, the admin user can self-define the organisation profle (logo, cover image, description etc.), and follows the steps as illustrated below.

All APIs are defined at [iGrant.io Developer page](https://docs.igrant.io/docs/developer-apis/).
The webhook based notification services allow organisations to monitor and take actions for various events it is subscribed to.
### For individuals
The User of an organisation can access their personal data dashboard and data wallets via the organisations mobile app or webportal.
---
# Mobile SDKs and Data Wallet
Source: https://docs.igrant.io/concepts/mdoDocs/mdo-mobagents
---
id: mdo-mobagents
title: Mobile SDKs and Data Wallet
sidebar_label: Mobile SDKs and Data Wallet
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
Apart from providing all services as RESTful APIs, the platform also provides out-of-the-box mobile SDKs (iOS and Android). This consists of personal data dashboard features and data wallets as described below. It comes with multiple language support as well.
## Architectural overview
The overall architecture of iGrant.io Data Wallet with software components is illustrated below.

## Data Wallet Communication and Storage Stack
The overall architecture of iGrant.io Data Wallet communication and storage stack is illustrated below.

- Interaction between agents is using DIF DIDComm protocols which provides an end-to-end encrypted channel for - secure communication.
- Agents are connected to trust anchors for e.g. Indy to resolve and verify credential schemas and decentralised identifiers
- Every data exchange transaction is mutually signed cryptographically between the parties ensuring full auditability.
## Personal data dashboard
### User preference center
This provides individuals total transparency on what data is being used by the organisation down to the attribute level. Here, individuals can mark their preferences and choices concerning the sharing and controlling of their data down to the level of attributes and how they are used. The mobile app allows users to exercise their data subject rights in accordance with the GDPR.
### Data subject rights
The user app provides an individual user to make specific personal data requests towards organisations and providing a way for follow up, for example based on GDPR **Data Subject Requests** as per [GDPR Chaper 3 Articles](https://gdpr-info.eu/chapter-3/).
The specific web-based requests that needs workflow integrations are as given:
> * Data Download Requests ([Article 15](https://gdpr-info.eu/art-15-gdpr/), [Article 21](https://gdpr-info.eu/art-20-gdpr/))
> * Data Correction Requests ([Article 16](https://gdpr-info.eu/art-16-gdpr/))
> * Data Forget/Delete Requests ([Article 17](https://gdpr-info.eu/art-17-gdpr/))
### Data agreement logs
Here, all consents and data exchange transaction logs can be accessed by the user at any point of time.
## Data wallet
iGrant.io provides a digital wallet (as a mobile agent) implemented using self-sovereign identity technology. It allows to stores credentials, keys, and other secrets necessary for self-sovereign identity.
Data wallets enable entities to own their data. It facilitates portability and reusability of the data. Data wallets are digital containers for data that's required to control self-sovereign identity (SSI) and consents. Data wallets are based on Indy’s wallet implementation. The picture below shows the architecture for Indy based data wallet implementation.

Data wallets will reside in a location that is owned or controlled by the entity. For example, on an individual's mobile device. iGrant.io offers the capability of cloud backup in external servers or in an organisation’s server. The platform provides entities with the necessary interfaces to interact with their data wallet: for example, a mobile application or a web application. Contents of the data wallet are encrypted using a master secret and stored to a pluggable storage for e.g. an SQLite database.
**SSI user agents:** A user agent provides individuals or organisations with a software component, that can act on their behalf and interact with others. An individual is provided with a mobile agent and an organisation with a cloud agent. Agent-to-agent communication is performed using interoperable DIDComm protocols: for example, issuing data based on schema, exchanging data with consent metadata etc.
:::note
iGrant.io data wallets are not limited to smartphones. The architecture allows the agents to be integrated on to any hardware, e.g. wearables.
:::
The key functions enabled via the data wallet are:
> * Add certificates (credentials)
> * Exchange data (credentials)
### Add certificates
Provides ability for users to add data to the data wallet as per Self-Sovereign Identity mechanisms.
### Data exchange
Provides ability for users to add data to the data wallet as per Self-Sovereign Identity mechanisms using a QR code or any HW device.
---
# Personal Data Portal
Source: https://docs.igrant.io/concepts/mdoDocs/mdo-pdd
---
id: mdo-pdd
title: Personal Data Portal
sidebar_label: Personal Data Portal
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
Apart from providing all services as RESTful APIs, the platform also provides ReactJS portals that can be automatically deployed once the data agreement models are defined in the Enterprise Dashboard. This comes with multiple language support and include a user preference centre, data rights management and the ability to view the data agreement logs.
## User preference center
This provides individuals total transparency on what data is being used by the organisation down to the attribute level. Here, individuals can mark their preferences and choices concerning the sharing and controlling of their data down to the level of attributes and how they are used. The portal allows users to exercise their data subject rights in accordance with the GDPR (General Data Protection Regulation).
## Data subject rights
The user portal provides the individual user to make specific personal data requests towards organisations and providing a way for follow up, for example based on GDPR **Data Subject Requests** as per [GDPR Chaper 3 Articles](https://gdpr-info.eu/chapter-3/).
The specific web-based requests that needs workflow integrations are as given:
> * Data Download Requests ([Article 15](https://gdpr-info.eu/art-15-gdpr/), [Article 21](https://gdpr-info.eu/art-20-gdpr/))
> * Data Correction Requests ([Article 16](https://gdpr-info.eu/art-16-gdpr/))
> * Data Forget/Delete Requests ([Article 17](https://gdpr-info.eu/art-17-gdpr/))
## Data agreement logs
Here, all consents and data exchange transaction logs can be accessed by the user at any point of time.
---
# Explore the Minimum Disclosure Option (MDO) Model
Source: https://docs.igrant.io/concepts/mdoDocs/mdo-ref-model
---
id: mdo-ref-model
title: Explore the Minimum Disclosure Option (MDO) Model
description: Understand the MDO reference model, which enables privacy‑preserving sharing of only essential data in digital identity transactions.
hide_title: true
sidebar_label: Reference Model
keywords: [MDO reference model, MyData operator, identity management, OpenID Connect, data agreements, ISO 27560, privacy, consent]
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
In relation to Data Intermediation Service Providers (DISPs), the MyData operator (also known as a **Data Intermediation Service Provider** per EU DGA Article 10/12) presents a refined model encompassing nine core functional elements crucial for the management of personal data. The reference model, illustrated below from the MyData Operator paper, facilitates the use of personal data in a transparent and human-centric manner and supports interoperability among data operators through open and standardised interfaces.

:::note
The functional elements depicted in the reference model are specifically selected for their relevance to the MyData framework and their direct value to individuals. It is crucial to note that not all operators will incorporate every functional element as the model is not intended as a template for a single, comprehensive implementation.
:::
## Identity management
The iGrant.io identity management handles authentication and authorisation of individuals and organisations using the data exchange and verification services. The supported user roles are owners, admins, developers, auditors, verifiers and DPOs.
iGrant.io IDM is implemented using the Keycloak open-source IAM platform - see https://www.keycloak.org/) which offers OpenID connect / OAuth 2.0 protocols and end-points. It provides functions to federate different identity solutions compliant with OpenID Connect/OAuth2.0 and SAML, compliant with Web 2.0 standards. For example, the Data Source and Data Using service could be using different national identity solutions. In Sweden, the solution already integrates with BankID and the intention is to integrate with other national ID systems including eIDAS.
The solution also enables self-sovereign identity via the use of decentralised identifiers (DIDs) with a DID Registry and Verified Credentials (VC), all as per the Web 3.0 (W3C specification).
## Permissions and consents
Permission management enables human-centric control of personal data where individuals can view, grant, revoke, and modify different kinds of permissions related to data flows. It enables individuals to manage and have an overview of data transactions, interactions and to execute their legal rights (e.g. as per GDPR).
Being a consented data exchange platform, permission management is a foundational component in iGrant.io. This is released via the concept of "Data Agreements" (DA) that records the conditions for an organization to process personal data in accordance with privacy regulation (e.g. GDPR) captured in a signed receipt given to the individual.
Using iGrant.io services, organisations can manage DAs and its lifecycle. With a DA, an organisation can be transparent about what data is being used and based on what lawful basis the data is processed, e.g. contract, legal obligation, vital interests, public task, legitimate interests and consents as per Article 6 in the GDPR. Using the DA, the individual is able to transparently view all different usage purposes for which their personal data is used. For data exchange with consents, the individual can opt-in/opt-out to any purpose, down to the attribute level. The Data Agreement is based on standards like Kantara. It's being enhanced to cater towards granular consents and is being standardised via ISO27560 and via DIF (Decentralised Identity).
The typical end to end use case for enabling permissions and consents in iGrant.io is described below:
> 1. Organisation (admin) registers their data model and configures the data agreement that consists of the usage purpose, the data attributes used by the ageement, lawful basis, data policy configurations etc. In this case, the lawful basis for the data agreement is "Consent".
>
> 2. The org publishes the purpose to its individual users.
>
> 3. The individuals are able view at the relevant granularity levels (aka attribute level e.g. name, phone number) respective data. It allows individuals to exercise their rights (their data subject rights as per GDPR Article 12-23) and they can opt-in and opt-out of any data usage at various granularity levels, where consent is used as a lawful basis. This can be done in real-time.
In the use of Data Agreement with consent as the lawful basis, iGrant.io complies to **Kantara** and emerging **ISO** standards for Data Agreement (or consent) receipts.
With iGrant.io, an organisation can be transparent about what data is being used and based on what lawful basis the data is processed, e.g. contract, legal obligation, vital interests, public task, legitimate interests and consents as per Article 6 in the GDPR. The individual is then able to transparently view all different usage purposes for which their personal data is used. For data exchange with consents, the individual is able to opt-in/opt-out to any purpose, at the attribute levels.
## Service management
iGrant.io, as a MyData Operator or Data Intermediary, operates in an ecosystem with Individuals, Data Sources and Data Using Services. In order to navigate this ecosystem, the various actors are linked through the iGrant.io service registry. Service management onboards the various actors within the ecosystem. The human-centric manifestation of service management is the possibility for individuals to manage the relationships and connections to different data sources and data using services in the ecosystem.
iGrant.io enables a multi-operator environment via a distributed service registry at two levels: one at the individual level, the other at the organisational level.

In figure above, A, B and C are organisations (**Data Sources** and **Data Using Services**) while the dotted circle represents the ecosystem and the governance framework facilitating data exchange via the use of data agreements. iGrant.io has filed an international patent on facilitating a consented data exchange.
### Organisation level
For organisations, it involves the controller and processor agreement handling as part of a data ecosystem. This includes functions like organisation onboarding/provisioning, managing organisation users, adding end users or consumers to organisation, data agreement handling between organisations and individuals for data exchange, data regulation and compliance management etc.
### Individual level
For individuals, the service management function lies in enabling a decentralised application (dApp). This includes functions like registrations, user profile management, subscription to a specific organisation etc. Every use of personal data is handled via a Data Agreement.
## Value exchange
A sustainable business model is a requisite for any ecosystem. In a MyData Operator ecosystem, this means that all of the actors in the ecosystem need to have more benefits than mere costs. Both benefits and costs can be also non-monetary in nature.
The current iGrant.io value exchange features focus on an end-user based licensing model helping organisations to be compliant with regulations while enabling data exchange. Enhanced value exchange offering is driven by specific customer cases and their business models. In our current offering, the platform has a fully auditable transaction model that builds the ecosystem for deriving value from a personal data exchange scenario in a lawful manner.
For individuals, time and effort spent can be a big cost and benefits often come in the form of services that makes their lives easier, for e.g. providing better convenience. As data operators provide technical infrastructure for making multi-party data transactions possible, they are in a natural position to keep track of such transactions for the purposes of payments and billing or creating other forms of rewards, such as loyalty and bonus points. Operators may provide a standard ‘accounting’ mechanism which transparently keeps a log of the data transactions so that the different parties in the ecosystem may use it as the base for payments between the parties. Using data as the means of payment and paying individuals for their data are contentious issues.
iGrant.io platform keeps track of all data agreement transactions and data exchange. This can be accessed via respective APIs and the current model is to let organisations decide the value exchange model. The “monetisation” is dependent on the customer scenarios, for example, discounts for providing a consented sharing of personal data.
## Data model management
Data model management, as an operator functionality facilitates translation of one data model to another with the target to enable scalability, interoperability, and re-usability.
In iGrant.io data exchange services, organisations define their data models via Data Agreements implemented via standardised protocols such as DIDComm and SSI Agents (E.g. Aries protocols stacks). Every data transaction has an associated auditable and verifiable Data Agreement that records conditions for an organization to process personal data in accordance with data regulations and are often formulated automatically following a Data Protection Impact Assessment (DPIA). It is captured as a signed receipt given to the individual.
iGrant.io supports all CRUD operations on Data Agreements to enable services for managing data models for any organisation. It also supports the translation of one data model to another with the target to enable scalability, interoperability, and re-usability. The services are used for transparency, compliance, facilitating agreement handling between ecosystem players and exercising personal data rights in a standardised manner.
For more information on data agreements and related W3C standards, refer the [Data Exchange open specs](https://github.com/decentralised-dataexchange/automated-data-agreements), contributed as part of European Union [NGI-Trust eSSIF-Lab infrastructure project engagement](https://essif-lab.eu/automated-data-agreements-to-simplify-ssi-work-flows-by-igrant-io/).
## Personal data exchange
Personal data exchange, facilitated by a MyData Operator, is key to data portability, as well as the access and re-use of personal data. This functionality realises the interfaces that allow data exchange between **Data Sources** and **Data Using Services **in a standardised and secure manner.
In the iGrant.io model, personal data transfers from a Data Source to a Data Using Service are endorsed via **Data Agreements**. Data agreements are based on different legal bases, (e.g. consent, lawful purpose, contract, legal obligation, vital interests, public task and legitimate interests etc). If they’re without consent, individuals will only have limited or no rights to withdraw the consent, however, the individual can still follow what data is processed and why. For more information on data agreements and related W3C standards, refer to the Decentralised [Data Exchange open specs](https://github.com/decentralised-dataexchange/automated-data-agreements), contributed as part of European Union NGI-Trust eSSIF-Lab ADA project.
Data exchange can be of two types active and passive, depending on the individual’s involvement in real-time, 1) Active Data Exchange and 2) Passive Data Exchange:

### Active Data Exchange
In an **Active Data Exchange**, the individual is actively involved in the exchange of data in real-time, for example via a Data Wallet. A Data Agreement is signed during any data exchange. This can further be of two types:
1. Active Data Exchange using a Data Wallet: In this form of Active Data Exchange, the individual holds the data and uses the data to any Data Using Service.
2. Active Data Exchange using notifications: In this form of Active Data Exchange, the individual is notified of a request to use their data by the Data Using Service and the individual agrees to a data exchange from a given Data Source.
The picture below illustrates the active data exchange with the use of a data wallet.

The complete scenario of an active data exchange with an interoperable iGrant.io Data Wallet is described in the following demonstration video.
[](https://www.youtube.com/watch?v=NF81dlISBeA "iGrant.io Data Wallet")
### Passive data exchange
In **Passive Data Exchange**, the data is exchanged between the Data Source and Data Using Service based on a Data Agreement that was mutually endorsed between the Individual and the organisations (Data Source or Data Using Service) involved.Here, iGrant.io facilitates the direct transfer based on a individual’s valid permission or consent (If consent is the lawful basis for such transfer).
The picture below illustrates the active data exchange with the use of a data wallet.

:::note
With iGrant.io, a Data Using Service can engage in agreements with various Data Sources, facilitating the relationship between a data controller or data processor (as defined in the GDPR). iGrant.io takes a data minimisation approach to personal data transfer where only the consent and transaction logs are stored as well as identity data. iGrant.io does not store the actual data that is being exchanged.
:::
## Personal data storage
A Personal Data Store (PDS) helps individuals to gather, store, manage, use and share information needed to manage and organize one’s life better. It provides the individual tools to control what information is shared with whom and when. This data is originally issued by a Data Souces and iGrant.io helps data to be integrated from multiple sources in the individuals device – harmonising, using and re-sharing it under the individual’s control.
iGrant.io platform client SDKs and a decentralised PDS (dPDS) Data Wallet that acts as data source for individuals. In the dPDS models, the individual aggregates and holds personal data from multiple Data Sources without storing it in the iGrant.io cloud. Using iGrant.io services, individuals can grant permission and transfer that data to any Data Using Service in real-time or otherwise. An individual's personal data can be exchanged between different organisations based on the individual’s preference and all transactions are fully auditable.
Although iGrant.io provides any data that can be added to a personal data wallet by the individual, as a platform, iGrant.io has a data minimalistic posture and stores only data relevant to identify a person (e.g., email ID and mobile number) and to federate that identity within an ecosystem. iGrant.io also stores an individual’s consent and various transaction logs which can also be reused as a data source if the individual so desires.
Using this model, Data Sources and Data Using Services are connected via the individual. This configuration reduces legal liabilities whilst enabling greater control to individuals. As the person with the PDS is technically in the centre of the data transactions, it can be considered also a highly human-centric approach for data transactions.
## Governance support
A governance support framework helps mediate the relationships between people and organisations. The iGrant.io framework builds on the MyData principles, facilitates compliance with regulations and honours individual rights, supporting individuals, organisations as well as ecosystem partners. In iGrant.io, Data Agreements records conditions for an organization to process personal data.
The key governance aspects are:
* Data Agreement between Data Sources and the individual with a set of governance mechanisms to ensure sustainable data usage and data exchange
* Data is cryptographically signed and can be verified for its authenticity and origin
* Every data transaction is associated with a cryptographically signed Data Agreement that can be traced, is tamper-proof and can be audited by independent third parties
* Tamper-proof logging of all data agreements and data exchange enables multi-party trust handling via decentralised identifiers (DID) and verified credentials (VC)
### Webhooks-based event dispatchers
iGrant.io uses event-based dispatchers where organisations can configure their receiving payload URLs. Any user or other events will result in notification to the organisation that can be integrated as part of the IT workflow.
### Event notifications
iGrant.io provides organisations to issue notifications for specific events. This could be used to comply to GDPR during data breaches. These APIs can be integrated to an organisations to enable self governing notifications towards users as part of automating compliance.
## Accountability and logging
Transparency and accountability are important principles and prerequisites in many legislations. Accountability can enhance assurance and logging can mitigate risks of misuse or unintended use. Logging is not the sole responsibility of the operators and has counterparts in data sources and data using services.
Accountability arrangements may flow from the rules and regulations in the underlying governance framework, but many proto-operators work without an explicit governance framework. Even in those cases, operators have to comply with the relevant legislation that often includes logging and accountability obligations. In general, governance implies some accounting obligations; but if no explicit governance applies, logging and accountability are still needed for auditability and transparency.
iGrant.io provides logging of all data transactions in the form of signed data agreements. Organisations can opt to choose a DLT-based or non-DLT based immutable logging. Access logging, security logs and various other types of logs are stored and made available only for organisations. These logs are available in a decentralised manner (implemented via user and organisation agents) for both individuals and organisations.
---
# EU Implementing Regulations Overview
Source: https://docs.igrant.io/regulations/implementing-acts-overview/
---
id: implementing-acts-overview
title: EU Implementing Regulations Overview
description: Browse all EU Implementing Regulations for the European Digital Identity Framework, covering EUDI Wallet certification, protocols, trust frameworks, and more.
keywords: [EU Implementing Regulations, eIDAS 2.0, EUDI Wallet, Implementing Acts, certification, trust framework, digital identity, European Digital Identity]
hide_title: true
sidebar_label: Overview
slug: /implementing-acts-overview/
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
import RegulationOverview from '@site/src/components/RegulationCard';
| (1) | 5 | Operational risk assessment |
| | - | OVR-5-01: The requirements specified in ETSI EN 319 401 [1], clause 5 shall apply. |
| - | NOTE 1: When the identity proofing is done by the provider of person identification data itself, the risk assessment of the provider of person identification data can cover the identity proofing. |
| (2) | 6.1 | Identity proofing service practice statement |
| | - | OVR-6.1-02: An IPSP shall identify in its practice statement the use cases for which compliance with the present document is claimed. |
| - | NOTE 1: When the identity proofing is done by the provider of person identification data itself, the identity proofing service practice statement of the provider of person identification data can cover the information on the identity proofing and there is no need for a specific practice statement for identity proofing. |
| (3) | 7.9 | Vulnerabilities and incident management |
| | - | OVR-7.9-02: Reporting obligations according to ETSI EN 319401 [1] REQ-7.9.2-02X and clause 7.9.3 shall be fulfilled as required by the identity proofing context and the obligations of the provider of person identification data relying on the IPSP's service. |
| - | EXAMPLE: Reporting to the supervisory authority supervising a provider of European Digital Identity Wallets established in the designating Member State can be done in cooperation between the IPSP and the provider of person identification data. |
| (4) | 7.10 | Collection of evidence |
| | - | OVR-7.10-01: The requirements specified in ETSI EN 319 401 [1], clause 7.10 shall apply. |
| - | NOTE 1: Long-term requirements for retention of evidence can be fulfilled by the provider of person identification data requesting the identity proofing instead of by the IPSP when the two are different entities. |
| - | NOTE 2: The requirements of clause 8.5.2 of the present document apply. |
| (5) | 7.11 | Business continuity management |
| | - | OVR-7.11-02: Processes for crisis management according to ETSI EN 319401 [1], REQ-7.11.3-01X shall be as required by the identity proofing context and the obligations of the provider of person identification data relying on the IPSP's service. |
| (6) | 7.12 | Termination and termination plans |
| | - | OVR-7.12-01: The requirements specified in ETSI EN 319401 [1], clause 7.12, excluding REQ-7.12-11, shall apply. |
| - | NOTE: When the IPSP and the provider of person identification data requesting the identity proofing are different entities, they can agree mutual or unilateral assistance in establishing termination plans. |
| (7) | 8.1 | Initiation |
| | - | INI-8.1-05: In the event that the remote identity proofing process is aborted or fails, the IPSP shall ensure that individuals are provided with sufficient explanations and remedies particularly in the case of unattended remote identity proofing. The information should ensure that individuals can effectively contribute to the prompt resolution of the problem and, if needed, exercise their data subject rights – such as the right to rectification or the ability to contest the decision – against the relevant controller. |
| (8) | 8.2.1 | General requirements |
| | - | COL-8.2.1-08: The IPSP shall implement measures to ensure compliance with the requirements of data protection by design and by default in accordance with Article 25 of Regulation (EU) 2016/679 during the onboarding process especially as regards to the processing of biometric data. Relevant measures may consist of adequate privacy-enhancing cryptographic controls, devices and organisational measures. Those measures should limit the data collection to what is strictly necessary for the processing of biometric data and any other personal data to be collected from the physical and digital sources of identification for the binding of the User's personal identification data to their wallets and to the User's device in which the Wallet Unit is installed. |
| (9) | 8.2.4 | Use of existing eID means as evidence |
| | - | [CONDITIONAL] COL-8.2.4-02X: If the Baseline LoIP is targeted, the eID means shall have been notified at least at eIDAS LoA substantial or its assurance level shall have been confirmed by an accredited conformity assessment body defined in Article 2(13) of Regulation (EC) No 765/2008 or by an equivalent body, and, if all applicable requirements are fulfilled, the assessment shall result in a certificate of compliance based on a certification audit. This formal certification process shall be based on a security evaluation process that refers to the levels of assurance defined for notified electronic identification means or for certified European Digital Identity Wallets under Regulation (EU) No 910/2014 [i.25]. |
| - | COL-8.2.4-02A: void. |
| (10) | 8.3.1 | General requirements |
| | - | VAL-8.3.1-11X: The identity proofing process shall verify that the evidence is valid at the time of the identity proofing. |
| (11) | 8.3.3 | Validation of physical identity document |
| | - | VAL-8.3.3-21: The effectiveness of the measures for complying with the requirements VAL-8.3.3-05X, VAL-8.3.3-05A, VAL-8.3.3-05B, VAL-8.3.3-05C, VAL-8.3.3-07A and VAL-8.3.3-07X, shall be confirmed by an accredited conformity assessment body defined in Article 2(13) of Regulation (EC) No 765/2008 or an equivalent body. |
| - | VAL-8.3.3-22: The reference face image from the physical identity document shall be collected using near field communication and the process shall perform passive or active authentication of the chip on the physical identity document. |
| (12) | 9.1 | Introduction, compliance with the present document, general requirements for all use cases |
| | - | USE-9.1-01X: To be compliant with the present document, an identity proofing process shall conform to use case in clause 9.5 of the present document for Extended LoIP. |
| - | USE-9.1-03X: void. |
| (13) | 9.2.3.4 | Use case for automated operation |
| | - | USE-9.2.3.4-04: The IPSP shall establish target values for the FAR and FRR, based on a risk analysis and its threats intelligence procedure, by following the methodology established in the ENISA report 'Methodology for sectoral cybersecurity assessments' [i.28] or an equivalent methodology, in fully automated identity proofing processes. The target values used by the IPSP shall be equal to or lower than those set for hybrid use cases, when they exist. The IPSP shall maintain these target values for FAR and FRR consistently, supported by a risk analysis and its threats intelligence procedure. |
| (14) | 9.5.1 | General requirements |
| | - | First paragraph: Where the applicant is a natural person, including a natural person representing a legal person, and the identity of the applicant has been proven to Baseline LoIP by means of authentication using an eID, and an enhancement to Extended LoIP is required, the following requirements shall apply. |
| - | USE-9.5.1-08: The additional identity proofing required to strengthen the reliability of an identity is only applicable for eID that have not been issued with a reliance on automated comparison between face images for the initial issuance process. |
| (15) | 9.5.2 | Use case for enhancing identity proofing to Extended LoIP by a full identity proofing using an identity document |
| | - | USE-9.5.2-01: The identity proofing to enhance from Baseline to Extended LoIP shall be according to the requirements for Extended LoIP from one of the use cases described in clauses 9.2.2, or 9.2.3 of the present document for Extended LoIP. |
| (16) | 9.5.3 | Use case for enhancing identity proofing to Extended LoIP by use of a previously captured reference face image |
| | - | USE-9.5.3-01: An identity proofing process fulfilling the requirements for Extended LoIP from one of the use cases described in clauses 9.2.2, or 9.2.3 of the present document, or the identity proofing process has been peer reviewed or certified by an accredited conformity assessment body defined in Article 2(13) of Regulation (EC) No 765/2008 or an equivalent body to comply with assurance level high in accordance with Regulation (EU) No 910/2014 [i.25] shall be used to capture a reference face image and to bind the necessary identity attributes to this reference face image. |
---
# eIDAS - Remote qualified electronic signature and seal creation devices
Source: https://docs.igrant.io/regulations/implementing-acts-remote-creation-devices/
---
id: implementing-acts-remote-creation-devices
title: eIDAS - Remote qualified electronic signature and seal creation devices
description: Understand the EU Implementing Acts on remote qualified electronic signature and seal creation devices.
sidebar_label: Remote creation devices
keywords: [Implementing Acts, eIDAS, remote signing, qualified creation devices, electronic signature, electronic seal]
slug: /implementing-acts-remote-creation-devices/
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```