EAA Disclosure Policies

This document outlines a proposed solution for implementing the disclosure policy requirements from the Implementing Acts (IA) 5a to handle Relying Party authorization during presentation of credentials.

Motivation

In this model, the (Q)EAA provider directly defines rules for which RP data requests are acceptable, adhering to the dynamic authorization framework discussed later. Rather than using an allow list approach, the authorization is credential-based, giving more flexibility to the Issuer to manage the policy.

The authorization requirements for accessing Personal Identity Data (PID) and Electronic Attribute Attestation (EAA) data prioritize flexibility and scalability while addressing the following shortcomings of traditional methods like allowlists and static trust anchors:

• Limitations of Allowlists: Maintaining a comprehensive and updated list of entities (e.g., pharmacies) across Europe is impractical, given the large number of Relying Parties and their varying roles.
• Challenges with Root of Trust Models: Static root of trust mechanisms introduce risks due to inconsistent registry coordination, and are unable to adapt to evolving authorization needs across multiple jurisdictions.

To overcome these limitations, the solution advocates for an attribute-based authorization model that uses a query language like Digital Credentials Query Language (DCQL):

• Attribute-based access control: The usage of a query language to realize authorization policies avoids the pitfalls of static mechanisms by:
  • Ensuring RPs are validated through machine-readable, real-time policies.
  • Allowing issuers to define granular, adaptable rules for data access.
• Automation and Transparency: The Wallet processes DCQL-based requests automatically, providing users with clear insights into how their data will be used, while ensuring compliance with issuer-defined policies.

International interoperability

The following can be specified individually by each member state without impacting interoperability:

• Setting up management for Authorization Attestations

Out of Scope

The setup and administration of authorities responsible for the discovery of the disclosure policies and the setup of the authorities issuing the required credentials are out of scope of this document.

Overview

Policies

Disclosure policies are defined using a single policy object that follows the EmbeddedDisclosurePolicy JSON Schema. Each policy specifies one trust model and its corresponding values. Only one policy can be defined per credential.

Policy object

Field	Required	Type	Description
policy	Yes	string	Type of policy (allowList, rootOfTrust, attestationBased, none)
options	Conditional	array	Objects that define claims and values (or credentials)
url	Yes	string	Human-readable explanation URL of the disclosure policy

---

Allowlist Policy

Definition: A list of Relying Party identifiers (subject alternative names) that are authorized to request specific claims of this credential.

Rules:

• policy must be allowList.
• Each entry in options may include:
  • claims: OPTIONAL — array of claim paths to which the allowlist applies. If omitted, the allowlist applies to all claims in the credential.
  • values: REQUIRED — array of subject alternative names of the authorized Relying Parties.
• Wallets must match the RP’s access certificate against the allowlist. If an intermediary is used, the registration certificate subject must also appear in the allowlist.

Example:

{
  "policy": "allowList",
  "options": [
    {
      "claims": [{ "path": ["country"] }],
      "values": ["EI:SE-5567971433", "NTRDE-HRB123456"]
    }
  ],
  "url": "https://example.com/disclosure-policy"
}

---

Root of Trust Policy

Definition: Instead of enumerating all Relying Parties, the Issuer trusts only specific Access Certificate Providers to authorize RPs.

Rules:

• policy must be rootOfTrust.
• Each entry in options may include:
  • claims: OPTIONAL — array of claim paths to which the trust anchor applies.
  • values: REQUIRED — array of identifiers of Access Certificate Providers authorized to issue access certificates.
• Wallets must verify that the RP’s certificate chains to one of these trusted providers, which are listed in the EU Trusted List.

Example:

{
  "policy": "rootOfTrust",
  "options": [
    {
      "claims": [{ "path": ["country"] }],
      "values": ["GermanAccessCertificateProvider"]
    }
  ],
  "url": "https://example.com/disclosure-policy"
}

---

Attestation-Based Policy

Definition: Relying Parties must present authorization attestations fulfilling specific claim and credential requirements.

Rules:

• policy must be attestationBased.
• Each entry in options may include:
  • claims: OPTIONAL — array of claim paths requested. Defaults to all claims in the attestation if omitted.
  • credentials: REQUIRED — array of credential requirements, defined with credential query syntax.
  • credential_sets: OPTIONAL — credential set requirements, using credential set query syntax.

Example:

{
  "policy": "attestationBased",
  "options": [
    {
      "claims": [{ "path": ["last_name"] }],
      "credentials": [
        {
          "id": "membership",
          "meta": { "vct_values": ["https://example.com/membership"] },
          "format": "sd-jwt-dc",
          "trusted_authorities": {
            "type": "aki",
            "values": ["s9tIpPmhxdiuNkHMEWNpYim8S8Y"]
          }
        }
      ]
    }
  ],
  "url": "https://example.com/disclosure-policy"
}

Note: The attestation must be bound to the Access Certificate used for signing the presentation request.

---

None Policy

Definition: No disclosure restrictions are applied.

Rules:

• policy must be none.
• No options are required.

Example:

{
  "policy": "none",
  "url": "https://example.com/disclosure-policy"
}

---

Providing approaches

The policy MUST be included into the Credential Issuer Metadata by value, not by reference. Each credential configuration can have its own policy.
Policies may apply to all claims of a credential or only to specific claims as indicated in each options.claims array.

The Wallet fetches the policy during the issuance process and stores it.
If the Issuer updates its policy, it needs to revoke all issued credentials. During reissuance, the Wallet fetches the new policy.

Non-normative example (embedded policy with allow list):

{
  "credential_configurations_supported": {
    "SD_JWT_VC_example_in_OpenID4VCI": {
      "format": "dc+sd-jwt",
      "scope": "SD_JWT_VC_example_in_OpenID4VCI",
      "cryptographic_binding_methods_supported": ["jwk"],
      "credential_signing_alg_values_supported": ["ES256"],
      "vct": "SD_JWT_VC_example_in_OpenID4VCI",
      "disclosure_policy": {
        "policy": "allowList",
        "options": [
          {
            "claims": [{ "path": ["country"] }],
            "values": ["EI:SE-5567971433", "NTRDE-HRB123456"]
          }
        ],
        "url": "https://example.com/disclosure-policy"
      }
    }
  }
}

---

Policy discovery

Two perspectives must be distinguished:

• Wallet perspective (enforcement): Wallets always retrieve the disclosure policy from the Issuer’s metadata endpoint (.well-known/openid-credential-issuer) and enforce it during credential presentation. Policies may restrict specific claims, so the Wallet ensures that requested claims are only released if allowed by the stored policy. It will not fetch the policy during presentation to avoid leaking information.
• Relying Party perspective (discovery): Relying Parties must know in advance what authorization credentials they need or how to join the list of authorized relying parties. Since this is not yet defined in the ARF, we assume that attestation rulebooks or policy registries will serve as discovery mechanisms for RPs to learn about policy requirements, including claim-specific restrictions.

---

Authorization Attestation

The authorization attestation is not bound to a specific credential format, so any format that can be referenced by DCQL can be used.

Requirements for interoperability:

• Attestations should be revocable or short-lived.
• Attestations must be bound to the Access Certificates of the RP. A Wallet MUST NOT accept an attestation that is not bound if there is no other way to prove ownership.

In case of OID4VP, the authorization attestations have to be attached to the authorization request. Below are examples for specific credential formats that can be used for the authorization attestation.

---

Passing attestations

The RP can pass the authorization attestation in the authorization request via the verifier_info.

Non-normative example:

{
  "verifier_info": [
    {
      "format": "dc+sd-jwt",
      "data": "eyJ0eXAiOiJ...zLTQ1LTY3ODkiXQ~"
    }
  ]
}

---

Use Case Scenarios

Medical Credential Issuer Limits Access to Certified Pharmacies
→ Attestation-based policy (specific claims like prescription data).

Tax Authority Restricts Access to Financial Data Credentials
→ Root-of-trust policy (claim-specific or global).

Mobility Provider Credential Issuer Limits Requests to Public Authorities
→ Allowlist policy (restricted to relevant claims).