Relying Party Solution¶

A Relying Party, as an organizational entity relying upon IT-Wallet, provides technical Solutions (Relying Party Solution) that could combine software, hardware, services, settings, and configurations, including Relying Party Instances for User authentication and Digital Credential verification.

In order to implement and provide technical solutions, a Relying Party could take advantage of services provided by an Intermediary Entity. A Relying Party Intermediary is an Organization Entity that may act on behalf of the Relying Party offering services to it, making the Relying Party able to connect to Wallet Instance and authenticate Users and verify User’s Digital Credentials.

A Relying Party provides at least one of the following components:

Relying Party Backend: It handles Relying Party Instances registration and the relative Certificate management. It obtains X.509 Certificate according to the The Infrastructure of Trust. It SHOULD also provide a X.509 Certificate to its Relying Party Instances. It also may implement additional web services and business logic for its own purposes and use cases.

Relying Party Instance: It is a frontend provided to Users in order to access Relying Party Services, and it may be provided as:

Web Client.

Mobile Application.

The following diagram depicts the Relying Party Solution High Level Architecture.

The image illustrates the Relying Party Solution and its relations and interactions within the ecosystem. — Fig. 8 Relying Party Solution High Level Architecture¶

Relying Party Solution Requirements¶

This section lists the requirements to be met by Relying Parties and Relying Party Solutions.

The Relying Party MUST register with the Federation Authority to obtain both the Access Certificate and the Registration Certificate.
The Relying Party MUST implement secure mechanisms for handling and processing received Digital Credentials, ensuring the integrity and confidentiality of the Relying Party Solution.
The Relying Party MUST expose an endpoint for the erasure of personal attributes presented by Users whenever the attributes requested by the Relying Party include a unique identifier of the User (e.g. the "tax_id_code" claim of the PID).
The Relying Party Solution MUST implement proper revocation procedures for compromised or decommissioned instances.
The Relying Party Solution MUST maintain an audit trail of Credential verifications while respecting privacy requirements and data protection regulations.
The Relying Party Solution MUST allow Selective Disclosure mechanisms during presentation scenarios.
The Relying Party Backend MUST provide a RESTful set of services for registering Relying Party Instances and issuing Access Certificates.
The Relying Party Instance MUST periodically reestablish trust with the Relying Party through integrity checks and Certificate renewal procedures.
The Relying Party Instance MUST provide both a Registration Certificate and Access Certificate to Wallet Instances during their interaction to prove the legitimacy and authorization of its requests.
The Relying Party Instance MUST communicate to Users which attributes are requested and for what purpose during any Credential presentation flow.
The Mobile Relying Party Instances MUST be compatible and functional on both Android and iOS operating systems and available on the Play Store and App Store, respectively.
The Mobile Relying Party Instances MUST handle both online and offline presentation scenarios, with appropriate security measures and user notifications.

Relying Party Instance¶

The Relying Party Instance (RPI) is a mobile or embedded application designed to request, receive, and process Digital Credentials from Wallet Instances in a trusted manner. Each RPI ensures the integrity, confidentiality and authenticity of Credential exchanges, enabling secure interactions between Users and Relying Parties.

There are two primary types of Relying Party Instances, each serving different operational environments:

Embedded Relying Party Instance: an hardware/software solution running on a specialized device (e.g., turnstiles). Each instance corresponds to a specific installation of the application on an embedded device. Since the trust with the Embedded Relying Party Instance is established through the trust established with the Mobile Relying Party Provider, the Embedded Relying Party Instance can be considered a confidential client.
Mobile Relying Party Instance: a native application running on a mobile device (e.g., smartphone or tablet). Each instance corresponds to a specific installation of the application on a device. Since the trust with the Mobile Relying Party Instance is established through the trust established with the Mobile Relying Party Provider, the Mobile Relying Party Instance can be considered a confidential client.
Web Relying Party Instance: a remote application operated by the Relying Party. A Web Relying Party Instance operates as a confidential client, meaning it can securely store confidential configurations (such as its private cryptographic keys) on a remote server. In this context, the Relying Party is unprovisioned and the presentation request and validation is automatically handled by software.

Note

Mobile and Embedded Relying Party Instances acting as public clients are not considered within these specifications.

Note

Unlike the Web Relying Party Instance, a Mobile and Embedded Relying Party Instance requires proper lifecycle management and special registration procedures managed through the Relying Party Backend.

Further technical and operational details are discussed in the following sections.

Mobile Relying Party Instance¶

A Mobile Relying Party Instance's lifecycle includes four main states: Installed, Unverified, Verified, and Uninstalled, supporting functionalities such as registration, Access Certificate reissuance, and revocation.

Mobile Relying Party Instance Lifecycle¶

In this section, state machines are presented to explain the Mobile Relying Party Instance states, as well as their transitions and relations.

_images/RelyingParty_Instance_Mobile_Lifecycle.svg — Fig. 9 Lifecycle of the Mobile Relying Party Instance¶

As shown in Fig. 9, the Mobile Relying Party Instance has four distinct states: Installed, Unverified, Verified, and Uninstalled. Each state represents a specific functional status and determines the actions that can be performed.

Transition to Installed¶

The state machine begins with the Relying Party Instance installation (RPI INST transition), where Users download and install a Relying Party Instance using the official app store of their device's operating system, leading to the Installed state.

While in this state, the Relying Party Instance MUST interact only with the Relying Party Backend to be registered (i.e., to verify the Instance integrity, register Hardware Cryptographic Keys and obtain an Access Certificate).

When the revocation of the Relying Party Instance occurs (RPI REV transition), the Relying Party Instance MUST get back from Unverified to Installed. This transition implies the following operations:

The Access Certificate MUST be revoked.
The Hardware Cryptographic Keys MUST be deleted.

Revocation can occur in the following cases:

For security reasons (e.g., compromise of cryptographic material).
For technical reasons (e.g., deprecation of the Relying Party Solution).
In case of Relying Party de-registration (as detailed in EIDAS-ARF, Section 6.4.3).
Illegal activities reported by Judicial or Supervisory Bodies.

In addition, each Relying Party SHOULD set an amount of time (grace period) during which the Relying Party Instance can request presentations of Digital Credentials by authenticating itself towards a Wallet Instance using an expired Access Certificate. After this period, the Relying Party Instance MUST be de-registered (RPI DEREG transition) and go back to the Installed state. This transition implies that the Hardware Cryptographic Keys MUST be deleted.

Transition to Verified¶

The Relying Party Instance needs to obtain a proper Access Certificate, which will be used to authenticate itself towards Wallet Instances. This Certificate is obtained by interacting with the Relying Party Backend, which in turns communicates with the Relying Party Instance Access Certificate Authority. Specifically, the registration transition (RPI REG) consists of the following subphases, leading to the Verified state:

Initialization: After verification of the Relying Party Instance integrity, it registers a pair of Hardware Cryptographic Keys.
Access Certificate Issuance: The Relying Party Instance obtains an Access Certificate.

In case the Access Certificate is expired, a new Certificate can be issued to the Relying Party Instance; this operation is represented by the CERT REISS transition towards the Verified state.

While in this state, the Relying Party Instance can request the presentation of Digital Credentials to Wallet Instances (PID/(Q)EAA PRE), using the Access Certificate to authenticate itself.

Transition to Unverified¶

The expiration of the Access Certificate (CERT EXP transition) leads to the Unverified state.

While in this state, the Relying Party Instance can still request the presentation of Digital Credentials to Wallet Instances during the grace period. However, as the Certificate is expired, a specific disclaimer MUST be displayed to the User of the Wallet Instance during the presentation flow; for this reason, this operation is represented by the label PID/(Q)EAA PRE*. This is required to support offline presentation flows. After the grace period has passed, the Relying Party Instance MUST NOT longer request presentations and will be de-registered.

Transition to Uninstalled¶

Across the Installed, Verified and Unverified states, the Relying Party Instance can be removed entirely through the Relying Party Instance uninstall (RPI UNINST) transition, leading to the Uninstalled state. If a Relying Party Instance is Uninstalled, it ends its lifecycle.

