Disclosure Policies / Relying Party Authorization¶

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

Motivation¶

In this model, the (Q)EAA provider directly defines rules for which RP data requests are acceptable directly, 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 the 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¶

The authorization methods will be defined in the authz to support alternative approaches in the future. The issuer should not add more than one method to the authz object since it is not clear which one should be used, what the priority is and what to do in case of a conflict.

Allowlist¶

allowlist: a list of Relying Parties identifiers that are authorized to request this credential. This approach is called Authorized relying party only policy in the Implementing Acts. For the unique identifier the distinguished name of the RP is used.

Root of Trust¶

rootOfTrust: the certificate of a RP must be derived from a list of specific root certificates. In the Implementing Acts it's called Specific root of trust. The value has to be the distinguished name of the root certificate.

Attribute based access control¶

attribute_based_access_control: a attribute based access control approach where the issuer is able to define the conditions of credentials the Relying Party has to pass to the Wallet to be authorized. The Dynamic Credentials Query Language (DCQL) is used to describe the requirements and allow the Wallet to automatically compare this against the presented credentials of the Relying Party.

credentials: REQUIRED, represents a list of credential queries.
credential_sets: OPTIONAL, represents a lists of credential set queries, allowing to define multiple conditions for authorization.

{
  "attribute_based_access_control":{
    "credentials":[
      {
        "id": "certified",
        "format": "dc+sd-jwt",
        "meta": {
          "vct_values": ["http://example.com/certified"]
        },
        "iss": "https://example.com/issuer"
      }
    ]
  }
}

Providing approaches¶

To fetch the policy, the issuer is able to link them via the credential format or the transport method. While embedding the policy has the advantage of being self-contained, the issuer is not able to update the policy without reissuing the credential. Because of this, the policy should be linked and then cached by the Wallet.

Credential format¶

For SD-JWT VC, the policy can be referenced in the SD-JWT VC Type Metadata. To protect the integrity of the policy, the issuer can add an integrity check and reference it in the metadata.

{
  "vct":"https://example.com/education_credential",
  "name":"Education Credential - Preliminary Version",
  "description":"This is our development version of the education credential. Don't panic.",
  "extends":"https://galaxy.example.com/galactic-education-credential-0.9",
  "extends#integrity":"sha256-9cLlJNXN-TsMk-PmKjZ5t0WRL5ca_xGgX3c1VLmXfh-WRL5",
  "schema_uri":"https://exampleuniversity.com/public/credential-schema-0.9",
  "schema_uri#integrity":"sha256-o984vn819a48ui1llkwPmKjZ5t0WRL5ca_xGgX3c1VLmXfh",
  "authz": "http://example.com/policy/education_credential",
  "authz#integrity": "sha256-o984vn819a48ui1llkwPmKjZ5t0WRL5ca_xGgX3c1VLmXfh"
}

Transport method¶

The policy can be linked in the issuer metadata:

{
  "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",
      "authz": {}, //policy is embedded or linked here
  }
}

Instead of publishing the rules directly into the issuer vc metadata, the rules can also be linked like:

{
  "authz": {
      "reference": "http://example.com/policy/education_credential",
      "reference#integrity": "sha256-o984vn819a48ui1llkwPmKjZ5t0WRL5ca_xGgX3c1VLmXfh"
  }
}

Privacy Considerations¶

Since the policy is linked and needs to be fetched, there is a minimal risk of monitoring:

The policy for it is placed into the general issuer metadata at /.well-known/openid-credential-issuer that includes all credentials the issuer offers.
The Wallet is able to cache these information locally and needs to fetch the endpoint just to get periodic updates. This could also be the case to sync information like the display data.
The request of the endpoint is without any kind of authentication so the issuer only receives the IP address. The Wallet should not insert any user agent information that allow the issuer to identify the holder.

A malicious issuer could use a unique domain like 4728202.example.com so each credential issued is using a unique sub domain. To eliminate this risk, all domains need to be registered or make public available, e.g. via the RP Registrar to avoid such a behavior and to allow the Relying Parties to discover the authentication rules for the credentials offered by an Issuer. The same attack vector exists when using status management like CRL or bitstring based approaches, where each credential gets a unique url.

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.

