#132 Objectives for EU Digital Identity Wallet Reference Framework under eIDAS

Sascha-Block commented 8 months ago

Description

This update aims to enhance the clarity and alignment of our project with the eIDAS requirements, ensuring that the objectives of the reference framework are well-defined and support the initiative's goals.

User Story

As an IT Architect involved in the EU Digital Identity Wallet Initiative,
I want the objectives of the reference framework to be clearly defined and aligned with the eIDAS Regulation,
So that we can enhance the project's clarity and alignment with eIDAS requirements, facilitating a more focused and compliant development process.

Acceptance Criteria

Scenario 1: Clarity of Objectives

Given an IT Architect or other stakeholders are reviewing the updated reference framework,
When they examine the objectives defined within the document,
Then they find each objective is clearly articulated, specifically addresses aspects of the eIDAS Regulation, and aligns with the goals of the EU Digital Identity Wallet Initiative.

Scenario 2: Alignment with eIDAS Requirements

Given regulatory experts are assessing the reference framework's objectives,
When they compare these objectives against the eIDAS Regulation requirements,
Then they confirm the objectives fully align with eIDAS, ensuring legal compliance and facilitating a secure digital identity ecosystem.

Scenario 3: Usability for Development Guidance

Given developers are utilizing the reference framework to guide their work on the EU Digital Identity Wallet,
When they reference the framework's objectives during development,
Then they are able to easily understand and apply these objectives, leading to efficient and focused development efforts that contribute directly to the initiative's goals.

pinamiranda commented 6 months ago

Thank you for reaching out. The new ARF version (ARF v1.4) enhances the clarity and alignment of the ARF with the eIDAS 2 Regulation requirements. Covered in the High Level Requirements Annex, are the listed requirements derived from the eIDAS 2 Regulation, that also have references to eIDAS articles where applicable.

OBIvision commented 5 months ago

I would suggest lack of clarity as the problem and further the real objective as they can be inferred are close to the opposite of regulation.

See e.g. on terminology obfuscation https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/179

The main issue is that the ARF structure fail to secure citizens - it turns into surveillance by design which is literally both destructive and illegal.

A zero-knowledge proof can share one credentials unlinkable, but what we need is transaction unlinkability, i.e. across a set of credentials, combined with qualified integrity, i.e. assurances that credentials are linked to and controlled by the citizens as well as means for accountability to enforce a contract. The later part being the very sensitive balance between unlinkability for the sake of security and markets can work on one side and on the other side that a contract can be enforced by a judge.

Beyond the fact that the present setup is security weak (smartphones are not secure spaces) lies the deeper problem that all transactions with the present specifications are linkable and thus feeding abuse.

We know both many bureaucrats and corporate entities favor models where control is transferred from the citizens to some system - but therein lies the problem. The role of GDPR and eIDAS is to prevent that - not to enforce it.

Sascha-Block commented 5 months ago

@OBIvision @pinamiranda Clarity according requirements is the primary objective of all.

With user stories in Cohn format with linked acceptance criteria, I propose a proven method.

Why? It is essential to formulate requirements precisely, clearly and easily understandably and to implement them without contradictions.

If requirements are in conflict with each other, it must be directly and clearly recognizable which implications result from this. In addition, decisions must be transparent, comprehensible and well justified at all times.

I agree with @OBIvision reasoning: it is true that we need to focus on unlinkability of transactions across a set of credentials, combined with qualified integrity.

In principle, frontends should only be given limited trust, if only because the frontend - due to the countless software components on it - can never be fully controlled.
This understanding also implicitly follows the basic principle of zero trust.

It requires a technical infrastructure that preserves the right to informal self-determination.

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework