13.1. Wallet Provider Endpoints¶

The Wallet Provider, responsible for delivering a Wallet Solution, MUST expose the endpoints to support trust establishment and essential Wallet Instance functionalities. These include the /.well-known/openid-federation Federation Endpoint which MUST adhere to the OpenID Federation 1.0 specification to reliably establish trust with the Wallet Provider's as well as, endpoints for Wallet Instance registration, nonce generation (required for registration), attestation issuance, and revocation. Aside from the Federation endpoint, the implementation details of the others are left to the Wallet Provider's discretion.

Note

Tests related to the use of Wallet Provider endpoints are defined in Wallet Provider Test Matrix, particularly Test Cases for Wallet Provider Backend, Test Cases for Wallet Instance, and Optional Test Cases for Wallet Instance.

13.1.1. Federation Endpoint¶

The /.well-known/openid-federation endpoint serves as the discovery mechanism for trust establishment by retrieving the Wallet Provider Entity Configuration.

See Section Wallet Provider Entity Configuration for technical details (WP_001–004).

13.1.2. Wallet Solution Nonce Endpoint¶

This is a RESTful API endpoint that allows the Wallet Instance to request a cryptographic nonce from the Wallet Provider. The nonce serves as an unpredictable, single-use challenge to ensure freshness and prevent replay attacks.

See Mobile Application Nonce Request and Mobile Application Nonce Response for details on the Nonce Request and Nonce Response (WP_131).

13.1.3. Wallet Instance Management Endpoint¶

This is a RESTful API endpoint provided by the Wallet Provider that enables Wallet Instance management, including registration, status retrieval, revocation upon request (e.g., by the User), and deletion. The following sections describe the registration, status retrieval and revocation requests, along with their corresponding responses, handled by this endpoint, which are required for core Wallet Instance Functionalities.

13.1.3.1. Wallet Instance Registration Request¶

To register a Wallet Instance, the request to the Wallet Provider MUST use the HTTP POST method with Content-Type set to application/json. The request body MUST contain the claims described in Mobile Application Instance Initialization Request (WP_131–134).

13.1.3.2. Wallet Instance Registration Response¶

If a Wallet Instance Registration Request is successfully validated, the Wallet Provider provides an HTTP Response with status code 204 (No Content). For detatails see Mobile Application Instance Initialization Response (WP_135–137).

13.1.3.3. Wallet Instance Retrieval Request¶

To retrieve all Wallet Instances associated with a User, a request MUST be sent using the HTTP GET method to the Wallet Provider (WP_145).

Note

For retrieving a specific Wallet Instance, the request MUST include the Wallet Instance ID as a path parameter.

13.1.3.4. Wallet Instance Retrieval Response¶

If a Wallet Instance Retrieval Request is successfully processed, the Wallet Provider MUST return an HTTP Response with a 200 (OK) status code. The response body MUST be in JSON format and include the relevant Wallet Instance information, such as its unique ID, status, and issuance date. When retrieving all Wallet Instances, the response MUST return an array containing the details of all associated instances (WP_146).

If any errors occur during the retrieval process, an error response MUST be returned. Refer to Error Handling for Wallet Instance Management for details on error codes and descriptions.

Below is a non-normative example of an error response:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "forbidden",
  "error_description": "User is not authorized to retrieve Wallet Instances."
}

13.1.3.5. Wallet Instance Revocation Request¶

To revoke an active Wallet Instance, a revocation request MUST be sent using the HTTP PATCH method with Content-Type set to application/json. The request body MUST contain a status parameter set to REVOKED (WP_147).

Note

While PATCH is the recommended method, the revocation request MAY also be sent using the POST method, depending on implementation preferences.

13.1.3.6. Wallet Instance Revocation Response¶

If a Wallet Instance Revocation Request is successfully processed, the Wallet Provider provides an HTTP Response with a 204 (No Content) status code (WP_148).

If any errors occur during the Wallet Instance Revocation, an error response MUST be returned. Refer to Error Handling for Wallet Instance Management for details on error codes and descriptions (WP_035–039, WP_043–044).

Below is a non-normative example of an error response:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "bad_request",
  "error_description": "The request is missing status parameter."
}

13.1.3.7. Error Handling for Wallet Instance Management¶

To ensure robustness and security, the Wallet Provider MUST handle errors consistently across all Wallet Instance Management requests, including Registration, Retrieval, and Revocation.

