Wallet-Relying Party Authentication

This document outlines a proposed solution for implementing the Wallet-Relying Party (RP) authentication requirements from IA 5b.

Motivation

Aligned with the eIDAS 2 regulation and the Implementing Acts, the proposed solution enables straightforward onboarding of Relying Parties (RPs) and provides users with automated validation of the intended use of their data by the Wallet. Rather than relying on the Authorization Certificate (Berechtigungszertifikat) used in Germany’s eID system for RP authentication and authorization, this approach introduces a more flexible model.

The authentication requirements for RPs interacting with the European Digital Identity Wallet (EUDI Wallet) are derived from Article 5b of the eIDAS 2 regulation. The following steps outline the process:

• RP Registration: RPs must register in their respective EU member state in both human- and machine-readable formats, providing:
  • Essential details (name, identifiers from other registers, registration number).
  • Specification of the data they intend to request from EUDI Wallets.
• Authentication with the EUDI Wallet: Authentication with the EUDI Wallet: Before interacting with the RP, EUDI Wallet needs to authenticate the RP. Authentication fails if the trust chain cannot be successfully verified and the EUDIW aborts the process.
• Validation of Data Requests: The EUDI Wallet ensures that RP presentation requests align with their declared intended use. Machine-readable formats play a central role in enabling automated validation while ensuring transparency for the users, consolidating both clarity and trust in data usage processes. EUDIW fails the process if the request exceeds the declared intended use and aborts the presentation process.

When the RP is using a hosted "Verifier as a Service" solution, presented certificates (Access Certificate and Registration Certificates) have to belong to the RP and not the one of the service provider. The RP has to make it clear who is the provider it is using, for example, by mentioning it in its privacy policy.

Trust Architecture

The proposed trust architecture involves a Trusted List, Wallet-Relying Party Registrar (RPR), and Wallet-Relying Party (RP) based on the following principles:

• Direct Authentication: RPs include certificates and attestations directly in their requests to the EUDI Wallet, supporting both online and offline interactions while reducing Wallet's communication with Registrars. This avoids potential tracking of Wallet's interactions by the Registrars.
• Separation of Attestations:
  • Identification data and intended use are managed as separate certificates (Access Certificate and Registration Certificate).
  • RPs can include only the attestations relevant to the requested data in each presentation request.
  • All attestations are publicly accessible via the registrar for review by the third parties.
• Machine processable intended use:
  • Wallets are able to match the intended use with the presentation request.
  • RPs are able to update their intended uses, but the request must never exceed the set of registered data.

International interoperability

The format of the following certificates and how to include them in the presentation request need to be aligned across the EU to ensure interoperability among the Wallets and the RPs:

• Access Certificate
• Registration Certificate

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

• RP Registrar onboarding
• Interaction with the RP Registrar

Out of Scope

The onboarding of a natural and legal persons of each kind are out of scope for this document. For interoperability between the member states, the onboarding to the registrars can be unique and must not align with each other, but the access certificates and intended use proofs have to.

Registrar

Registration

To interact with an EUDI Wallet in any role (issuer, verifier, etc.), the RP has to register at the RPR to receive the required certificates. The exact process of the onboarding of a RP is not defined yet since there are multiple ways that need to be defined by a policy first.

Authentication management

To request data or receive credentials, the RP must first authenticate with the EUDI Wallet so the user knows with whom they are interacting.

The process of receiving an Access Certificate can be automated on the RPR side since the identification of the RP is done during the onboarding process. This allows the RP without any delay to receive new certificates for key rotation or adding new services.

The revocation of an access certificate by the RP can be done any time without a delay to reduce the risk of a data breach. The revocation of an access certificate can not be undone.

Step by Step:

1. RP sends request to the RPR
   • request includes only the public key of the RP
   • includes authentication data like bearer token from previous login step
2. RPR evaluates the request, creates an Access Certificate and publishes it
   • a status management is added
   • identity data from from the internal database is added
3. RPR sends the Access Certificate to the RP
   • RP can use it in all requests to the Wallet

Intended use management

When an RP intends to request user data, the intended use must be registered in advance. This intended use is structured according to a defined schema, utilizing the Dynamic Credential Query Language, enabling the Wallet to process the request. The RPR does not verify whether the RP is authorized to request the data. The concept of specifying the intended use for processing personal data is comparable to the existing privacy policies commonly in use today.

Step by Step:

1. RP creates an intended use
2. RP sends request to the RPR
3. RPR evaluates the request, creates a Registration Certificate and publishes it
   • a status management is added
   • the subject is linked to the RP Access Certificate distinguished name
4. RPR sends the Registration Certificate to the RP
   • it will allow the RP to attach it in a presentation request without pointing to an endpoint, risking privacy (RPR would see which Wallet is requesting which RP's intended use)

Access Certificate

The RP Access Certificate is a x509 certificate based on the RFC 5280, including the relevant attributes to identity a RP. It must just include the values for authentication, not the entitlements or the intended use.

A RP is able to request multiple Access Certificates from the RPR and use them in parallel. A RP can request the revocation of any of its certificates at any time through the RPR's API. While this approach increases the complexity for the RPR, it simplifies processes on the EUDI Wallet side, as the validation of the trust chain and the mapping of the intended use remain consistent. It also helps with the compliance since the Access Certificates need to be available via the registrar for ten years, even after the RP shut down its business.

Subject: the distinguished name (DN) of the RP, including the following fields. In case the RP is a legal person, the CN should be the name of the legal person and the O field needs to be present. In case the RP is a natural person, the CN should be the name of the natural person and the GNand SN should be present. The list of fields only includes the already defined fields that have an OID.

Attribute	Abbreviation	Description	Example Value
Common Name	CN	Identifies the entity (e.g., person, company).	SPRIND GmbH, Erika Mustermann
Organization	O	The name of the organization.	SPRIND GmbH
Country	C	The ISO 3166-1 two-letter country code.	DE
Given Name	GN	First name of the individual (optional).	Erika
Surname	SN	Last name or family name (optional).	Mustermann

Issuer: the distinguished name of the RP Registrar, including the following fields:

Attribute	Abbreviation	Description	Example Value
Common Name	CN	Identifies the registrar	bundesnetzagentur
Country	C	The ISO 3166-1 two-letter country code.	DE

Certificate Policies: the RP access certificate must include the policy of the RP Registrar.

Validity: the notBefore and notAfter fields define the certificate’s validity period.

Status Management: the RP Registrar must maintain a certificate revocation list to revoke the RP access certificate when necessary. The revocation list should be accessible via a URL. To protect the users privacy, OCSP should not be used. The privacy preserving approach with OCSP stapling can not be used since it was designed to be used with TLS, but the transport protocols of the EUDI Wallet do not all depend on TLS.

Key Usage: to be discussed if required.

Official identifiers: where applicable, the RP's identifiers from official records should be included like

• an Economic Operators Registration and Identification (EORI) number as referred to in Commission Implementing Regulation (EU) No 1352/2013 ;
• the registration number as registered in a national business register;
• a Legal Entity Identifier (LEI) as referred to in Commission Implementing Regulation (EU) No 2022/1860 ;
• a VAT registration number;
• an excise number as specified in Article 2(12) of Council Regulation (EC) No 389/2012 ;
• a tax reference number;
• a European Unique Identifier (EUID) as referred to in Commission Implementing Regulation (EU) 2020/2244.

The semantic of the table below is based on ETSI EN 319 412-1 V1.5.1

Attribute	Abbreviation	Description	Format	Example Value
Economic Operators Registration and Identification (EORI) Number	organizationIdentifier	Unique identifier for economic operators in the EU.	EORI<CountryCode>-<Identifier>	EORIDE-1234567890
National Business Register Number	organizationIdentifier	Identifier from a national trade register.	NTR<CountryCode>-<Identifier>	NTRDE-HRB123456
Legal Entity Identifier (LEI)	organizationIdentifier	Global identifier based on ISO 17442.	LEIXG-<Identifier>	LEIXG-529900T8BM49AURSDO55
VAT Registration Number	organizationIdentifier	Identification based on a national VAT number.	VAT<CountryCode>-<Identifier>	VATDE-123456789
Excise Number	organizationIdentifier	Identifier for excise duty purposes.	<CountryCode>:EX-<Identifier>	DE:EX-987654321
Tax Reference Number	organizationIdentifier	National tax reference number.	<CountryCode>:TX-<Identifier>	DE:TX-123456789
European Unique Identifier (EUID)	organizationIdentifier	Business register number compliant with EUID format.	EI<CountryCode>-<Identifier>	EI:SE-5567971433

Registration Certificate

The Registration Certificate is an attestation issued by the WRP-Registrar that includes the registered information. It allows the WRP to provide this certificate directly to the Wallet during interactions, preventing the Wallet from disclosing sensitive data to the Registrar. The certificate is formatted as a JWT or CWT and must be signed using the WRP-Registrar's private key.

Depending on the role the WRP is acting, either as issuer or verifier, specific values are required in the Registration Certificate.

The header of the JWT/CWT MUST include the following fields:

• typ: REQUIRED: The type of the JWT/CWT. The value MUST be rc-rp+jwt.
• alg: REQUIRED: The algorithm used to sign the JWT/CWT. The RP Registrar must use a secure algorithm, such as ES256.
• x5u: REQUIRED: The URL of the RP Registrar's public key. This field is used to verify the signature of the JWT/CWT. The RP Registrar must provide a mechanism for the Wallet to retrieve its public key.
• x5t#s256: REQUIRED: The SHA-256 thumbprint of the RP Registrar's public key.

The payload of the JWT/CWT MUST include the following fields:

• credentials: OPTIONAL: a set of credential queries, ensuring compatibility with established standards for querying and presenting credentials. This field is REQUIRED when the Registration Certificate is used during the presentation request to fetch credentials from the Wallet. The Wallet will check if the provided set is equal or a subset of credential queries passed passed in presentation request, more information in the validating over asking chapter. If the check fails, the Wallet will inform the user about the failure. The user can then decide if they want to continue with the presentation request or not.

• contact: REQUIRED: Contact information of the RP, including the following fields:

  • website: URL of the RP's website.
  • e-mail: Email address of the RP.
  • phone: Phone number of the RP.

• sub: REQUIRED: The subject of the JWT/CWT, which identifies the RP. The value MUST be the distinguished name (DN) of the RP. The DN is a string that uniquely identifies the RP in the X.500 directory.

• service: REQUIRED: A list of objects describing the services provided by the wallet-relying party. Each object contains a lang and name field. The lang field is a string that identifies the language of this object, while the name field is a string that describes the service. The structure of the service field is defined in the multi language support chapter.

• public_body: OPTIONAL: A boolean indicating whether the wallet-relying party is a public sector body. The value MUST be true or false. This field is used to determine if the RP is a public body, which may have different requirements and responsibilities under the eIDAS regulation. If no value is provided, the default value is false.

• entitlements: REQUIRED: A list of entitlements of the WRP that are not defined yet.

• provided_attestations: OPTIONAL: a set of credentials that are issued by the wallet relying party with the entitlement of an EAA provider. When the WRP is issuing credentials, this field is REQUIRED. Each object contains the following fields:

  • format: REQUIRED: The format of the sub entitlement.
  • meta: REQUIRED: The metadata to identify the credential type based on the format. More information are defined in OID4VP Appendix B.

• privacy_policy: REQUIRED: A URL linking to the RP’s privacy policy, providing users with additional information about data processing and storage.

• iat: REQUIRED: The issued at time of the JWT/CWT, represented as a Unix timestamp (seconds since epoch). This field indicates when the JWT/CWT was issued and can be used to determine its validity period.

• exp: OPTIONAL: The expiration time of the JWT/CWT, represented as a Unix timestamp (seconds since epoch). This field indicates when the JWT/CWT will expire and can no longer be used. The expiration time is optional, but it is recommended to include it to ensure that the JWT/CWT is not used after a certain period.

• purpose: OPTIONAL: A list of objects describing the purpose of the Registration Certificate. Each object contains a lang and name field. This field is REQUIRED when the WRP want to request a credential from the Wallet. The lang field is a string that identifies the language of this object, while the name field is a string that describes the purpose. The structure of the purpose field is defined in the multi language support chapter.

• status: REQUIRED: A status management system is required for the RP Registrar to revoke an attestation when necessary. It may also be triggered by the RP’s request or by a third party if the Registration Certificate becomes invalid.

This structure supports granular, auditable, and privacy-preserving handling of credentials and intended use, aligned with DCQL standards and practical requirements for transparency and governance.

Here is a decoded example of the Registration Certificate:

{
    "typ": "rc-rp+jwt",
}
.
{  
  "purpose": [
    {
      "lang": "en-US",
      "name": "Required for checking the minimum age"
    },
    {
      "lang": "de-DE",
      "name": "Benötigt für die Überprüfung des Mindestalters"
    }
  ],
  "contact": {
    "website": "https://example.com/contact",
    "e-mail": "privacy@sprind.org",
    "phone": 1234566789,
  },
  "sub": "CN=SPRIND GmbH, C=DE", //the distinguished name of the RP
  "privacy_policy": "https://sprind.org/en/privacy-policy",
  "iat": 1683000000,
  "credentials":[
    {
      "id":"pid",
      "format":"dc+sd-jwt",
      "meta":{
        "vct_values":[
          "https://credentials.example.com/identity_credential"
        ]
      },
      "claims":[
        {
          "path":[
            "given_name"
          ]
        },
        {
          "path":[
            "family_name"
          ]
        },
        {
          "path":[
            "address",
            "street_address"
          ]         
        }
      ]
    },
    {
      "id":"other_pid",
      "format":"dc+sd-jwt",
      "meta":{
        "vct_values":[
          "https://othercredentials.example/pid"
        ]
      },          
      "claims":[
        {
          "path":[
            "given_name"
          ]
        },
        {
          "path":[
            "family_name"
          ]
        },
        {
          "path":[
            "address",
            "street_address"
          ]
        }
      ]
    }    
  ],  
  "entitlements": [
    "http://data.europa.eu/eudi/entitlement/Service_Provider",
  ],
  "provided_attestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.example.com/employee_credential"
        ]
      }
    }
  ],
  "public_body": false,
  "service": [
    {
      "lang": "en-US",
      "name": "Required for checking the minimum age"
    },
    {
      "lang": "de-DE",
      "name": "Benötigt für die Überprüfung des Mindestalters"
    }
  ],
  "status": {
    "status_list": {
      "idx": 0,
      "uri": "https://example.com/statuslists/1"
    }
  }  
}

Multi-language Support

To support multiple languages, the purpose and service field in the Registration Certificate MUST be a list of objects. Based on the user's language preferences, the appropriate entry should be selected and displayed. If the user's configured language is not in the list, it is up to the Wallet to decide which entry to use.

The structure of the purpose and service fields is as follows:

[
  {
    "lang": "en-US",
    "name": "Required for checking the minimum age"
  },
  {
    "lang": "de-DE",
    "name": "Benötigt für die Überprüfung des Mindestalters"
  }
]

• lang: REQUIRED — A string that identifies the language of this object. It MUST follow the BCP47 language tag format defined in RFC5646.
  Multiple display objects MAY be included for different languages. There MUST be only one object for each language identifier.
• name: REQUIRED — A string that describes the purpose or service.

Over asking Validation

When the Wallet receives a presentation request, it must use the provided Registration Certificate to verify that the request does not exceed the registered intended use (“over asking”). If the certificate is missing, expired, or revoked, the Wallet must treat the request as invalid and inform the user. The order of elements in lists is irrelevant. If any check fails, the Wallet should notify the user of the over asking with detailed information, allowing them to choose whether to proceed with or cancel the presentation.

Credential Query

The credential query from the presentation request must be equal to or a subset of the credential query in the Registration Certificate. A subset is defined as follows: the list of Claims Queries must be equal to or a subset of the claims listed in the Registration Certificate.

