Skip to content

Commit acb6608

Browse files
phin10nikosftskounis
authored
Topic d to be published 7 feb (#893) (#392)
Add topic d to discussion topics arf Co-authored-by: Nikos Fotiou <nikosft@gmail.com> Co-authored-by: Stavros Kounis (WSL 22.04) <skounis@gmail.com>
1 parent bb81137 commit acb6608

File tree

1 file changed

+244
-2
lines changed

1 file changed

+244
-2
lines changed

‎docs/discussion-topics/d-embedded-disclosure-policies.md‎

Lines changed: 244 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,245 @@
1-
# D - Embedded disclosure policies
1+
# D - Embedded Disclosure Policies
2+
3+
Version 0.5, updated 6 February 2025
4+
5+
## 1. Introduction
6+
7+
### 1.1 Discussion Paper topic description
8+
9+
This document is the Discussion Paper for eIDAS Coordination Group regarding
10+
Topic D: Embedded Disclosure Policies.
11+
12+
The ARF Development Plan \[ARF\_DevPlan\] describes this Topic as follows:
13+
14+
*The high-level requirements for the embedded disclosure policy need to be further elaborated,
15+
with a focus on defining specific use cases where the policy should be applied and identifying
16+
the language to be used for expressing these policies.*
17+
18+
### 1.2 Related risks in the Risk Register
19+
20+
The risk register for European Digital Identity Wallets \[RiskRegister\]
21+
contains the following risks that are related to the use of the Digital
22+
embedded disclosure policies:
23+
24+
|Risk type | Risk id | Related risk titles|
25+
|-------------|-------|-------------------|
26+
|High-level risks to the wallets | R6 | Data disclosure|
27+
28+
| R6 Data disclosure |
29+
|---|
30+
|Data disclosure is defined as the unauthorised exposure of personal data including special categories of personal data. The privacy breach risk is very similar when considered from a privacy rather than security viewpoint. |
31+
32+
More specifically, \[RiskRegister\] describes the following threats to a Wallet:
33+
34+
|ID | Threat description | Related risks |
35+
|---------|-------|-------------------|
36+
|TR30 | An attacker can defeat technical and procedural controls to extract data. | Data disclosure (R6) |
37+
|TR32 | An attacker can obtain knowledge on the embedded disclosure policy for attributes and present attributes contained in the current request by wallet units. | Data disclosure (R6) |
38+
39+
## 1.3 Key words
40+
41+
This document uses the capitalized key words 'SHALL', 'SHOULD' and 'MAY' as
42+
specified in RFC 2119, i.e., to indicate requirements, recommendations and
43+
options specified in this document.
44+
45+
In addition, 'must' (non-capitalized) is used to indicate an external
46+
constraint, for instance a self-evident necessity or a requirement that is
47+
mandated by an external document. The word 'can' indicates a capability, whereas
48+
other words, such as 'will' and 'is' or 'are' are intended as statements of
49+
fact.
50+
51+
## 1.4 Document structure
52+
This document is structured as follows:
53+
54+
- Chapter 2 presents legal requirements for embedded disclosure policies.
55+
- Chapter 3 discusses implementation and deployment issues.
56+
- Chapter 4 presents additional mechanisms for implementing embedded disclosure policies.
57+
- Chapter 5 lists the additions and changes that will be made to the ARF
58+
as a result of discussing this topic with Member States.
59+
60+
## 2 Legal requirements for embedded disclosure policies
61+
62+
Article 2 of Implementing Regulation (EU) 2024/2979 \[2024/2979\] defines embedded disclosure
63+
policy as:
64+
65+
> a set of rules, embedded in an electronic attestation of attributes by its
66+
provider, that indicates the conditions that a wallet-relying party has to meet
67+
to access the electronic attestation of attributes
68+
69+
In article 10 of Implementing Regulation (EU) 2024/2979 it is defined:
70+
71+
> 1. Wallet providers shall ensure that electronic attestations of attributes
72+
with common embedded disclosure policies set out in Annex III can be processed
73+
by the wallet units that they provide.
74+
>2. Wallet instances shall be able to process and present such embedded disclosure
75+
policies referred to in paragraph 1 in conjunction with data received from the
76+
requesting wallet-relying party.
77+
>3. Wallet instances shall verify whether the wallet-relying party complies
78+
with the requirements of the embedded disclosure policy and inform the wallet user
79+
of the result.
80+
81+
Annex III of the same regulation defines the following list of common embedded
82+
disclosure policies:
83+
84+
>1. 'No policy' indicating that no policy applies to the electronic attestations
85+
of attributes.
86+
> 2. 'Authorised relying parties only policy', indicating that wallet users may only
87+
disclose electronic attestations of attributes to authenticated relying parties
88+
which are explicitly listed in the disclosure policies.
89+
>3. 'Specific root of trust' indicating that wallet users should only disclose
90+
the specific electronic attestation of attributes to authenticated wallet-relying
91+
parties with wallet-relying party access certificates derived from a specific
92+
root (or list of specific roots) or intermediate certificate(s)
93+
94+
Therefore, Wallet Units, as well as the mechanisms used for defining and
95+
evaluating policies, shall provide support for at least policies
96+
2. and 3. above.
97+
98+
## 3 Discussion
99+
100+
### 3.1 Distribution of embedded disclosure policies
101+
102+
**Question 1**
103+
How should embedded disclosure policies be distributed? Options are:
104+
105+
(a) Embedded disclosure policies are provided in Provider metadata (e.g., by extending
106+
the "Credential Issuer Metadata" specified in section 11.2 of \[OID4VCI\]). This option
107+
does not require modifications to the attestation format.
108+
109+
(b) Embedded disclosure policies are included in the attestations. This option requires
110+
modifications to the attestation format. As far as existing formats are concerned,
111+
including ISO mdoc and IETF SD-JWT, it is not straightforward how this can be
112+
implemented.
113+
114+
115+
Policies can be integrated directly into metadata (or the attestation) or "linked"
116+
using a URL and stored by the Provider. The former approach has the advantage of
117+
not requiring any communication with the Provider when evaluating a policy, which
118+
may introduce privacy risks and hinder integration with protocols such as the Digital
119+
Credential API. However, updating a policy would necessitate the revocation and
120+
re-issuance of credentials.
121+
122+
The latter option, on the other hand, simplifies policy updates. Nevertheless, it
123+
requires Wallet Units to periodically communicate with the provider.
124+
Moreover, this approach may pose challenges in offline scenarios.
125+
126+
**Question 2** Policies should be integrated or linked? Shall
127+
ARF make a requirement about that or leave it as an option to the provider?
128+
129+
### 3.2 Enforcing of EDPs and communication of results to RPs
130+
131+
Article 10, paragraph 3 of Implementing Regulation (EU) 2024/2979 requires Wallet
132+
Units to "inform the wallet user of the (evaluation of the embedded disclosure policy) result." However,
133+
it does not specify how this result should be enforced. Related to that ARF 1.5.0
134+
includes the following requirement:
135+
136+
> EDP_07 The Wallet Unit SHALL enable the User, based on the outcome of the evaluation
137+
of the embedded disclosure policy, to deny or allow the presentation of the requested
138+
electronic attestation of attributes to the requesting Relying Party or the requesting
139+
Wallet Unit.
140+
141+
If an evaluation of the embedded disclosure policy results in "deny" and this result is enforced,
142+
generating an error that reveals the attestation's existence while denying presentation to the
143+
Relying Party may leak information about the user. A Relying Party should
144+
not be able to distinguish between a nonexistent attestation and an existing
145+
attestation for which presentation is denied. It is noted that currently protocols
146+
specified in the Implementing Acts do not consider such error response.
147+
148+
**Question 3**
149+
Do you agree that generating an authorization error may be a privacy threat and
150+
countermeasures should be considered?
151+
152+
**Question 3a**
153+
Shall Wallet Units be required to generate the same output (towards the Relying Party)
154+
in case an attestation does not exist and in case an attestation exists but
155+
presentation is denied?
156+
157+
158+
159+
## 4. Extended approaches
160+
Embedded disclosure policies can be extended beyond the list of the common embedded
161+
disclosure policies defined in \[2024/20179\]. In this section we discuss possible
162+
approaches. These approaches are motivated
163+
by the fact the Wallet Units should implement more advanced authorization decision processes
164+
to support *Wallet-Relying Party Registration Certificates*.
165+
166+
The draft Implementing Regulation for "the registration of wallet-relying parties
167+
and the common mechanism for the identification and authentication of wallet-relying
168+
parties" introduces "wallet-relying party registration certificate" (WRPRC) and defines
169+
it as:
170+
171+
> a data object that indicates the attributes the relying party has registered to
172+
intend to request from users
173+
174+
Therefore, a Wallet Unit in addition to the common embedded disclosure policies
175+
should verify that the requested attributes are included in the WRPRC
176+
177+
### 4.1 Relying Party authorization based on WRPRCs
178+
If Policies 2 and 3 considered by \[2024/20179\] are implemented based on Relying
179+
Party identifiers included in WRPAC and root of trusts for WRPAC respectively, this
180+
will prevent the use of intermediaries. It is reminded that according to requirement
181+
RPI_01 of ARF 1.5.0:
182+
183+
> [...] an intermediary obtains an access certificate containing its own name
184+
and unique Relying Party identifier
185+
186+
On the other hand, according to requirement RPI_03 of ARF 1.5.0:
187+
188+
> For each of the Relying Parties that uses its services, an intermediary SHALL
189+
obtain a registration certificate from a Registrar [...] (which) SHALL contain
190+
that Relying Party's name and unique identifier, as well as the list of
191+
attributes registered for that Relying Party
192+
193+
Therefore, intermediaries can only be supported only if embedded disclosure policies
194+
consider the Relying Party identifiers included in a WRPRC and the corresponding
195+
root of trusts.
196+
197+
**Question 5**
198+
Shall the ARF require common embedded policies 2 and 3 to consider Relying Party
199+
identifiers from WRPRCs and root of trusts for WRPRCs respectively?
200+
201+
### 4.2 Fine-grained policies based on Relying Party attributes
202+
Implementing embedded disclosure policies as simple whitelists hinders policy
203+
management, prevents fine-grained policies, and limits the expressiveness of a policy.
204+
An embedded disclosure policy may consider additional Relying Party attributes, or
205+
even user related attributes and user context,
206+
and define authorization rules using a policy definition language.
207+
Such an approach can provide
208+
Attestation Providers with more fine-grained control over which
209+
Relying Parties can access an attestation and under which conditions.
210+
211+
The expectations of such a policy definition language are (to be expressed as HLR):
212+
* It shall be standardized
213+
* It shall allow rules for authorization based on Relying Party attributes, User attributes,
214+
and contextual attributes
215+
* It shall enable conditions and logical operations
216+
* It shall enable filtering of Relying Party certificates based on roots of trust
217+
* It shall enable definition of which attestation attributes can be accessed
218+
if a rule if satisfied.
219+
220+
221+
**Question 6**
222+
What other expectations do you have from a policy definition language
223+
224+
225+
226+
## 5 Additions and changes to the ARF
227+
### 5.1 High-Level Requirements to be added to Annex 2
228+
The following High-Level Requirements will be added to Annex 2 of the ARF v1.11
229+
230+
### 5.2 High-Level Requirements to be changed
231+
232+
### 5.3 Descriptions to be added to the ARF main document
233+
234+
235+
## 6 References
236+
237+
| Reference | Description |
238+
| --- | --- |
239+
|[2024/2979]| Commission Implementing Regulation (EU) 2024/2979 of 28 November 2024 laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards the integrity and core functionalities of European Digital Identity Wallet|
240+
| [ARF_DevPlan] | Architecture and Reference Framework Development plan 2025, European Commission, v0.91, final draft |
241+
| [OID4VCI] | OpenID for Verifiable Credential Issuance - draft 15|
242+
| [OID4VP] | OpenID for Verifiable Presentations - draft 23 |
243+
| [RiskRegister] | Annex 1 to the Commission Implementing Regulation (EU) 2024/2981 of 28 November 2024 laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and the Council as regards the certification of European Digital Identity Wallets |
244+
2245

3-
Placeholder file

0 commit comments

Comments
 (0)