Skip to content

Commit 6cfed23

Browse files
phin10phin10
authored
Release/topic k document release 1 (#526)
* For release topic k first document (#1209) * Including readme updated for topic K
1 parent 7ef3ff9 commit 6cfed23

File tree

2 files changed

+208
-1
lines changed

2 files changed

+208
-1
lines changed

‎docs/discussion-topics/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,7 @@ Iteration is planned from 26 March 2025 to 02 July 2025 covering the following t
7373
| H | [Transaction logs kept by the wallet](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/338) |
7474
| I | [Natural person representing another natural person](i-natural-person-representing-another-natural-person.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/339) |
7575
| J | [Wallet to Wallet interaction](j-wallet-to-wallet-interactions.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/340) |
76-
| K | [Combined presentation of Attestations](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/341) |
76+
| K | [Combined presentation of Attestations](k-combined-presentation-of-attestations.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/341) |
7777
| L | [User requesting data deletion to Relying Parties](l+m-data-deletion-and-dpa-complaint.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/342) |
7878
| M | [User reporting unlawful or suspicious request of data to DPAs](l+m-data-deletion-and-dpa-complaint.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/343) |
7979
| N | [Data portability](n-export-and-data-portability.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/344) |

‎docs/discussion-topics/k-combined-presentation-of-attestations.md‎

Lines changed: 207 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,207 @@
1+
# K - Combined presentation of Attestations
2+
3+
Version 0.1, updated 7 May 2025
4+
5+
[Link to GitHub discussion](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/519)
6+
7+
## 1. Introduction
8+
9+
### 1.1 Discussion Paper topic description
10+
11+
This document is the Discussion Paper for European Digital Identity Cooperation Group regarding
12+
Topic K - Combined presentation of Attestations
13+
14+
The ARF Development Plan [ARF_DevPlan] describes this Topic as follows:
15+
16+
Requirements for implementing “combined presentation” need to be clearly defined.
17+
Combined presentation involves a transaction in which a Relying Party requests
18+
multiple attributes associated with the same User from various attestations
19+
(PID and/or (Q)EAAs) in a single request and receives those attributes consolidated
20+
in a single response. The goal for the Relying Party is to verify that all received
21+
attributes belong to the same User.
22+
23+
24+
## 1.2 Key words
25+
26+
This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as
27+
specified in RFC 2119, i.e., to indicate requirements, recommendations and
28+
options specified in this document.
29+
30+
In addition, 'must' (non-capitalised) is used to indicate an external
31+
constraint, for instance a self-evident necessity or a requirement that is
32+
mandated by an external document. The word 'can' indicates a capability, whereas
33+
other words, such as 'will' and 'is' or 'are' are intended as statements of
34+
fact.
35+
36+
## 1.3 Document structure
37+
38+
This document is structured as follows:
39+
40+
- Chapter 2 presents legal requirements and High Level Requirements (HLRs) defined
41+
in the Annex 2 of the ARF for the combined presentation of Attestations.
42+
- Chapter 3 details the topic and introduces discussion items
43+
- Chapter 4 lists the additions and changes that will be made to the ARF
44+
as a result of discussing this topic with Member States.
45+
46+
## 2. Legal requirements and existing High Level Requirements
47+
48+
According to the [European Digital Identity Regulation], article 5a (4):
49+
50+
> European Digital Identity Wallets shall enable the user, in a manner that is user-friendly,
51+
transparent, and traceable by the user, to:
52+
(a) securely request, obtain, select, **combine**, store, delete, share and present, under the sole
53+
control of the user, person identification data and, where applicable, in combination with electronic
54+
attestations of attributes, to authenticate to relying parties online and, where appropriate,
55+
in offline mode, in order to access public and private services, while ensuring that selective disclosure
56+
of data is possible; [...]
57+
58+
Annex 2 of ARF includes the following High Level Requirements (HLRs) for
59+
to the combined presentation of Attestations:
60+
### A. Functional requirements for ecosystem components <!-- omit from toc -->
61+
62+
| **Index** | **Requirement specification** |
63+
|-----------|-----------------|
64+
| ACP_01 | Wallet Units SHALL support the features in [ISO18013-5] and/or [OpenID4VP] (as applicable) that allow requesting and releasing attributes from multiple attestations in a single request and response. |
65+
| ACP_02 | Relying Parties SHOULD support the features in [ISO18013-5] and/or [OpenID4VP] (as applicable) that allow requesting and releasing attributes from multiple attestations in a single request and response. |
66+
| ACP_04 | If a Wallet Unit determines it must release multiple attestations to a Relying Party in a combined presentation of attributes, it SHOULD request a proof from the WSCA that the WSCA manages all of the private keys of these attestations. |
67+
| ACP_05 | If, as a result of ACP_04, the Wallet Unit receives such a proof from the WSCA, it SHALL include this proof in the response message containing the combined presentation of attributes and send it to the Relying Party. |
68+
| ACP_06 | If a Relying Party receives a combined presentation of attributes including a proof as meant in ACP_04, it SHOULD verify this proof to validate that the attestations in this presentation were issued to the same User. |
69+
70+
### B. Process requirements <!-- omit from toc -->
71+
72+
| **Index** | **Requirement specification** |
73+
|-----------|----------------|
74+
| ACP_07 | During issuance of an attestation, an Attestation Provider SHOULD be able to request that the private key for the new attestation is managed by the same WSCD as the private key of a PID or another attestation already existing on the Wallet Unit, provided that the Attestation Provider has verified during the issuance process that the new attestation indeed belongs to the User of that existing PID or attestation. |
75+
| ACP_08 | When receiving a combined presentation of attributes, a Relying Party SHOULD NOT refuse the attestations solely because a proof as meant in ACP_04 is absent. |
76+
77+
### C. Miscellaneous <!-- omit from toc -->
78+
79+
| **Index** | **Requirement specification** |
80+
|-----------|-----------------|
81+
| ACP_09 | The common [ISO18013-5] and [OpenID4VP] protocols, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a Wallet Unit to transfer a proof as meant in ACP_04 to a Relying Party. The Commission SHALL take measures to ensure that this is the case. |
82+
83+
## 3. Discussion
84+
85+
The concept of *combined presentation* refers to a process where a Relying Party
86+
requests multiple attributes concerning a single User, drawn from separate attestations
87+
(e.g., PID and/or (Q)EAAs), and receives a consolidated, verified response. The key
88+
functional goal is to enable the Relying Party to confirm that all presented attributes
89+
genuinely pertain to the same User without
90+
compromising trust, privacy, or data integrity.
91+
92+
### 3.1 Use Cases
93+
94+
### Real-World Use Cases for Combined Presentation
95+
96+
Scenarios where a User is asked to present different attributes from various
97+
physical documents are common in the real world—and are also relevant in the digital domain.
98+
These scenarios can be addressed more efficiently through combined presentation
99+
allowing a Relying Party to receive a consolidated set of attributes
100+
from different attestations.
101+
102+
#### **University Admissions**
103+
104+
A university evaluating prospective students may request a digital presentation containing:
105+
106+
- **Personal identification** (from a PID),
107+
- **Academic credentials** (from diploma or qualification attestations),
108+
- **Work or research experience** (from employment attestations or other EAAs).
109+
110+
These attributes typically originate from different issuers and must be validated as
111+
belonging to the same applicant. A combined presentation enables the university to
112+
efficiently pre-screen candidates based on custom admission criteria, while avoiding
113+
the processing of unnecessary data.
114+
115+
#### **Professional Licensing**
116+
117+
A regulatory body responsible for licensing professionals (e.g., doctors, lawyers, engineers) may require a presentation that includes:
118+
119+
- **Proof of identity** (PID),
120+
- **Professional degrees and certifications** (from educational authorities),
121+
- **Proof of prior licensure or work experience** (from previous employers or licensing bodies).
122+
123+
By accepting a combined presentation, the authority can streamline application reviews
124+
while ensuring all data belongs to the same applicant, supported by secure bindings
125+
across attestations.
126+
127+
128+
#### **Rental or Loan Applications**
129+
130+
When applying for a loan or renting a property, a service provider may request attributes such as:
131+
132+
- **Identity verification** (from PID),
133+
- **Proof of income or employment** (from employer attestations),
134+
- **Creditworthiness or financial history** (from financial institutions or credit bureaus).
135+
136+
These data points are usually dispersed across documents and issuers. Combined presentation
137+
allows the User to share only the required attributes in a secure, verifiable,
138+
and privacy-preserving way—simplifying onboarding while reducing the risk of fraud
139+
or misrepresentation.
140+
141+
142+
143+
### 3.2 Identity Matching
144+
A preliminary requirement for the combined presentation of attestations is
145+
**identity matching**. The Relying Party shall be able to verify that all attributes
146+
included in the presentation originate from attestations that refer to the same
147+
entity. Without such a mechanism, there is a risk of malicious combinations; for example,
148+
using a valid facial image from one User together with another person's `"age over 18"`
149+
attribute could enable fraud or unauthorized access.
150+
151+
High-Level Requirement ACP_04 of Annex 2 in the ARF mandates that Wallet Solutions
152+
support **cryptographic binding** of attestations to ensure that the WSCA manages
153+
all of the private keys of these attestations. However, other mechanisms may also be employed to support identity matching, including:
154+
155+
- **Relying Party-Specific Identifiers**: Unique identifiers assigned by the
156+
Relying Party—such as customer or contract numbers—can serve as a means of
157+
linking multiple attestations to the same User.
158+
- **Attribute-Based Binding**: Attestations may share a common unique identifier (e.g., PID number).
159+
160+
161+
**Question 1** Is ACP_04 enough?
162+
**Note** ACP_04 should be considered in conjunction with ACP_07. Relying solely on
163+
cryptographic binding, may not be sufficient if a User stores in their Wallet Unit
164+
an attestation that actually belongs to another individual. In such cases, cryptographic
165+
binding alone could still allow malicious combinations of attributes. Therefore,
166+
it may be necessary to extend ACP_04.
167+
168+
### 3.3 Security consideration
169+
#### Policies for Including Attributes
170+
Each attestation may have its own **Embedded Disclosure Policy**. In parallel,
171+
the **Relying Party Registration Certificate** may grant different access rights
172+
to different types of attestations.
173+
When a Relying Party requests a combined presentation containing attributes from
174+
multiple attestations, the **strictest applicable policy** must prevail.
175+
176+
#### Validity of Combined Presentation
177+
The **validity period** of a combined presentation shall be determined by the
178+
**minimum validity** of the individual attestations whose attributes are included.
179+
180+
#### Privacy Considerations
181+
Although individual attributes may not be personally identifying or trackable on
182+
their own, their **combination across attestations** may create a **unique tracking vector**.
183+
184+
185+
**Question 2** Are there other security issues that should be explicitly addressed?
186+
187+
**Question 3** How can the privacy risks from attribute combinations be mitigated?
188+
189+
**Question 4** These considerations are implied but not explicitly considered in Topic 18.
190+
Should a related requirement be introduced?
191+
192+
## 4 Additions and changes to the ARF
193+
194+
### 4.1 High-Level Requirements to be added to Annex 2
195+
196+
197+
### 4.2 High-Level Requirements to be changed
198+
199+
### 4.3 Descriptions to be added to the ARF main document
200+
201+
## 5 References
202+
203+
| Reference | Description |
204+
| --- | --- |
205+
| [ARF_DevPlan] | Architecture and Reference Framework Development plan 2025, European Commission, v0.91, final draft |
206+
| [European Digital Identity Regulation] | Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework |
207+

0 commit comments

Comments
 (0)