Mobile Relying Party Instance Functionalities¶

A Mobile Relying Party Instance MUST support three fundamental functionalities: Registration, Access Certificate Reissuance, and Revocation. Each functionality is described in detail in the following sections.

Note

Throughout this section, the services used to attest genuineness of the Relying Party Instance and the device in which it is installed are referred to as Key Attestation API. The Key Attestation API is considered in an abstract fashion and it is assumed to be a service provided by a trusted third party (i.e., the OS Provider's API) which is able to perform integrity checks on the Wallet Instance as well as on the device where it is installed.

Note

The details provided below are non-normative and are intended to clarify the functionalities of the Mobile Relying Party Instance. The actual implementation may vary based on the specific use case and requirements of the Relying Party.

Mobile Relying Party Instance Registration¶

This process allows for the registration of a Relying Party Instance with the Relying Party Backend, and the issuance of an Access Certificate that will be used for authentication purposes towards Wallet Instances during presentation flows. The process consists of two subphases:

Initialization: The Relying Party Instance requests a security and integrity assertion from the OS manufacturer, which also binds a long-lived key pair stored in a proper secure storage within the device itself; the assertion is then validated by the Relying Party Backend. Further details are provided in the Mobile Application Instance Initialization section.
Access Certificate Issuance: The Relying Party Instance requests an Access Certificate from the Relying Party Backend. Before interacting with the Relying Party Instance Access Certificate Authority for the issuance of the Access Certificate, the Relying Party Backend validates the Relying Party Instance's integrity and security by leveraging the long-lived, attested keys generated in the previous subphase. The flow is displayed in Fig. 10, while a step-by-step description is provided below.

Note

Access Certificates MAY be issued as short-lived (typically valid within 24 hours) or long-lived.

_images/RelyingParty_Instance_Mobile_Registration_AccessCertificateIssuance.svg — Fig. 10 Flow of the Mobile Relying Party Instance Access Certificate Issuance¶

Steps 1-2: The Mobile Relying Party Instance:

Verifies the existence of Cryptographic Hardware Keys. If none exist, the Relying Party Instance re-initialization is required.

Generates an asymmetric key pair for the Access Certificate (key_pub, key_priv).

Steps 3-5: The Mobile Relying Party Instance requests a nonce from the Relying Party Nonce Endpoint of the Relying Party Backend. This nonce MUST be unpredictable to serve as the main defense against replay attacks.

Upon a successful request, the Relying Party Nonce Endpoint generates and returns the nonce to the Mobile Relying Party Instance. The Relying Party Nonce Endpoint MUST ensure that it is single-use and valid only within a specific time frame.

Non-normative examples of the Nonce Request and Response can be found in the Nonce Request and Nonce Request sections, respectively.

Step 6: The Mobile Relying Party Instance:

Generates client_data, a JSON object that includes the challenge and the thumbprint of key_pub, obtained from its JWK representation.

Computes client_data_hash by applying the SHA256 algorithm to client_data.

Below is a non-normative example of the client_data JSON object.

{
  "nonce": "f3b29a81-45c7-4d12-b8b5-e1f6c9327aef",
  "jwk_thumbprint": "hT3v7KQjFZy6GvDkYgOZ1u2F6T4Nz5bPjX8o1MZ3dJY"
}

Steps 7-8: The Mobile Relying Party Instance:

Requests the Key Attestation APIs to create a key_attestation value linked to the client_data_hash.

Receives a signed key_attestation value from the Key Attestation APIs, authenticated by the OEM.

Steps 9-11: The Mobile Relying Party Instance:

Generates an hardware_signature value by signing the client_data_hash with the Hardware Cryptographic private key, serving as a proof of possession for the Cryptographic Hardware Keys.

Generates the Relying Party Key Binding Request in the form of a JWT. This JWT includes key_attestation, hardware_signature, nonce, hardware_key_tag, and cnf (representing key_pub); it is signed using key_priv.

Sends the signed Relying Party Key Binding Request JWT as an assertion parameter in the body of an HTTP request to the Relying Party Key Binding Endpoint.

Step 12: The Relying Party Backend evaluates the Key Binding Request and performs the following checks:

The request includes all required HTTP header parameters as defined in Relying Party Key Binding Request.

The signature of the Key Binding Request is valid and verifiable using the provided jwk.

The nonce value has been generated by the Relying Party Backend and not previously used.

The Relying Party Instance has valid Cryptographic Hardware Keys registered.

The client_data can be reconstructed using nonce and cnf (representing key_pub). The hardware_signature parameter value is then validated using the registered Cryptographic Hardware Key's public key associated with the Relying Party Instance.

The key_attestation can be validated according to the device manufacturer's guidelines. The specific checks performed by the Relying Party Backend are detailed in the operating system manufacturer's documentation.

The device in use is free of known security flaws and meets the minimum security requirements defined by the Relying Party.

The URL in the iss parameter matches the Relying Party's URL identifier.

Step 13: If the checks are successful, the Relying Party Backend responds with a confirmation of success (Relying Party Key Binding Response).

Step 14: The Mobile Relying Party Instance generates a Certificate Signing Request (CSR, csr) using key_pub and key_priv.

Step 15: The Mobile Relying Party Instance sends the CSR to the Relying Party Access Certificate Endpoint of the Relying Party Backend, as part of the Relying Party Access Certificate Request.

Steps 16-17: The Relying Party Backend checks that the public key in the CSR corresponds to a Relying Party Instance that has been previously validated, i.e., that it matches the one bound to the Cryptographic Hardware Keys through hardware_signature. If this check is successful, the Relying Party Backend sends the CSR to the Relying Party Instance Access Certificate Authority.

Steps 18-19: The Relying Party Instance Access Certificate Authority signs the CSR, obtaining a valid Access Certificate (access_certificate) which it sends back to the Relying Party Backend.

Steps 20-21: The Relying Party Backend sends the Access Certificate (as part of the Relying Party Access Certificate Response) to the Mobile Relying Party Instance, which stores it for future authentication towards Wallet Instances.

Mobile Relying Party Instance Access Certificate Reissuance¶

The issuance of a new Access Certificate follows the same flow described in the Mobile Relying Party Instance Registration section for Access Certificate Issuance. Those certificates MAY be issued as short-lived (typically valid within 24 hours) or long-lived.

Mobile Relying Party Instance Revocation¶

Relying Parties MUST periodically verify the Relying Party Instance's authenticity and security. When security issues are detected, Relying Parties MUST revoke the Relying Party Instance, revoking its X.509 Access Certificate (in case of long-lived certificates), and in any case, Relying Parties MUST NOT allow the re-issue of certificates. As a result, Mobile Relying Party Instance revocation MUST be tied to X.509 Access Certificates validity.

Long-lived X.509 Certificates follows the requirements about their lifecycle, defined in The Infrastructure of Trust.

Web Relying Party Instance¶

Web Instances operates server-side security controls that safely store secrets and cryptographic keys in a controlled environment. Web Instances MUST be registered with the Trust Anchor or Intermediary Entities, according to The Infrastructure of Trust.

Web Relying Party Instance Functionalities¶

A Web Relying Party Instance MUST support two fundamental functionalities: Registration and Revocation. Each functionality is described in the following sections.

Web Relying Party Instance Registration¶

Web Relying Party Instances, as confidential clients, are registered directly with the Trust Anchor or an Intermediary Entity. The registration involves:

The Relying Party MUST register its Web Instance with the Trust Anchor or Intermediary.
The Relying Party MUST expose an Entity Configuration as defined in the Trust Framework.
The Entity Configuration MUST contain all necessary metadata for federation, including endpoints and public keys.
No individual instance lifecycle management is required, as the Web Instance operates as part of the secured server environment.

Web Relying Party Instance Revocation¶

When a Web Relying Party Instance needs to be revoked:

The revocation MUST be performed according to the Trust Framework procedures.
The cryptographic keys used by the Web Instance MUST be revoked.
The Entity Configuration MUST be updated to reflect the revocation.
The Trust Anchor MUST be notified of the revocation to update federation metadata.

Relying Party Endpoints¶

The Relying Party MUST expose a trust endpoint adhering to the OpenID Federation 1.0 Wallet Architecture specification, facilitating the Relying Party's identity and metadata distribution. In addition, in case the Relying Party supports proximity presentation, it MUST expose a set of endpoints for handling the lifecycle of Relying Party Instances (e.g., by providing nonce generation, hardware key registration, integrity validation, and Access Certificate issuance); their specific implementation details are left to the Relying Party's discretion.

Relying Party Federation Endpoint¶

Entity Configuration of Relying Parties¶

According to Section Configuration of the Federation, as a Federation Entity, the Relying Party is required to maintain a well-known endpoint that hosts its Entity Configuration. The Entity Configuration of Relying Parties MUST contain the parameters defined in the Sections Entity Configuration Leaves and Intermediates and Entity Configurations Common Parameters.

The Relying Parties MUST provide the following metadata types:

federation_entity

openid_credential_verifier

The federation_entity metadata MUST contain the claims as defined in Section Metadata of federation_entity Leaves.

Metadata for openid_credential_verifier¶

The openid_credential_verifier metadata MUST contain the following parameters.

Claim	Description
client_id	It MUST contain an HTTPS URL that uniquely identifies the RP. See RFC 7591#section-3.2.1 and OpenID Connect Dynamic Client Registration 1.0 Section 3.2.
client_name	Human-readable string name of the RP. See RFC 7591#section-2.
application_type	String indicating the type of application. It MUST be set to "web" value. See OpenID Connect Dynamic Client Registration 1.0 Section 2.
request_uris	JSON Array of request_uri values that are pre-registered by the RP. These URLs MUST use the https scheme. See OpenID Connect Dynamic Client Registration 1.0 Section 2.
response_uris	JSON Array of response URI strings to which the Wallet Instance MUST send the Authorization Response using an HTTP POST request as defined by the Response Mode `direct_post` and `direct_post.jwt` (see OpenID4VP Draft 20 Sections 6.2 and 6.3).
authorization_signed_response_alg	String representing the signing [RFC 7515] alg algorithm that MUST be used for signing authorization responses. The algorithm "none" MUST NOT be used. See JARM.
authorization_encrypted_response_alg	Algorithm used to encrypt the authorization response. It specifies to the Wallet Instance the asymmetric encryption algorithm. See JARM.
authorization_encrypted_response_enc	Encryption algorithm used for the authorization response. It specifies to the Wallet Instance the symmetric encryption algorithm. See JARM.
vp_formats	JSON object defining the formats and proof types of Verifiable Presentations and Verifiable Credentials the RP supports. It consists of a list of name/value pairs, where each name uniquely identifies a supported type. The RP MUST support at least "dc+sd-jwt". The value associated with each name/value pair MUST be a JSON object "sd-jwt_alg_values" that MUST contain a JSON array containing identifiers of cryptographic algorithms the RP supports for protection of a SD-JWT. The alg JOSE header (as defined in RFC 7515) of the presented SD-JWT MUST match one of the array values. See also OpenID4VP Draft 20 Section 9.1.
jwks	JSON Web Key Set document, passed by value, containing the protocol specific keys for the Relying Party. See JARM Section 3, OID-FED Draft 41 Section 5.2.1 and JWK.
erasure_endpoint	[CONDITIONAL] JSON String that represents the URI to which the Wallet Instance can request deletion of Users’ attributes. This URL MUST use the https scheme. This endpoint MUST be present whenever the Relying Parties requested attributes that can uniquely identify Users such as the tax_id_code claim of the PID.

Note

The parameters response_uris and erasure_endpoint are introduced in this specification.

Example of a Relying Party Entity Configuration¶

Below a non-normative example of the request made by the Wallet Instance to the openid-federation well-known endpoint to obtain the Relying Party Entity Configuration:

GET /.well-known/openid-federation HTTP/1.1
HOST: relying-party.example.org

Below is a non-normative response example:

{
    "iat": 1718207217,
    "exp": 1749743216,
    "iss": "https://relying-party.example.org",
    "sub": "https://relying-party.example.org",
    "authority_hints": [
        "https://trust-anchor.example.org"
    ],
    "jwks": {
        "keys": [
            {
                "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
                "kty": "EC",
                "crv": "P-256",
                "x": "jE2RpcQbFQxKpMqehahgZv6smmXD0i/LTP2QRzMADk4",
                "y": "qkMx5iqt5PhPu5tfctS6HsP+FmLgrxfrzUV2GwMQuh8"
            }
        ]
    },
    "metadata": {
        "federation_entity": {
            "homepage_uri": "https://relying-party.example.org",
            "organization_name": "Organization Name",
            "contacts": [
                "informazioni@example.it",
                "protocollo@pec.example.it"
            ],
            "tos_uri": "https://relying-party.example.org/public/info_policy.html",
            "policy_uri": "https://relying-party.example.org/public/privacy_policy.html",
            "logo_uri": "https://relying-party.example.org/public/logo.svg"
        },
        "openid_credential_verifier": {
            "application_type": "web",
            "client_id": "https://relying-party.example.org",
            "client_name": "Organization Name",
            "contacts": [
                "informazioni@example.it",
                "protocollo@pec.example.it"
            ],
            "request_uris": [
                "https://relying-party.example.org/request_uri"
            ],
            "response_uris": [
                "https://relying-party.example.org/response_uri"
            ],
            "redirect_uris": [
                "https://relying-party.example.org/cb"
            ],
            "authorization_signed_response_alg": "ES256",
            "vp_formats": {
                "dc+sd-jwt": {
                    "sd-jwt_alg_values": [
                        "ES256",
                        "ES384",
                        "ES512"
                    ]
                }
            },
            "jwks": {
                "keys": [
                    {
                        "kid": "f10aca0992694b3581f6f699bfc8a2c6cc687725",
                        "kty": "EC",
                        "crv": "P-256",
                        "x": "jE2RpcQbFQxKpMqehahgZv6smmXD0i/LTP2QRzMADk4",
                        "y": "qkMx5iqt5PhPu5tfctS6HsP+FmLgrxfrzUV2GwMQuh8"
                    }
                ]
            }
        }
    }
}

Relying Party Nonce Endpoint¶

The Relying Party Nonce Endpoint allows the Relying Party Instance to request a cryptographic nonce from the Relying Party Backend. The nonce serves as an unpredictable, single-use challenge to ensure freshness and prevent replay attacks.

Further details on the Nonce Request and Response are provided in the Mobile Application Nonce Request and Mobile Application Nonce Response sections, respectively.

Relying Party Instance Initialization Endpoint¶

The Relying Party Instance Initialization Endpoint allows for the initialization of Relying Party Instances, consisting in the registration of a pair of long-lived, securely stored Cryptographic Hardware Keys.

Further details on the Relying Party Instance Initialization Request and Response are provided in the Mobile Application Instance Initialization Request and Mobile Application Instance Initialization Response sections, respectively.

Relying Party Key Binding Endpoint¶

The Relying Party Key Binding Endpoint enables Relying Party Instances to bind the newly created pair of keys, which will be associated with an Access Certificate, to the Relying Party Instance, by relying on a proof of possession of the Cryptographic Hardware Keys generated during the Mobile Application Instance Initialization phase. Before completing the process, the Relying Party Backend also needs to verify the integrity of the Relying Party Instance.

Relying Party Key Binding Request¶

Further details on the Relying Party Key Binding Request are provided in the Mobile Application Key Binding Request section.

The typ header of the Integrity Request JWT assumes the value rp-kb+jwt.

Relying Party Key Binding Response¶

Upon a successful request, the Relying Party Backend provides an HTTP Response with a 204 No Content status code.

Below is a non-normative example of a Key Binding Request Response.

HTTP/1.1 204 No content

If any errors occur during the process, an error response is returned. Further details on the error response are provided in the Mobile Application Key Binding Error Response section.

Relying Party Access Certificate Endpoint¶

The Relying Party Access Certificate Endpoint enables Relying Party Instances to obtain an Access Certificate.

Relying Party Access Certificate Request¶

The Access Certificate Request uses the HTTP POST method with Content-Type set to application/json.

The request includes the following body parameter:

Parameter	Description	Reference
csr	The CSR generated by the Relying Party Instance, encoded in the `base64url` format as defined in RFC 2511.

Below is a non-normative example of an Access Certificate Request.

POST /access-certificate HTTP/1.1
Host: relying-party.example.org
Content-Type: application/json

{
  "csr": "MIIBvzCCAa..."
}

Relying Party Access Certificate Response¶

Upon a successful request, the Relying Party Access Certificate Endpoint provides an HTTP Response with a 200 OK status code and the Access Certificate. The Access Certificate Response, which uses application/json as the Content-Type, includes the following body parameters:

Parameter	Description	Reference
access_certificate	The Access Certificate generated by the CSR.	This specification.

Below is a non-normative example of an Access Certificate Response.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_certificate": "hajdnhaghSDGns..."
}