Based on the Registration Certificate above, the following DCQL in a presentation request would be valid:

{  
  "credentials": [
    {
      "id": "pid",
      "format": "vc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.example.com/identity_credential"
        ]
      },
      "claims": [
        {
          "path": [
            "given_name"
          ]
        },
        {
          "path": [
            "family_name"
          ]
        }        
      ]
    }    
  ] 
}

• The credentials field only includes the pid credential, which is a subset of the credentials listed in the Registration Certificate.
• The claims requested for the pid credential are only given_name and family_name, which are a subset of the claims in the registration certificate.

Intermediaries

The Wallet-Relying Party can interact with the Wallet through an intermediary. This intermediary handles tasks such as issuing credentials into the Wallet or requesting data from it. To do so, it uses its own Access Certificate along with the Registration Certificate, which is bound to both the Intermediary and the Relying Party:

• sub: REQUIRED. Distinguished name of the RP
• act: REQUIRED. Includes the distinguished name of the intermediary based on RFC 8693 in the sub field.

{
  "sub": "CN=SPRIND GmbH, C=DE",
  "act":  {
    "sub": "CN=Intermediary GmbH, C=DE"
  }
}

The Relying Party (Sprind) has to be registered at the RP Registrar, but does not need an own Access Certificate. The values from the distinguished name are registered during the onboarding process.

In case the act parameter is present, the Wallet needs to check if the value of the act field is matching with the distinguished name of the Access Certificate that is used in the presentation request. If the act is not present, the sub field has to be used.

Registrar Requirements

While the Implementing Acts do not require RP registrars to have standardized APIs, the following set of Relying Party Registrar Requirements would benefit all participants by ensuring consistent access to information.

• Reading information from the RP Registrar should be free of charge.
• Security measures like rate limiting should be implemented to prevent attacks.
• An OpenAPI-based API and a website with a question form should be available for reading information from the registrar.
• Users must be able to retrieve RP details based on the name or other identifiers.
• Revoked certificates, whether they are access or Registration Certificates, must be included in the response from the Registrar.
  • Clear guidelines must define situations where invalid content needs to be removed. For example, certificates containing personal data can be considered invalid. They should be entirely removed and not just be marked as deleted.
• Each certificate entry must include the issuance, expiration, and revocation timestamps in the response.
• Authentication to the Registrar should follow the OAuth 2.0 standard.

Intermediaries handling

When an intermediary wants to issue a Registration Certificate on behalf of a RP, it needs some kind of proof that the RP has authorized the intermediary to register new certificates for the RP. The type of proof is of out of scope of this document and should be defined by the policy of the RP Registrar. The Registration Certificates need to be revoked when either the Access Certificate of the Intermediary or the RP is revoked.