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
Email Address	E	Email address of the entity (non-standard).	info@sprind.org
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 a JWT or CWT that includes the intended use of the RP. The JWS/CWT is signed by the RP Registrar. The typ value for the JWT must be rc-rp+jwt. The JWT has to be signed with the private key of the RP Registrar. It must not be included in the header since the registrars public key is published in the trusted list.

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

credentials and credentials_sets:

• These are structured according to the DCQL specification, ensuring compatibility with established standards for querying and presenting credentials.
• The Wallet will check if the credentials field, that is a list, of the VP request is equal or a subset of the credentials field of the passed Registration Certificate. The same is done for the credential_sets field. If one of these checks 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:

• Contact details specific for the intended use are included in the JWS, as they are not part of the authentication certificate. It is up to the registrar to verify the contact information during the creation process of the Registration Certificate.

sub:

• The sub field is required and should include the Distinguished Name (DN) of the RP Access Certificate.

service:

• A natural-language description of the type of services provided by the wallet-relying party. See multi language support chapter for more information about the structure.

public_body:

• Boolean indicating whether the wallet-relying party is a public sector body.

entitlements:

• The entitlement(s) of the wallet-relying party, represented as a list of strings.

privacy_policy:

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

iat:

• Defines the time the Registration Certificate was issued.

exp:

• Optional and can be used to define an expiration date for the certificate.

purpose:

• The purpose field is a text-based description of the intended use of the data, see multi language support chapter for more information about the structure.

status:

• A status management system is required for the RP Registrar to revoke an attestation when necessary.
• Revocation is performed by the RP Registrar. 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",
    "email": "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"
          ]
        }
      ]
    }    
  ],
  "credential_sets":[
    {  
      "options":[
        [
          "pid"
        ],
        [
          "other_pid"
        ]
      ]
    }
  ],
  "entitlements": [],
  "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"
    }
  }  
}

TODO: add an example for a COSE Signature.

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.

Credential Set Query

The credential set query from the presentation request must be equal to or a subset of the credential set query in the registration certificate. A subset means that the list of options in the credential set query of the presentation request must be equal to or a subset of the options defined 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"
          ]
        }        
      ]
    }    
  ],
  "credential_sets": [
    {  
      "options": [
        [
          "pid"
        ]
      ]
    }
  ]
}

• 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.
• The credential_sets field includes only the pid credential, which is a subset of those allowed by 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.