If any errors occur, the Relying Party Access Certificate Endpoint returns an error response. The response uses application/json as the content type and includes the following parameters:

error. The error code.

error_description. Text in human-readable form providing further details to clarify the nature of the error encountered.

Below is a non-normative example of an Access Certificate Error Response.

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
    "error": "invalid_request",
    "error_description": "The public key in the CSR is different from the one associated with the Cryptographic Hardware Keys."
}

The following table lists HTTP Status Codes and related error codes that MUST be supported for the error response, unless otherwise specified:

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters (e.g., header parameters or integrity assertion), or includes invalid and unknown parameters.
`403 Forbidden`	`invalid_request`	The public key in the CSR does not match the public key associated with the Cryptographic Hardware Keys.
`500 Internal Server Error`	`server_error`	The request cannot be fulfilled because the Endpoint encountered an internal problem.
`503 Service Unavailable`	`temporarily_unavailable`	The request cannot be fulfilled because the Endpoint is temporarily unavailable (e.g., due to maintenance or overload).

Relying Party Erasure Endpoint¶

The Erasure Endpoint, which is described in Metadata for openid_credential_verifier, allows Wallet Instances to request deletion of attributes presented to the Relying Party. It MUST be authenticated, i.e., the Relying Party MUST request User authentication before proceeding with the attribute deletion.