In case of an error, the Wallet Provider MUST return an error response as defined in RFC 7231, with additional details available in RFC 7807. The response MUST use the Content-Type set to application/json 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 sections categorize errors into common errors, which apply to all requests, and request-specific errors, which are relevant to particular operations (WP_035–044, and WP_150–155).

13.1.3.8. Common Error Responses¶

The following errors apply to all Wallet Instance Management operations (Registration, Retrieval, and Revocation), and MUST be supported for the error response, unless otherwise specified (WP_035–039):

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters, or includes invalid and unknown parameters.
`422 Unprocessable Content` [OPTIONAL]	`validation_error`	The request does not adhere to the required format.
`500 Internal Server Error`	`server_error`	An internal error occurred while processing the request.
`503 Service Unavailable`	`temporarily_unavailable`	The service is unavailable. Please try again later.

13.1.3.9. Request-Specific Error Responses¶

The errors in Mobile Application Instance Initialization Error Response MUST be supported for error responses related to Wallet Instance Registration.

The following errors MUST be supported for error responses related to Wallet Instance Retrieval (WP_041–042):

HTTP Status Code	Error Code	Description
`403 Forbidden`	`forbidden`	The user does not have permission to retrieve this Wallet Instance.
`401 Unauthorized`	`unauthorized`	The request lacks valid authentication credentials.

The following errors MUST be supported for error responses related to Wallet Instance Revocation (WP_043–044):

HTTP Status Code	Error Code	Description
`403 Forbidden`	`invalid_request`	The user does not have permission to revoke this Wallet Instance.
`401 Unauthorized`	`unauthorized`	The request cannot be authenticated or authorized.

13.1.4. Wallet App and Wallet Unit Attestation Issuance Endpoint¶

This is a RESTful API endpoint provided by the Wallet Provider that enables the Wallet Instance to obtain Wallet App and Wallet Unit Attestation, by sending a Wallet App and Wallet Unit Attestation Issuance Request.

13.1.4.1. Wallet App and Wallet Unit Attestation Issuance Request¶

The Wallet App and Wallet Unit Attestation Issuance Request uses the HTTP POST method with Content-Type set to application/json. (WP_026 and WP_140–142).

The typ header of the Wallet App and Wallet Unit Attestation Issuance Request JWT assumes the value wp-war-wua+jwt.

The Wallet App and Wallet Unit Attestation Issuance Request body contains an assertion parameter whose value is a signed JWT including all header parameters and body claims described below.

Below is a non-normative example of a Wallet App and Wallet Unit Attestation Request.

POST /wallet-attestation HTTP/1.1
Host: application-provider.example.org
Content-Type: application/json

{
  "assertion": "eyJpc3MiOiJodHRwczovL3dhbGxldC1wcm92aWRlc..."
}

In particular, the Wallet App and Wallet Unit Attestation Issuance JWT includes the following HTTP header parameters:

Parameter	Description	Reference
alg	A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	[RFC 7516#section-4.1.1]
kid	Thumbprint of the Wallet Instance's JWK contained in the `cnf` claim.	[RFC 7638#section_3]
typ	The type of the JWT, it MUST set to `wp-war-wua+jwt`.

The Wallet App and Wallet Unit Attestation Request JWT includes the following body claims:

Claim	Description	Reference
iss	The identifier of the Wallet Provider concatenated with the thumbprint of the JWK in the `cnf` claim.	[RFC 9126], [RFC 7519].
aud	The identifier of the Wallet Provider.	[RFC 9126], [RFC 7519].
exp	UNIX timestamp representing the JWT expiration time.	[RFC 9126], [RFC 7519].
iat	UNIX timestamp representing the JWT issuance time.	[RFC 9126], [RFC 7519].
nonce	The `nonce` obtained from the Nonce Endpoint.
hardware_signature	The signature of `client_data_hash_waa` and `client_data_hash_wua` obtained using the Cryptographic Hardware Key, encoded in the `base64url` format.
integrity_assertion	The Integrity Assertion for Wallet App Attestation obtained from the Device Integrity Service APIs with the holder binding of `client_data_hash_waa`.
attested_key	The key Attestation obtained for the credential key either from the Key Attestation APIs with the holder binding of `client_data_hash_wua` or from the Device Integrity Service APIs with the holder binding of `client_data_hash_wua`.
hardware_key_tag	The value of the Cryptographic Hardware Key Tag.
cnf	JSON object containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7800.

Below is a non-normative example of a Wallet App and Wallet Unit Attestation Request JWT header and payload.

{
  "alg": "ES256",
  "kid": "OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "typ": "wp-war-wua+jwt"
}

{
  "iss": "https://wallet-provider.example.org/instance/OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "sub": "https://wallet-provider.example.org/",
  "nonce": "f3b29a81-45c7-4d12-b8b5-e1f6c9327aef",
  "hardware_signature": "KoZIhvcNAQcCoIAwgAIB...",
  "integrity_assertion": "o2NmbXRvYXBwbGUtYXBwYXNzZXJ0aW9uLXBheWxvYWQtYXBw...",
  "attested_key": "o2CFbXRvYXBwbGUtYXBwYXNzTYU0aW9uLXBheWxvYWQtZvRM..."
  "hardware_key_tag": "QW12DylRTmF89iGkpydNDWW7m8bVpa2Fn9KBeXGYtfX"
  "cnf": {
    "jwk": {
      "crv": "P-256",
      "kty": "EC",
      "x": "8FJtI-yr3pjyRKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "MKZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
    }
  }
}

13.1.4.2. Wallet App and Wallet Unit Attestation Issuance Response¶

If the Wallet App and Wallet Unit Attestation Issuance Request is successfully validated, the Wallet Provider returns an HTTP response with a status code of 200 OK and Content-Type application/json. The returned JSON Object MUST possess the wallet_attestations parameter, which includes wallet_app_attestations and wallet_unit_attestation elements (see Wallet App and Wallet Unit Attestation Issuance). wallet_app_attestations is an array containing the Wallet App Attestations in JWT, SD-JWT and mdoc format and wallet_unit_attestation is a single object containing the Wallet Unit Attestation. Both attestations are signed by the Wallet Provider (WP_027–029 and WP_143–144). The JWT formatted Wallet App Attestation is to be used for the Issuance phase, as an OAuth Client Attestation, and will be sent to the Credential Issuer as discussed in Digital Credential Issuance. The SD-JWT and mdoc formatted Wallet App Attestation will instead be used during presentation respectively in the remote (Remote Flow) and proximity (Proximity Flow) flows. The JWT formatted Wallet Unit Attestation is to be used for the Issuance phase, as an key_attestation JOSE header in the JWT proof type, and will be sent to the Credential Issuer as discussed in Digital Credential Issuance.

The JSON Object returned in the response has the following claim:

Parameter

Description

Reference

wallet_attestations

REQUIRED. A JSON array containing one or more Wallet App Attestation and one Wallet Unit Attestation in wallet_app_attestations and wallet_unit_attestation elements, respectively. It MUST contain the following mandatory claims:

wallet_app_attestation: A JSON array containing of one or more issued Wallet App Attestation. The elements of the array MUST be JSON Objects. At least two JSON Objects MUST be present.
wallet_unit_attestation: A JSON object containing of the issued Wallet Unit Attestation.

This specification.

Each JSON Object contained in the wallet_app_attestations array MUST have the following form:

Parameter

Description

Reference

format

A string identifying the Data Model used to create and represent the Wallet App Attestation. It MUST be either jwt, dc+sd-jwt or mso_mdoc depending on the credential format.

This specification.

wallet_app_attestation

A string representing the Wallet App Attestation. If

the Wallet App Attestation is in JWT format, then the claim's value MUST be a string that is a JWT.
the Wallet App Attestation is in SD-JWT format, then the claim's value MUST be a string that is an SD-JWT VC.
the Wallet App Attestation is in mdoc format, then the claim's value is the base64url-encoded representation of the CBOR-encoded IssuerSigned structure, as defined in [ISO.18013-5]. This structure MUST contain all Namespaces and IssuerSignedItems that are included in the MobileSecurityObject.

This specification.

In the case of wallet_unit_attestation parameter, its value is an string representing the Wallet Unit Attestation in a JWT.

If any errors occur during the process, an error response is returned. 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 (WP_035).

Below is a non-normative example of a Wallet App and Wallet Unit Attestation Issuance Response.

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

{
  "error": "invalid_request",
  "error_description": "The provided challenge is invalid, expired, or already used."
}

The following table lists HTTP Status Codes and related error codes that are supported for the error response, unless otherwise specified (WP_036–039 and WP_150–155):

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	The request is malformed, missing required parameters (e.g., header parameters, Integrity Assertion, or `attested_key`), or includes invalid and unknown parameters.
`403 Forbidden`	`invalid_request`	The Wallet Instance has been revoked.
`403 Forbidden`	`integrity_check_error`	The device does not meet the Wallet Provider's minimum security requirements.
`403 Forbidden`	`invalid_request`	The signature of the Wallet App and Wallet Unit Attestation Request is invalid or does not match the associated public key (JWK).
`403 Forbidden`	`invalid_request`	The Integrity Assertion or Key Attestation (`attested_key`) validation failed; the Integrity Assertion or Key Attestation (`attested_key`) is tampered with or improperly signed.
`403 Forbidden`	`invalid_request`	The provided `nonce` is invalid, expired, or already used.
`403 Forbidden`	`invalid_request`	The Proof of Possession (`hardware_signature`) is invalid.
`403 Forbidden`	`invalid_request`	The `iss` parameter does not match the Wallet Provider's expected URL identifier.
`404 Not Found`	`not_found`	The Wallet Instance was not found.
`422 Unprocessable Content` [OPTIONAL]	`validation_error`	The request does not adhere to the required format.
`500 Internal Server Error`	`server_error`	An internal server error occurred while processing the request.
`503 Service Unavailable`	`temporarily_unavailable`	The service is unavailable. Please try again later.

Di seguito forniamo i dettagli relativi alla Wallet App Attestation nei formati jwt, dc+sd-jwt o mso_mdoc e alla Wallet Unit Attestation nel formato jwt.

13.1.4.3. Wallet App Attestation JWT¶

The JOSE header of the Wallet App Attestation JWT contains the following parameters:

JOSE header	Description	Reference
alg	REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	RFC 7516#section-4.1.1.
kid	REQUIRED. Unique identifier of the public key associated to the private key the Wallet Provider used to sign the Wallet App Attestation.	RFC 7638#section_3.
typ	REQUIRED. It MUST be set to `oauth-client-attestation+jwt`	OPENID4VC-HAIP.
trust_chain	REQUIRED. Sequence of Entity Statements that composes the Trust Chain related to the Wallet Provider.	OID-FED Section 4.3 Trust Chain Header Parameter.
x5c	REQUIRED. Contains the X.509 public key certificate or certificate chain (RFC 5280) corresponding to the key used to digitally sign the JWT.	RFC 7515 Section 4.1.8 and SD-JWT-VC Section 3.5.

The body of the Wallet App Attestation JWT contains the following claims:

Claim	Description	Reference
iss	REQUIRED. Identifier of the Wallet Provider.	RFC 9126 and RFC 7519.
exp	REQUIRED. UNIX Timestamp with the expiry time of the JWT.	RFC 9126 and RFC 7519.
iat	REQUIRED. UNIX Timestamp with the time of JWT issuance.	RFC 9126 and RFC 7519.
cnf	REQUIRED. JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7800.
wallet_link	OPTIONAL. String containing a URL to get further information about the Wallet and the Wallet Provider.	OpenID4VCI.
wallet_name	OPTIONAL. String containing a human-readable name of the Wallet.	OpenID4VCI.
sub	REQUIRED. Identifier of the Wallet Instance which is the thumbprint of the Wallet App Attestation JWK.	RFC 9126 and RFC 7519.

Below is a non-normative example of the Wallet App Attestation JWT header and payload, without encoding and signature applied:

  {
    "alg": "ES256",
    "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
    "trust_chain": [
      "eyJhbGciOiJFUz...6S0A",
      "eyJhbGciOiJFUz...jJLA",
      "eyJhbGciOiJFUz...H9gw"
    ],
    "x5c": [
      "MIIDqjCCApKgAwIBAgIESLNEvDA ...",
      "MIICwzCCAasCCQCKVy9eKjvi+jA ...",
      "MIIDTDCCAjSgAwIBAgIJAPlnQYH..."
    ],
    "typ": "oauth-client-attestation+jwt"
  }

  {
    "iss": "https://wallet-provider.example.org",
    "cnf":
    {
      "jwk":
      {
        "crv": "P-256",
        "kty": "EC",
        "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
        "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
      }
    },
    "iat": 1687281195,
    "exp": 1687288395,
    "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
    "wallet_name": "Wallet_v1",
    "wallet_link": "https://example.com/wallet/detail_info.html"
  }

13.1.4.4. Wallet App Attestation SD-JWT¶

The JOSE header of the Wallet App Attestation SD-JWT MUST contain the following parameters:

JOSE header	Description	Reference
alg	REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	RFC 7516#section-4.1.1.
kid	REQUIRED. Unique identifier of the public key associated to the private key the Wallet Provider used to sign the Wallet App Attestation.	RFC 7638#section_3.
typ	REQUIRED. It MUST be set to `dc+sd-jwt`	OPENID4VC-HAIP.
trust_chain	REQUIRED. Sequence of Entity Statements that composes the Trust Chain related to the Wallet Provider.	OID-FED Section 4.3 Trust Chain Header Parameter.
x5c	REQUIRED. Contains the X.509 public key certificate or certificate chain (RFC 5280) corresponding to the key used to digitally sign the JWT.	RFC 7515 Section 4.1.8 and SD-JWT-VC Section 3.5.

The body of the Wallet App Attestation SD-JWT contains the following claims:

Claim	Description	Reference
iss	REQUIRED. Identifier of the Wallet Provider.	RFC 9126 and RFC 7519.
exp	REQUIRED. UNIX Timestamp with the expiry time of the JWT.	RFC 9126 and RFC 7519.
iat	REQUIRED. UNIX Timestamp with the time of JWT issuance.	RFC 9126 and RFC 7519.
cnf	REQUIRED. JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7800.
vct	REQUIRED. Credential type value MUST be an URN and it MUST be of the type `urn:eudi:wallet_app_attestation:it:{version}` as described in Digital Credentials Catalog.	Section 3.2.2.2 SD-JWT-VC.
_sd	REQUIRED. JSON array containing a list of all disclusure's digests.	SD-JWT.
_sd_alg	REQUIRED. String containing the hash algorithm used by the Wallet Provider to generate the disclusure's digests.	SD-JWT.
sub	OPTIONAL. Identifier of the Wallet Instance which is the thumbprint of the Wallet App Attestation JWK.	RFC 9126 and RFC 7519.

The following disclosures MAY be present:

Disclosure	Description	Reference
wallet_link	OPTIONAL. String containing a URL to get further information about the Wallet and the Wallet Provider.	OpenID4VCI.
wallet_name	OPTIONAL. String containing a human-readable name of the Wallet.	OpenID4VCI.

Note

Regardless of the fact that wallet_link and wallet_name are disclosable, these values MUST NOT be shown to the User, as they are not a User attribute.

Below are described examples of values for the disclosures:

Claim wallet_link:

SHA-256 Hash: cD9/XC7t7QVHvmSiE1dGW0WYr0jcqm8n0GA6MGitaik=
Disclosure: WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgIndhbGxldF9saW5rIiwgImh0dHBzOi8vZXhhbXBsZS5jb20vd2FsbGV0L2RldGFpbF9pbmZvLmh0bWwiXQ==
Contents: ["2GLC42sKQveCfGfryNRN9w", "wallet_link", "https://example.com/wallet/detail_info.html"]

Claim wallet_name:

SHA-256 Hash: iQQhzf6+saYCzHH92N1QyJisKsZbApbTrJ1amHgLoOk=
Disclosure:n``WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgIndhbGxldF9uYW1lIiwgIldhbGxldF9Ib2JiaXRvbl92MSJd``
Contents: ["2GLC42sKQveCfGfryNRN9w", "wallet_name", "Wallet_v1"]

Below is a non-normative example of the SD-JWT Wallet App Attestation header and payload without encoding and signature applied:

  {
    "alg": "ES256",
    "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
    "typ": "dc+sd-jwt",
    "x5c": [
      "MIIDqjCCApKgAwIBAgIESLNEvDA ...",
      "MIICwzCCAasCCQCKVy9eKjvi+jA ...",
      "MIIDTDCCAjSgAwIBAgIJAPlnQYH..."
    ]
  }

  {
    "iss": "https://wallet-provider.example.org",
    "cnf": {
      "jwk":
      {
        "crv": "P-256",
        "kty": "EC",
        "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
        "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
      }
    },
    "_sd": ["cD9/XC7t7QVHvmSiE1dGW0WYr0jcqm8n0GA6MGitaik=", "iQQhzf6+saYCzHH92N1QyJisKsZbApbTrJ1amHgLoOk="],
    "_sd_alg": "sha-256",
    "iat": 1687281195,
    "exp": 1687288395,
    "vct": "urn:eudi:wallet_app_attestation:it:1",
    "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
  }

13.1.4.5. Wallet App Attestation mdoc¶

This description extends the MDOC-CBOR Credential Format guidelines, given in mdoc-CBOR Credential Format, to support Wallet App Attestation data representation. The Wallet App Attestation MUST use docType of the form {Trust Anchor reverse domain}.{wallet_app_attestation} as described in Digital Credentials Catalog.

The nameSpaces for the domestic nameSpace Json Objects are defined as follows:

Table 13.1 it.wallet.trust-registry.WalletAttestation¶
elementIdentifier	Description	Reference
sub	OPTIONAL. Identifier of the Wallet Instance which is the thumbprint of the Wallet App Attestation COSE Key.	RFC 9126 and RFC 7519.
wallet_link	OPTIONAL. JSON String containing a URL to get further information about the Wallet and the Wallet Provider.	OpenID4VCI.
wallet_name	OPTIONAL. JSON String, it MUST be the Identifier of the Wallet Provider.	OpenID4VCI.

Below is a non-normative example of the mdoc Wallet App Attestation in CBOR diagnostic notation:

  {
    "nameSpaces": {
      "it.wallet.trust-registry.wallet_attestation": [
        24(<<
          {
            "digestID": 0,
            "elementIdentifier": "sub",
            "elementValue": "ec#1",
            "random": h'0117942b3ecdad65f226a668466fa175b72563a392598ad18fa6d359ea9b1b2d'
          }
        >>),
        24(<<
          {
            "digestID": 1,
            "elementIdentifier": "wallet_link",
            "elementValue": "https://wallet-provider.example.org",
            "random": h'dc9d032a64866e33d06f48a882989b5747da3638f0d216a2275191ed3395fdec'
          }
        >>),
        24(<<
          {
            "digestID": 2,
            "elementIdentifier": "wallet_name",
            "elementValue": "Wallet name",
            "random": h'd665c50c4364c7cbf4ab9461b9bbb228f37ad278b9fb61283550951624d4d9ae'
          }
        >>)
      ]
    },
    "issuerAuth": [
      << {1: -7} >>,
      {
        33: h'825903B0...'
      },
      <<
        24(<<
          {
            "version": "1.0",
            "digestAlgorithm": "SHA-256",
            "valueDigests": {
              "it.wallet.trust-registry.wallet_attestation": {
                0: h'2f89a12f690fe570b9b18d96acd231a70b5cb97cef5edad81973b99eeb145c2f',
                1: h'7541a38f61d686f72ca8fb9da87a3db9fc65d28caa4e0973b0a3d66181ff7997',
                2: h'7049c3bfcd96d62833f2fdb892b12cb6fd983b4c3bf40b0c39cb233bfeb5b75f',
                3: h'ce566344e76ff543c5084e7618bdb54223ff2750dbcb4a3c7c35fd56a47a1024'
              }
            },
            "deviceKeyInfo": {
              "deviceKey": {
                -1: 1,
                2: "ec#1",
                1: 2,
                -2: h'09a9028deb030705de45e4702d1ce6860e94c0e29f334359a476078c2d22b9c5',
                -3: h'6b972cd32c19cd5e8c19e051f1e207cabb3c2a802abf40ee5baaaa4a464508c3'
              }
            },
            "docType": "it.wallet.trust-registry.wallet_attestation",
            "validityInfo": {
              "signed": 0("2025-06-27T07:40:21Z"),
              "validFrom": 0("2025-06-27T07:40:21Z"),
              "validUntil": 0("2025-06-27T08:40:21Z")
            }
          }
        >>)
      >>
      h'97f223fd4c9c462454e4123df916dd0d672af14608727ce38470b8bd74fb496e11462113f0005d3e97bf6115074712991e1720eb085292edd894a116a305310c'
    ]
  }

Note

Regardless of the fact that sub, wallet_link and wallet_name are disclosable in the domestic namespace, these values MUST NOT be shown to the User, as they are not a User attribute.

13.1.4.6. Wallet Unit Attestation JWT¶

The JOSE header of the Wallet Unit Attestation JWT contains the following parameters:

JOSE header	Description	Reference
alg	REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section Cryptographic Algorithms and MUST NOT be set to `none` or any symmetric algorithm (MAC) identifier.	RFC 7516#section-4.1.1.
kid	REQUIRED. Unique identifier of the public key associated to the private key the Wallet Provider used to sign the Wallet Unit Attestation.	RFC 7638#section_3.
typ	REQUIRED. It MUST be set to `key-attestation+jwt`	OPENID4VC-HAIP.
trust_chain	REQUIRED. Sequence of Entity Statements that composes the Trust Chain related to the Wallet Provider.	OID-FED Section 4.3 Trust Chain Header Parameter.
x5c	OPTIONAL. Contains the X.509 public key certificate or certificate chain (RFC 5280) corresponding to the key used to digitally sign the JWT.	RFC 7515 Section 4.1.8.

The body of the Wallet Unit Attestation JWT contains the following claims:

Claim	Description	Reference
iss	REQUIRED. Identifier of the Wallet Provider.	RFC 9126 and RFC 7519.
exp	REQUIRED. UNIX Timestamp with the expiry time of the JWT.	RFC 9126 and RFC 7519.
iat	REQUIRED. UNIX Timestamp with the time of JWT issuance.	RFC 9126 and RFC 7519.
attested_keys	REQUIRED. A non-empty array of attested keys from the same key storage component using the syntax of JWK, containing the public part of an asymmetric key pair owned by the Wallet Instance.	RFC 7517.
key_storage	REQUIRED. A non-empty array of case sensitive strings that assert the attack potential resistance of the key storage component and its keys attested in the `attested_keys` parameter. The following values are defined as a value for this claim: `iso_18045_high`: It MUST be used when key storage is resistant to attack with attack potential `High`. `iso_18045_moderate`: It MUST be used when key storage is resistant to attack with attack potential `Moderate`. `iso_18045_basic`: It MUST be used when key storage is resistant to attack with attack potential `Basic`.	OpenID4VCI.
user_authentication	REQUIRED. A non-empty array of case sensitive strings that assert the attack potential resistance of the user authentication methods allowed to access the private keys from the `attested_keys` parameter. The following values are defined as a value for this claim: `iso_18045_high`: It MUST be used when user authentication is resistant to attack with attack potential `High`. `iso_18045_moderate`: It MUST be used when user authentication is resistant to attack with attack potential `Moderate`. `iso_18045_basic`: It MUST be used when user authentication is resistant to attack with attack potential `Basic`.	OpenID4VCI.
status	REQUIRED. JSON Object representing the supported revocation check mechanisms, such as OAuth Status List.	OpenID4VCI.
certification	OPTIONAL. A String that contains a URL that links to the certification of the key storage component.	OpenID4VCI.

Below is a non-normative example of the Wallet Unit Attestation JWT header and payload, without encoding and signature applied:

  {
    "alg": "ES256",
    "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
    "trust_chain": [
      "eyJhbGciOiJFUz...6S0A",
      "eyJhbGciOiJFUz...jJLA",
      "eyJhbGciOiJFUz...H9gw"
    ],
    "typ": "key-attestation+jwt"
  }

  {
    "iss": "https://wallet-provider.example.org",
    "attested_keys": [
      {
        "crv": "P-256",
        "kty": "EC",
        "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
        "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
      }
    ],
    "status": { 
    "status_list": {
        "idx": 412,
        "uri": "https://revocation_url/statuslists/1"
      }
  },
    "iat": 1687281195,
    "exp": 1687288395,
    "key_storage": [ "iso_18045_moderate" ],
    "user_authentication": [ "iso_18045_moderate" ],
    "certification": "GP"
  }

13.1.5. e-Service PDND Wallet Provider Catalog¶

User's death leads to the revocation of the Wallet Instances of the User and the deletion of the User account at the Wallet Provider. For this reason, the Wallet Provider provides the following e-service through PDND. A PID Provider that has been notified by the Authentic Source of the PID of the User's death MUST send a notification to Wallet Providers using this endpoint.

Note

A complete OpenAPI Specification is available here.

13.1.5.1. Notify User Death¶

Description	This service is used to notify the Wallet Provider of the need to revoke the Wallet Instance and delete the User's account due to the User's death.
Provider	Wallet Provider
Consumer	PID Provider