Topic D: Embedded Disclosure Policies

[phin10]

Welcome to the discussion on the Embedded Disclosure Policies, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document Topic D - Embedded Disclosure Policies.

The goal is to develop high-level requirements on the topic 'embedded disclosure policies', with a focus on defining specific use cases where the policy should be applied and identifying the language to be used for expressing these policies.

Items addressed in section 3 of the document are:

• the distribution of embedded disclosure policies, and
• the enforcing of embedded disclosure policies and communication of results to Relying Parties.

Additional, embedded disclosure policies can be extended beyond the list of the common embedded disclosure policies defined in [2024/20179]. In section 4 possible approaches are discussed. These approaches are motivated by the fact the Wallet Units should implement more advanced authorization decision processes to support Wallet-Relying Party Registration Certificates:

• Relying Party authorization based on WRPRCs,
• Fine-grained policies based on Relying Party attributes.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicD AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic D. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

AEPD: A little discussion about how, when, and why EDPs should be updated could be very useful to be mentioned in the ARF.

Response. It has been agreed that EDPs should be updated by updating the corresponding metadata and by revoking existing attestations. With respect to “when” and “why”, this depends on the specific use case.

AEPD: We agree that “Implementing embedded disclosure policies as simple whitelists may not be suitable for advanced use cases that may require finer grained policies”. However, “This discussion paper does not propose any requirement for such a language” seems somewhat contradictory. We do not understand how the two statements are intended to be reconciled.

A discussion on to what extent EDPs should be standardized to ensure interoperability and consistency is required.

Response. During the meetings with representatives of the member states, it was agreed that introducing such a policy language could hinder the adoption of EDP due to the need for specifications not only at the technical level but also at the semantic level. It was also concluded that combining whitelists with Relying Party Registration certificates provides a sufficient starting point.

AEPD: We advise that the ARF:

• Clarifies the specific use cases where EDPs shall/should/may be applied.
• Defines the language for expressing these policies.

Response. During the meetings with representatives of the member states, it was agreed that such a language will not be specified.

AEPD: We advise that the ARF: 

• Establishes how EDPs will be evaluated by Wallet Units.
• Defines the format for communicating the evaluation results to the users (not to the RPs, given that they should not be able to distinguish between a nonexistent attestation and an existing attestation for which presentation is denied) and the required transparency mechanisms.

Response. Such technical specifications are out of the scope of the discussion paper. They will be defined at a later stage following other processes.

AEPD: We advise that the ARF: 

• Clarifies when and how the results of EDP evaluations should be enforced.
• Clarifies how EDPs ensure that users’ decisions about what information they want to disclose are respected. This last point is essential concerning potential automated individual decision making involving the EDP evaluation. The data controller shall implement suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express their point of view and to contest the decision if some enforcement is decided. It is not clear to us after carefully reading section 3.2 (“EDP_07 The Wallet Unit SHALL enable the User, based on the outcome of the evaluation of the embedded disclosure policy, to deny or allow the presentation of the requested electronic attestation of attributes to the requesting Relying Party or the requesting Wallet Unit” but at the same time “If an evaluation of the embedded disclosure policy results in “deny” and this result is enforced”). Enforcement is only considered in some use cases and for the “deny” option? Further clarification is needed.

Response. The corresponding text has been modified to “If an attestation presentation is denied by the user” to remove ambiguity. The user always makes the final decision. There is no automated decision-making process.

AEPD: The ARF should specify how EDPs interact with other parts of the ARF, such as the WUA (Topic C).

Response. It is not clear how EDPs are related to WUA. Please provide more clarifications.

[samuelmr]

Policies can be integrated directly into metadata or "linked" using a URL and stored by the Provider. The integrated approach does not require any additional communication with the Provider but attestations shall be revoked when a policy is updated. On the other hand, the integrated approach prevents a provider from unilaterally changing an embedded disclosure policy.

According to OID4VCI, the issuer metadata can be fetched from the issuer's /.well-known/openid-credential-issuer location. If the policies are integrated into the metadata (but not in the credential), shall the wallet store a static copy of the issuer metadata (or at least the policies)?

[samuelmr]

Should this be an explicit requirement to the Wallet Solution? (To store a static copy and not fetch the issuer metadata and policies at the time of presentation of the attestation.)

[ad-Orange]

On the interest of EDP and policy definition languages
In the short term, EDPs probably make sense to avoid the biggest issues with information sharing in the short term. However, in the longer term, we’re not sure about the usefulness of complex policy definition languages. Detailed analysis of potential usage in use cases should be highlighted before a new complexity layer is added and lots of resources are invested in it.
To avoid the misdoings of potential malicious RPs, we think that something akin to what we are proposing in Topic X would be a better compromise between privacy/security and commercial frictions.

On intermediaries
We repeat what we wrote in Topic X:
The very notion of intermediaries arguably theoretically goes against the SSI approach that was followed (and rightly so, we think) by the ARF. We have not seen anywhere in the ARF where this notion is addressed heuristically and comprehensively to get a better grasp on the necessity for it and the drawbacks it introduces so that they can be compared rationally and systematically. We think it should be the object of an upcoming topic to ensure all the aspects of it are properly taken into account.

[DC4EU-Consortium]

On behalf of DC4EU LSP:
While the discussion on Embedded Disclosure Policies clearly acknowledges the usefulness of complex authorization decisions in many real-world scenarios, it wisely sets the main objectives for this first iteration by considering the practical limitations that could hinder timely adoption (see Section 3.4: Fine-grained policies based on Relying Party attributes).

Within this framework, the current proposal structures access management decision rules around the following components:

a) an Embedded Disclosure Policy, defined by the attestation provider and integrated within the attestation itself. Embedded Disclosure Policy acts more or less as guidelines for the citizen, which are presented by the wallet. This policy can be used by the Wallet Instance to match against the requesting Relying Party (RP) identifier in order to evaluate additional access management rules;
b) a set of X509 PKCs (Access Certificate) and an Attributes Certificate AC, defined during the registration of the RP (or intermediary), and integrated within the WRPAC and WRPRC respectively. These conditions are intended to facilitate RP’s Authentication and the RP’s eligibility to request user attributes. The WRPAC and WRPRC are jointly evaluated by the Wallet Instance during the disclosure process.

Nevertheless, from a public service perspective, selective disclosure policies that only provide user-facing guidelines lack the necessary granularity to define robust and enforceable authorization rules. In the context of public services, it is critical to localize authorization policies to account for contextual, role-based, and often jurisdiction-specific requirements.

Designing access management and authorization is complex, and some simplifications are often needed to avoid over-engineering. However, the current proposal, with its approach of embedding or hard-coding all authorization-relevant information directly into attestations, introduces significant limitations. Unless the target scope of EDP is restricted to a limited set of public-sector bodies, this design lacks the flexibility and scalability required to support both the anticipated number of Relying Parties and, more importantly, the dynamic nature of the private sector. In this context, the frequent onboarding of new entities, deprecation of existing ones, and ongoing shifts in service offerings make the one-by-one listing of eligible RPs (policy 2) impractical to manage and use at scale. On the other hand, access controls that rely on static trust anchors (policy 3) risk being prohibitively generic in many cases.

Thus, we propose the following two key adjustments to the current framework:

Role-based access management (regarding the Embedded Disclosure Policy)
Instead of choosing between using a trust anchor (and implicitly all nodes signed by it) or explicitly listing each RP by its identifier, it would be more effective to introduce a business-relevant attribute to control access — such as activity code or sector code of the RP— by leveraging established European catalogues and vocabularies during the RP registration process. This approach would allow an attestation provider, for example, to grant access to all healthcare providers or all higher education institutions. Classifications based on existing vocabularies and legal entity registries can enable fine-grained access control without introducing additional burdens on the registration process. Also, Role-based access control can function independently or in combination with trust anchor policies, offering greater flexibility and alignment with sector-specific requirements.

Complementary remarks and request for clarifications

1. The two-layered access control approach, combining the Embedded Disclosure Policy (EDP) and attribute-based access control on the Relying Party (RP) side, may unintentionally exclude RPs from accessing attributes they are otherwise eligible to request (e.g., family_name). This can occur when an attestation contains both sensitive and non-sensitive attributes, and the EDP restricts access to the entire attestation based on a single sensitive attribute. As a result, RPs may be denied access even to basic attributes they are entitled to, simply because the EDP enforces restrictions at the attestation level rather than allowing per-attribute control.

This not only creates unnecessary barriers for legitimate access but also undermines one of the core privacy-enhancing benefits of selective disclosure, the ability to share only the minimum necessary information, without exposing unrelated or sensitive data.

2. In REQUIREMENT 3, it is stated: “A Wallet Unit SHALL retrieve and store locally the corresponding policies during PID or Attestation issuance.”
   If the policy is embedded in the attestation, this requirement appears redundant.

3. In [ARB_22], it is stated: “Note: An Attestation Rulebook may also specify requirements regarding how the Wallet Unit must display the attestation and the attributes in it to the User.”

We suggest replacing this with:
“Note: An Attestation Rulebook may also provide guidelines regarding how the Wallet Unit should display the attestation and its attributes to the User.”

4. In Section 3.1 — Distribution of Embedded Disclosure Policies, the rationale for preferring the “integrated approach” is weakly justified, especially given that the same section notes:
   “The integrated approach does not require any additional communication with the Provider, but attestations shall be revoked when a policy is updated.”

5. It should be clearly defined if the Provider EDP is advisory or mandatory, and whether the wallet holder can ignore it.