Erasure Request¶

The Erasure Request MUST be a GET request to the Erasure Endpoint. The Wallet Instance MUST also support a call back mechanism which enables the User-Agent to notify the Wallet Instance (and thus the User) once the Erasure Response is returned.

Below is a non-normative example of an Erasure Request where the call back URL is passed as a query parameter.

GET /erasure-endpoint?callback_url=https://wallet-instance/erasure_response HTTP/1.1
Host: relying-party.example.org

Erasure Response¶

If the deletion of all attributes bound to the User have been successful, the Erasure Response MUST return a 204 HTTP status code.

If instead the attributes deletion procedure fails due any circumstances, the Relying Party MUST return an error response with application/json as the content type and MUST include the following parameters:

error: The error code.

error_description: Text in human-readable form providing further details to clarify the nature of the error encountered.

The following table lists the HTTP Status Codes and related error codes that MUST be supported for the error response:

Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters (e.g., header parameters or integrity assertion), or includes invalid and unknown parameters.
`401 Unauthorized`	`unauthorized`	The request could not be carried fulfilled due to invalid authentication by the User.
`500 Internal Server Error`	`server_error`	The request cannot be fulfilled because the Erasure Endpoint encountered an internal problem. (RFC 6749#section-4.1.2.1).
`503 Service Unavailable`	`temporarily_unavailable`	The request cannot be fulfilled because the Erasure Endpoint is temporarily unavailable (e.g., due to maintenance or overload). (RFC 6749#section-4.1.2.1).

The following is an example of an error response from Erasure Endpoint:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
 "error": "server_error",
 "error_description": "The request cannot be fulfilled due to an internal server error."
}

Upon receiving an error response, the Wallet Instance which made the Erasure Request MUST inform the User of the error condition in an appropriate manner.