Skip to content

Commit 40afab6

Browse files
authored
Add ADR: Business Wallet Unit Attestation based on TS3 (#232)
1 parent 76ae72a commit 40afab6

2 files changed

Lines changed: 46 additions & 0 deletions

File tree

adr/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@ Propose new ADRs using the [template](_template.md). Announce them to the [Archi
2626
17. [Support for Sole Trader Representation](Support-for-Sole-Trader-Representation.md)
2727
18. [QEAA Attestations and QERDS Documents](adr-qeaa-attestations-qerds-documents.md)
2828
19. [Credential Offer Endpoint Registry and Lookup Service](ebw-endpoint-lookup-service.md)
29+
20. [Business Wallet Unit Attestation based on TS3](bwua-ts3-attestation.md)
2930
<!--END INDEX-->
3031

3132
## Supporting analysis

adr/bwua-ts3-attestation.md

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# Business Wallet Unit Attestation based on TS3
2+
3+
**Authors:**
4+
5+
- Lal Chandran, iGrant.io, Sweden
6+
- Nikolaos Triantafyllou, University of Aegean, Greece
7+
8+
## Context
9+
10+
The EUDI Wallet (CS-04) defines its Wallet Unit Attestation through [Technical Specification 3 (TS3)](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts3-wallet-unit-attestation.md), where the Wallet Unit Attestation is composed as WUA = WIA + KA, that is, a Wallet Instance Attestation bound to one or more Key Attestations. TS3 lets Issuers determine a Wallet Unit's security level, authenticate it, and verify it has not been revoked for the lifetime of an issued attestation.
11+
12+
The [Wallet Unit Attestation and lifecycle management](wallet-unit-lifecycle-management.md) decision made a Wallet Unit Attestation mandatory for the European Business Wallet but did not fix its shape. The Business Wallet (CS-05) differs from the EUDI Wallet on several dimensions: it is a server or cloud-hosted service rather than an app on a personal device, its keys live in a Cloud HSM, an organisation-controlled HSM or server-side, and it plays Holder, Issuer and Verifier in one wallet at high, possibly batched or asynchronous, throughput.
13+
14+
A comparison of CS-04 and CS-05 shows that several dimensions can be reused from the EUDI Wallet approach as-is, while a smaller set requires CS-05-specific work. The settled, reused dimensions are roles, form factor, key custody, attestation shape, organisational identity carriage, and roles played. The open dimensions, addressed in separate ADRs, are lifecycle source, discovery, session binding, and throughput.
15+
16+
This ADR records the decision for the attestation shape dimension: how the Business Wallet Unit Attestation is structured.
17+
18+
## Decision
19+
20+
For WE BUILD Consortium usecases, the European Business Wallet SHALL adopt the TS3 Wallet Unit Attestation approach as the basis for the Business Wallet Unit Attestation (BWUA).
21+
22+
As a working hypothesis, the BWUA is composed as **BWUA = BWIA + SKA**, mirroring the TS3 WUA = WIA + KA structure:
23+
24+
- **BWIA** (Business Wallet Instance Attestation) attests the Business Wallet Unit and its components against the relevant requirements, in the role of the TS3 WIA.
25+
- **SKA** (Server Key Attestation) attests the keys used for credential binding where those keys are held in a Cloud HSM, organisation-controlled HSM or server-side environment, in the role of the TS3 KA adapted to a server form factor and key custody.
26+
27+
The following dimensions are reused from the EUDI Wallet (CS-04) / TS3 approach as-is, adapted only for the Business Wallet form factor where noted:
28+
29+
- **Roles** — Business Wallet Provider, Admin(s) and Users.
30+
- **Form factor** — server or cloud-hosted service.
31+
- **Key custody** — Cloud HSM, organisation-controlled HSM, server-side, or any.
32+
- **Organisational identity** — EBWOID carried as a claim, issued by member state business registries or similar.
33+
- **Roles played** — Holder, Issuer and Verifier in one wallet.
34+
35+
The lifecycle source, discovery, session binding and throughput dimensions are out of scope for this ADR and are decided separately.
36+
37+
## Consequences
38+
39+
Reusing TS3 gives the Business Wallet a known, interoperable attestation model rather than a bespoke one, so Issuers and Relying Parties can reason about Business Wallet security and revocation using the same structure as the EUDI Wallet. The BWIA + SKA decomposition preserves the TS3 separation between attesting the instance and attesting the keys, while accommodating server-side and HSM-based key custody that the EUDI Wallet's device-bound model does not assume.
40+
41+
Because BWUA = BWIA + SKA is recorded as a working hypothesis, the precise profile, including formats, the SKA's relationship to HSM key-attestation mechanisms, and conformance criteria, remains to be elaborated via a conformance specification. Where the Business Wallet's server form factor diverges from TS3 assumptions about a local WSCD, those divergences must be made explicit so that Issuers are not exposed to attestation semantics that do not hold for a cloud-hosted wallet.
42+
43+
## Advice
44+
45+
Once merged, this is our consortium's decision. This does not mean all participants agree it is the best possible decision.

0 commit comments

Comments
 (0)