cs-04: Add Annex C — Tiered WUA for cross-platform Wallet Solutions

[leifj]

Annex C: Tiered WUA for cross-platform Wallet Solutions

This PR adds an informative Annex C to CS-04, proposing a two-dimensional model for Wallet Unit Attestation across heterogeneous deployment platforms (native mobile, web with companion software, and web-only).

Motivation

The EUDI Wallet ecosystem increasingly includes Wallet Solutions that are not exclusively native mobile applications. The European Business Wallet (CS-05) and some natural-person wallets deploy across multiple platforms. All participate in the same OID4VCI issuance flows and must produce conformant WUAs (WIA + KA), yet their security properties differ. Issuers need a way to evaluate these WUAs consistently.

Approach: two orthogonal dimensions

The annex introduces two independent dimensions:

KA dimension — key storage security (K1 / K2 / K3)

Level	Description	key_storage claim
K1	Certified device (CC, EUCC, or equivalent)	iso_18045_high or higher
K2	Hardware, non-certified	iso_18045_moderate
K3	Software	iso_18045_low

WIA dimension — software attestation coverage (S1 / S2 / S3)

Level	Description	Verification
S1	Full client attestation	Platform-issued cryptographic proof of app identity
S2	Partial client attestation	Companion-component attestation; host unattested
S3	Backend-only	No client-side integrity evidence

The dimensions combine into a 3×3 matrix where not all cells are equally likely, but all are expressible using existing TS-03 claim structures.

Contents

• C.1 Problem statement
• C.2 Two orthogonal dimensions (with attestation matrix)
• C.3 Mapping to WIA and KA data structures (claim tables + JSON examples)
• C.4 Issuer acceptance policy (guidance per credential type)
• C.5 Relevance to the European Business Wallet (CS-05)

Key design decisions

1. Technology-neutral — describes security properties, not specific technologies
2. No new claims — maps entirely onto existing TS-03 v1.5 claim structures
3. Issuer-driven — the K/S labels are a Wallet Provider implementation concern; issuers evaluate claim values via key_attestations_required
4. Informative — does not add normative requirements; provides guidance for cross-platform implementations

Relation to existing annexes

• Annex A: Example WIA/KA payloads → Annex C adds level-specific examples
• Annex B: Key binding vs holder binding → Annex C addresses a different concern (multi-platform attestation)

---

This contribution is motivated by the SIROS ID wallet deployment which spans web, web+plugin, and native platforms and needs to express varying attestation strengths to issuers in a standards-conformant way.

[miluDIGG]

@leifj Fine for WeBuild and probably necessary for Business Wallets, but it's a problem for natural-person wallets. S3, for example, goes against WIAM_10 (AS-WP-40-011), which is a SHALL: the Wallet Provider must verify Wallet Instance integrity before issuing a WIA. Some of the other cross-platform models have the same issue.

Also, unless the claims are adjusted, an issuer can't tell whether it's looking at S1, S2 or S3. That seems to undermine trust rather than support it — some wallet solutions have cryptographic proof of app integrity and others don't, and the issuer has no way to distinguish them.
Would it work to keep the annex but scope it to Business Wallets, or mark the natural-person applicability as open? The trust between BW and NP wallets would still need to be covered I think though.