However there are some requirements for the authorization attestation that should be fulfilled to ensure interoperability:

An attestation should be revocable or short lived to avoid long term authorization of the Relying Party.
The attestation should be bound to the Access Certificates of the Relying Party to ensure that the authorization is only valid for the specific certificate. A Wallet MUST NOT accept an authorization attestation that is not bound to the Access Certificate of the Relying Party if there is no other way to verify the ownership of the Authorization Attestation.

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.

SD-JWT VC¶

Using SD-JWT VC is recommended way since it allows an easy reference by the vct attribute in the credential metadata. Since the attestation is not key-bound and all attributes are visible, the Key-Binding JWT (KB-JWT) is not appended when sending the authorization attestation.

x5c: OPTIONAL, the chain of trust for the authorization attestation. The first entry should be the authority that issued the certificate.

typ: REQUIRED, should be set to dc+jwt-vc.

iss: REQUIRED, the unique identifier of the issuer of the Authorization Certificate, which should be the authority that issues the attribute based access control attestation.

sub: REQUIRED, the subject of the authorization attestation, which should be the distinguished name of the RP.

status: REQUIRED, reference to the status management, the token status list is used.

iat: REQUIRED, the time the authorization attestation was issued.

exp: OPTIONAL, the expiration time of the authorization attestation.

cnf: OPTIONAL, the confirmation method to bind an Authorization Certificate to a specific Access Certificate. The Certificate Thumbprint Confirmation Method is used to bind the authorization attestation to one Access Certificate. Since the access certificate is a X509 based one, this seems to be the only standardize way to bind it according to the published JWT conforming methods.

Here is a non-normative example of an authorization attestation:

{  
  "alg": "ES256",
  "typ": "dc+sd-jwt"
}
.
{
  "vct": "http://example.com/certified",
  "iss": "https://example.com/issuer",
  "sub": "CN=SPRIND GmbH, O=SPRIND GmbH, C=DE", //should be the distinguished name of the RP Access Certificate
  "iat": 1683000000,  
  "status": {
    "status_list": {
      "idx": 0,
      "uri": "https://example.com/statuslists/1"
    }
  },
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" //fingerprint to the RP access certificate    
  },
}

The following example shows a disclosure policy to request such an authorization attestation:

{
  "attribute_based_access_control":{
    "credentials":[
      {
        "id": "certified",
        "format": "dc+sd-jwt",
        "meta": {
          "vct_values": ["http://example.com/certified"]
        },
        "iss": "https://example.com/issuer"
      }
    ]
  }
}

This authorization attestation can be attached to the authorization request like:

{
   "attachments":[
    {
      "format": "eudi_registration_certificate",
      "data": "eyJ0eXAiOiJ...zLTQ1LTY3ODkiXQ~"
    },
  ]
}

Use Case Scenarios¶

Medical Credential Issuer Limits Access to Certified Pharmacies

A national health authority issues a Digital Prescription Credential to patients. To protect sensitive health data:

The issuer defines a disclosure policy that only RPs with a “Certified Pharmacy” authorization attestation issued by a designated agency can request the credential.
This policy is expressed using DCQL and linked via issuer metadata.
The Wallet enforces this policy before releasing the credential to any RP.

Result: Only certified pharmacies—regardless of country—can request the prescription credential.

Tax Authority Restricts Access to Financial Data Credentials

A government tax agency issues Income Statement Credentials to individuals. To restrict access:

The disclosure policy allows access only to RPs holding a “Tax Consultant License” credential, issued by a certified German authority.
The policy is dynamically enforced using attribute-based access control with DCQL.
A fintech company trying to access the credential must first obtain and present this authorization credential.

Result: Only regulated tax advisors can request financial credentials—no general fintech access.

Mobility Provider Credential Issuer Limits Requests to Public Authorities A European smart mobility provider issues Driver License Sharing Credentials for ride-sharing apps and traffic authorities. To avoid misuse:

The issuer defines a disclosure policy that only public sector RPs with a valid government-issued access credential can request the driver license data.
This includes police departments, city governments, or traffic courts, but not private insurers or marketers.

Result: Only vetted public authorities can request identity-linked mobility credentials.