FprCEN/TS 18297 EUDI Wallet Held Attributes Access Control, operation and management

[IshaiO]

Formal name

FprCEN/TS 18297 EUDI Wallet Held Attributes Access Control, operation and management

Overview

This document specifies the functionality of the Wallet Unit for Access Control to Wallet Held Assets (WHAs) i.e. personal data relating to the Wallet User and stored in the Wallet Unit. It defines the Wallet Access Control decision Engine (WACE) and the corresponding functional requirements, resulting in recommendations to the user on decision to be made.
This document aims at:

1. describing and specifying an Access Control Model supporting access control to the various possible operations on WHA(s);
2. providing the definitions and classification of the various types of data and metadata, and supporting access control to the various possible operations on WHA(s) ;
3. describing and specifying a W ACE controlling the access to the various possible operations on WHA(s) and the notification returned by the Wallet Access Control Decision Engine to a Wallet Unit;
4. identifying requirements applicable to the Wallet Access Control Decision Engine;
   This document also:

• identifies technical specifications and standards that can be used to support the concepts described herein;
• specifies additional requirements for the use of the identified specifications to meet the above objectives;
• provides the missing technical specifications needed to meet the above objectives where needed;
• provides examples and use cases;
  The Access Control Model and Wallet Access Control Decision Engine defined in this document aim to comply with the regulator requirements regarding access control.
  The following areas are out of the scope of this document:
  1. content and encoding of the policies assigned for the disclosure of WHA(s),
  2. implementation choice and encoding of Wallet Held Access Control Metadata;
  3. encoding of electronic attestation(s) of attributes which are in the remit of ETSI/TC ESI.

Work Plan

• CEN is developing the standard.
• The EC is following up with CEN on the development of this standard.

Updates

• 2026-01-07: CEN: Work draft 4 will be open for comments until 2026-02-06. It is expected to come to a final stage in the summer of 2026, and expected to be published in 2026.

Alerts

There are no open alerts.

References

• https://standards.cencenelec.eu/ords/f?p=CEN:110:::::FSP_PROJECT,FSP_ORG_ID:79593,6205&cs=11FADDA1A61090776E4C979D8F8350AA0

[mfah4]

Dear Ishai,
First of all, Thx for editing this page. Overall, when considering the limitations inherent to the eIDAS2 Regulation and ARF in terms of access control to the wallet held credentials, this CEN TS 18297 turns truly useful. Even though the LoA high is required for PID presentation and provisioning, it remains true that issuers do not have configurable means to finetune the access control depending on the nature of credentials (not all wallet credentials are PID, the Wallet is likely to host a variety of credentials/attributes of other kind for which specific rules may apply e.g. eHealth data, corporate data, financial data etc.).
Besides, Access Certificate does not enforce a dynamic authentication of RP with a challenge/response with the wallet (a passive authentication by checking the certificate validity on the ground of certification authority signature can suffice) and the Registration Certificate is optional (thus, sparing the RP the need to present further evidence of their identity to the wallet i.e. role, authorizations, domain name, purpose of usage, etc.) These limitations, in my opinion, justify the need for a tangible access control, configurable by issuers or by their sub-contractors, to strengthen user privacy and security. As soon as issuers will capture the benefit of this further access control, they can strart asking for it and offering it as a service with their wallet. We could even contemplate possibly a new business model with this approach that could as well leverage the confidence users lend to the wallet.
One another point : This TS 18297 does not impose assurance level beyond the one endorsed by the EU regulation; it only allows for issuers to configure, possibly upon users' demand, a data-specific policy per domain; and this could as example make a presentation of some non-PID credentials at LoA Substantial which it suffices or when it's the common practice in some domains, where user experience and security are a trade-off.
Additionally, I've the feeling that the interoperability offered by TS 18297 is not grasped by all experts : actually, the metadata governing the wallet access control engine, can be of any sort (language-agnostic), which means that evey single issuer can decide of its preferred metadata language without jeopardizing interoperability nor scallability. This is because the metadata are processed internally by the wallet access control engine, whereas the only thing that is required for interoperability is to agree on an entry-point (API) exposed by the wallet access control engine that shall receive from one hand the input from the Wallet Unit , and return from the other hand its advice/notification to the Wallet Unit.
I would encourage industries involved in eIDAS2 (through LSP or else) to experience the implementation of this TS 18297 to show how it fits with the EUID Wallet and brings advantages. Do you know, or could you envision a hands-on demonstration event where such functionality could be exposed ?

Best Regards
M.FAHER