Skip to content

Commit ba93ec6

Browse files
phin10phin10
authored
Release first discussion paper on topic z (#590)
* Topic z first discussion document for release * Update README.md for topic Z
1 parent e04b9eb commit ba93ec6

File tree

2 files changed

+180
-1
lines changed

2 files changed

+180
-1
lines changed

‎docs/discussion-topics/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ Iteration is planned from 20 August 2025 to 26 November 2025 covering the follow
9393
| R | [Authentication of the User to the device](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/348) |
9494
| S | [Certificate transparency](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/349) |
9595
| T | [Support and maintenance by the Wallet Provider](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/350) |
96-
| Z | [Device-bound Attestations](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/567) |
96+
| Z | [Device-bound Attestations](z-device-bound-attestations.md) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/567) |
9797
| AA | [Support of Electronic Payments Customer Authentication (SCA) with the Wallet](#topics) | [Roadmap issue](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/568) |
9898

9999
Earlier topics, planned to be additionally discussed in iteration 3:

‎docs/discussion-topics/z-device-bound-attestations.md‎

Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
# Z - Device-bound Attestations
2+
3+
Version 0.4, updated 19 Aug 2025
4+
5+
[Link to GitHub discussion](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/581)
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 Z - Device-bound Attestations
13+
14+
The ARF Development Plan [ARF_DevPlan] describes this Topic as follows:
15+
16+
Currently the ARF only assumes device-bound Attestations. Should this be extended to not-device-bound Attestations. What specific high level requirements for not-device-bound Attestations should the ARF specify?
17+
18+
19+
## 1.2 Key words
20+
21+
This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as
22+
specified in RFC 2119, i.e., to indicate requirements, recommendations and
23+
options specified in this document.
24+
25+
In addition, 'must' (non-capitalised) is used to indicate an external
26+
constraint, for instance a self-evident necessity or a requirement that is
27+
mandated by an external document. The word 'can' indicates a capability, whereas
28+
other words, such as 'will' and 'is' or 'are' are intended as statements of
29+
fact.
30+
31+
## 1.3 Document structure
32+
This document is structured as follows:
33+
- Chapter 2 presents requirements related to device-bound attestations.
34+
- Chapter 3 discusses use cases for non device-bound attestations.
35+
36+
## 2. Existing requirements related to device-bound attestations
37+
Device binding refers to the practice of cryptographically linking an attestation
38+
to a specific device, through the use of a private key stored in secure hardware.
39+
40+
One of the key advantages of device binding is its ability to prevent the sharing
41+
or unauthorized reuse of attestations. Since the attestation is tied to a cryptographic
42+
key that only exists on the user device, it becomes significantly more difficult
43+
for users to copy and transfer an attestation to another device or individual. Similarly,
44+
device binding prevents replay attacks, since each presentation shall include
45+
a fresh proof bound to the Relying Party.
46+
47+
On the other hand, when device binding is enforced, the portability of attestations
48+
would most likely require re-issuance of the attestation on the new device. Another
49+
disadvantage is that device binding can complicate the use
50+
of privacy-preserving protocols such as Zero-Knowledge Proofs (ZKPs), which may be
51+
considered in future versions of the ARF.
52+
53+
54+
The question of whether Electronic Attestations of Attributes (EAA) should be
55+
cryptographically bound to a specific device remains open. As of now, there is no
56+
legal requirement mandating such device binding. Section 6.6.3.8 of the ARF
57+
leaves room for future decisions on whether or not non device-bound attestations should
58+
be supported.
59+
60+
mDL specification [ISO/IEC 18013-5] enforces device binding through the use of a
61+
"deviceKey" which is included in the Mobile Security Object (MSO). This same key
62+
is also used to authenticate the device to verifiers during attestation presentation.
63+
Consequently, mDL implementations necessarily couple the attestation with the device
64+
that holds the private key, ensuring strong holder binding. On the other hand, [SD-JWT VC]
65+
and [W3C VCDM v2.0] treat key binding as an optional feature.
66+
67+
When it comes to attestation presentation, [OpenID4VP] provides mechanisms for holder
68+
binding but does not enforce them universally.
69+
Section 5.3 of the OpenID4VP specification describes how a Relying Party can request a
70+
presentation without requiring "holder binding proofs". Using this mechanism a
71+
Relying Party may indicate that such a proof is not required even if an attestation
72+
is device-bound.
73+
74+
Based on the above, three distinct cases can be identified regarding attestation binding and verification requirements:
75+
76+
1. The attestation is bound to a device, and the Relying Party explicitly requests a binding proof during presentation.
77+
2. The attestation is bound to a device, but the Relying Party does not require a binding proof.
78+
3. The attestation is not bound to any device.
79+
80+
**Question 1**
81+
82+
What are the advantages and disadvantages of each case?
83+
84+
85+
## 3. Use cases for non device-bound attestations
86+
### Low security attestations
87+
88+
A prominent use case for non device-bound attestations involves low-risk, low-security
89+
attestations such as event tickets, discount vouchers, or other entitlements where
90+
strong holder binding is not required.
91+
92+
In such cases, the level of assurance needed by the Relying Party is minimal, and the
93+
main functionality expected from the Wallet is to display a QR code that can be scanned
94+
at the point of access. Once the QR code is presented, no further interaction is needed
95+
between the Wallet Unit and the Relying Party. As a result, the Wallet functions
96+
primarily as a display interface rather than as an active participant in the verification protocol.
97+
98+
This model can be implemented efficiently by embedding the QR code as a display
99+
property of the attestation, allowing a User to simply present it to a compatible
100+
QR reader. In this setup, the Wallet assumes a passive role and has no control
101+
over the Relying Party with which the User interacts. Notably, this interaction
102+
flow is not explicitly addressed in the ARF. Moreover, since the QR code is treated
103+
as a static image from the Wallet’s perspective, if it encodes multiple attributes,
104+
the User cannot perform selective disclosure. In this context, whether or not the
105+
attestation is bound to the device becomes irrelevant. It is reminded, however,
106+
that [ISO/IEC 18013-5] enforces device binding as part of its specification.
107+
108+
It should be highlighted however, holder binding and device binding are related
109+
but not the same. An attestation may be bound to a device but not to a User.
110+
Device binding in this case will prevent attestation sharing, as well as replay
111+
attacks (as discussed in Section 2).
112+
113+
**Question 2**
114+
115+
What are the advantages and disadvantages of using device-bound attestations in this
116+
use case?
117+
118+
### Attestations Bound to a Biometric Trait
119+
120+
Another use case for non device-bound attestations involves attestations that are
121+
bound to a biometric trait of the User rather than to the device. In this model,
122+
the attestation includes a reference to a biometric identifier, such as a facial
123+
template or fingerprint hash, or even the actual biometric data, which serves as
124+
the basis for binding the attestation to its legitimate holder.
125+
126+
In practice, the Wallet may not be able to generate a binding proof on its own,
127+
since it lacks the capability to verify biometric traits against the reference template
128+
embedded in the attestation. Instead, binding verification must be performed
129+
externally—either by a biometric sensor operated by the Relying Party or through a
130+
trusted third-party service that conducts biometric matching.
131+
132+
On the other hand, device binding may offer additional security advantages as
133+
discussed in Section 2.
134+
135+
**Question 3**
136+
137+
What are the advantages and disadvantages of using device-bound attestations in this
138+
use case?
139+
140+
### Combined presentation of attestations
141+
One of the use cases for supporting non device-bound attestations is the combined
142+
presentation of multiple attestations. In certain scenarios, users may need to
143+
present a set of attestations issued by different providers, each attesting to
144+
distinct attributes. To support such combined presentations, mechanisms must exist
145+
to establish that the combined attestation belong to the same user. As discussed
146+
in [Topic K], this can be achieved through "Attribute-Based Binding". In this approach,
147+
attestations include a shared unique identifier—such as a PID number—that allows
148+
verifiers to correlate the attestations. Alternatively, redundant person identification
149+
data, such as name, date of birth, or address, can be used to infer linkage.
150+
151+
Under this model, it is not necessary for every attestation involved in a combined
152+
presentation to be device-bound. For example, a PID can be securely bound to a device,
153+
while complementary attestations, such as a university diploma or a professional license,
154+
may remain portable and unbound.
155+
156+
**Question 4**
157+
158+
What are the advantages and disadvantages of using device-bound attestations in this
159+
use case?
160+
161+
---
162+
163+
**Question 5**
164+
165+
What are other use cases for non device-bound attestations?
166+
167+
168+
## References
169+
170+
| Reference | Description |
171+
| --- | --- |
172+
| [ARF_DevPlan] | Architecture and Reference Framework Development plan 2025, European Commission, v0.91, final draft |
173+
| [ISO/IEC 18013-5] | [ISO/IEC 18013-5](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/issues/84), Personal identification --- ISO-compliant driving licence - Part 5: Mobile driving licence (mDL) application |
174+
| [OpenID4VP] | Terbu, O. et al., [OpenID Connect for Verifiable Presentations](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/issues/2), OpenID Foundation. |
175+
| [SD-JWT VC] | [SD-JWT-based Verifiable Credentials](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/issues/9) (SD-JWT VC). Retrievable from: <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/> |
176+
| [Topic K](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework-private/blob/main/docs/discussion-topics/k-combined-presentation-of-attestations.md) | ARF Discussion Topic K - Combined presentations of attributes |
177+
| [W3C VCDM v2.0] | Sporny, M. *et al,* [Verifiable Credentials Data Model v2.0](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/issues/115), W3C Recommendation |
178+
179+

0 commit comments

Comments
 (0)