From 3ea35af96f27fd576e269d5cc19ddd9f82222834 Mon Sep 17 00:00:00 2001 From: Francesco Grauso Date: Thu, 29 Aug 2024 16:01:53 +0200 Subject: [PATCH] fix: Wallet solution editorial changes (#387) --- docs/en/wallet-attestation.rst | 59 ++++++++++++++-------------- docs/en/wallet-solution.rst | 70 +++++++++++++++------------------- 2 files changed, 59 insertions(+), 70 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 142b3a3a7..c8f1c8977 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -10,33 +10,32 @@ Wallet Attestation contains information regarding the security level of the devi Requirements ------------ -The following requirements for the Wallet Attestation are met: +The requirements for the Wallet Attestation are defined below: - The Wallet Attestation MUST use the signed JSON Web Token (JWT) format; -- The Wallet Attestation MUST give all the relevant information to attests the **integrity** and **security** of the device where the Wallet Instance is installed. -- The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and that is the owner of the Wallet Solution, as specified by the overseeing registration authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance. -- The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties. The Wallet Provider MUST also verify the Wallet Instance by using the App Store vendor's API, *Play Integrity API* for Android, and *DeviceCheck* for iOS. These services are defined in this specification as **Device Integrity Service (DIS)**. +- The Wallet Attestation MUST provide all the relevant information to attest to the **integrity** and **security** of the device where the Wallet Instance is installed. +- The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and is the owner of the Wallet Solution, as specified by the overseeing registration authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance. +- The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties. The Wallet Provider MUST also verify the Wallet Instance using the App Store vendor's API, such as the *Play Integrity API* for Android and *DeviceCheck* for iOS. These services are defined in this specification as **Device Integrity Service (DIS)**. - The Wallet Attestation MUST have a mechanism in place for revoking the Wallet Instance, allowing the Wallet Provider to terminate service for a specific instance at any time. -- The Wallet Attestation MUST be securely bound to the Wallet Instance ephemeral public key. -- The Wallet Attestation MAY be usable multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction. -- The Wallet Attestation MUST be short-lived and MUST have an expiration date time, after which SHOULD no longer be considered valid. +- The Wallet Attestation MUST be securely bound to the Wallet Instance's ephemeral public key. +- The Wallet Attestation MAY be used multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction. +- The Wallet Attestation MUST be short-lived and MUST have an expiration date/time, after which it SHOULD no longer be considered valid. - The Wallet Attestation MUST NOT be issued by the Wallet Provider if the authenticity, integrity, and genuineness are not guaranteed. In this case, the Wallet Instance MUST be revoked. -- Each Wallet Instance SHOULD be able to request multiple attestations with different ephemeral public keys associated to them. This requirement provides a privacy-preserving measure, as the public key MAY be used as a tracking tool during the presentation phase (see also the point listed below). -- The Wallet Attestation MUST NOT contain any information that can be used to directly reference the User. -- The Wallet Instances MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by `ARF`_. +- Each Wallet Instance SHOULD be able to request multiple attestations with different ephemeral public keys associated with them. This requirement provides a privacy-preserving measure, as the public key MAY be used as a tracking tool during the presentation phase (see also the point listed below). +- The Wallet Attestation MUST NOT contain any information that can be used to directly identify the User. +- The Wallet Instance MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by `ARF`_. - Private keys MUST be generated and stored in the WSCD using at least one of the approaches listed below: - - **Local Internal WSCD**: in this approach, the WSCD relies entirely on the device's native cryptographic hardware, such as the Secure Enclave on iOS devices or the Hardware Backed Keystore or Strongbox on Android devices. - - **Local External WSCD**: the WSCD is an hardware external to the User's device, such as a smart card compliant with *GlobalPlatform* and supporting *JavaCard*. - - **Remote WSCD**: Here, the WSCD utilizes a remote Hardware Security Module (HSM). - - - **Local Hybrid WSCD**: the WSCD involves a pluggable internal hardware component within the User's device, such as an *eUICC* that adheres to *GlobalPlatform* standards and supports *JavaCard*. - - **Remote Hybrid WSCD**: the WSCD involves a local component mixed with a remote service. + - **Local Internal WSCD**: The WSCD relies entirely on the device's native cryptographic hardware, such as the Secure Enclave on iOS devices or the Hardware-Backed Keystore or Strongbox on Android devices. + - **Local External WSCD**: The WSCD is hardware external to the User's device, such as a smart card compliant with *GlobalPlatform* and supporting *JavaCard*. + - **Remote WSCD**: The WSCD utilizes a remote Hardware Security Module (HSM). + - **Local Hybrid WSCD**: The WSCD involves a pluggable internal hardware component within the User's device, such as an *eUICC* that adheres to *GlobalPlatform* standards and supports *JavaCard*. + - **Remote Hybrid WSCD**: The WSCD involves a local component mixed with a remote service. - The Wallet Provider MUST offer a set of services, exclusively available to its Wallet Solution instances, for the verification and issuance of Wallet Attestations. .. warning:: - At the current stage, the current implementation profile defined in this document supports only the **Local Internal WSCD**. Future versions of this specification MAY include other approaches depending on the required `AAL`. + At the current stage, the implementation profile defined in this document supports only the **Local Internal WSCD**. Future versions of this specification MAY include other approaches depending on the required `AAL`. Static Component View --------------------- @@ -56,23 +55,22 @@ Wallet Instance Initialization and Registration .. figure:: ../../images/wallet_instance_initialization.svg :name: Sequence Diagram for Wallet Instance Initialization - :alt: The figure illustrates the sequence diagram for initializa a Wallet Instance, with the steps explained below. + :alt: The figure illustrates the sequence diagram for initializing a Wallet Instance, with the steps explained below. :target: https://www.plantuml.com/plantuml/uml/ZLFHRjD047o_hrYb3xHM-84yeA8Iqgf04IdmlBOtpYhEdRMt3eIlPy-cQMoPmeCZQszcTcOklewAeks-TjXgyEq-9t5RBWas8MWUVhfNZG6uu0QzEeU51e7PrqWo0upGseixGy3iEzOrATnvK_O5TIXi6XYYtj612pAKKYMiHrYJf4aFHurm4HjXNrL2v2StV9PmCAC2EHOxycL7pOkTSvM4je7WwoEqJV2mOOaAR8wCYSes2XlGBILZBaLu_SRU5j2L4PzEuB8d6k0g1US3Qa-nvm_ZPal53dW3Vmi4R7aEo3NcDJadFfX6E90aeRdPXOiFTwlRnzMNvVAJw-N60KqY5V1a-ZtPi8-1leIGAx87DkDxKYnHqLaTtIRdUg-sPm4hqyooOflKVKLPzXmgrMRF2UX9qZXu0kKzfGf6r8JkEnWTb3HGFLLrKZNyZHmR3PLWi-K2Rb7A7oW4ztICMMPPMRfaKOEy38T7h6ndlmGrBW1LAQeTNPvCpU5bWIkNgCzfqlXj9zELR8uYLvvAo8_miFnurkZQUXx6dq_oBSn_nPY-ZczOSuawke59m7Zt0BR-PvrnUB4FznEtQOVfYrd0w4Et5rOs9x-eFASP9VqTtRNzjFlwDm00 **Step 1**: The User starts the Wallet Instance mobile app for the first time. **Step 2**: The Wallet Instance: - * check if Device Integrity Service is available. - * check whether the device meets the minimum security requirements. + * Checks if the Device Integrity Service is available. + * Checks whether the device meets the minimum security requirements. .. note:: - **Federation Check**: The Wallet Instance needs to check if the Wallet Provider is part of the Federation, obtaining its protocol specific Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the Wallet Provider is represented within the section `Wallet Provider metadata`_. + **Federation Check**: The Wallet Instance needs to check if the Wallet Provider is part of the Federation, obtaining its protocol-specific Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the Wallet Provider is represented within the section `Wallet Provider metadata`_. **Steps 3-5**: The Wallet Instance sends a request to the Wallet Provider Backend and receives a one-time ``challenge``. This "challenge" is a ``nonce``, which must be unpredictable to serve as the main defense against replay attacks. The backend must generate the ``nonce`` value in a manner that ensures it is single-use and valid only within a specific time frame. This endpoint is compliant with the specification `OAuth 2.0 Nonce Endpoint`_. - .. code-block:: http GET /nonce HTTP/1.1 @@ -89,26 +87,25 @@ Wallet Instance Initialization and Registration **Step 6**: The Wallet Instance, through the operating system, creates a pair of Cryptographic Hardware Keys and stores the corresponding Cryptographic Hardware Key Tag in local storage once the following requirements are met: - 1. It MUST ensure that Cryptographic Hardware Keys do not already exist, if they exist and the Wallet is in the initialization phase they MUST be deleted. + 1. It MUST ensure that Cryptographic Hardware Keys do not already exist. If they do exist and the Wallet is in the initialization phase, they MUST be deleted. 2. It MUST generate a pair of asymmetric Elliptic Curve keys (Cryptographic Hardware Keys) via a local WSCD. 3. It SHOULD obtain a unique identifier (Cryptographic Hardware Key Tag) for the generated Cryptographic Hardware Keys from the operating system. If the operating system permits specifying a tag during the creation of keys, then a random string for the Cryptographic Hardware Key Tag MUST be selected. This random value MUST be collision-resistant and unpredictable to ensure security. To achieve this, consider using a cryptographic hash function or a secure random number generator provided by the operating system or a reputable cryptographic library. - 4. If the previous points are satisfied, It MUST store the Cryptographic Hardware Key Tag in a local storage. + 4. If the previous points are satisfied, it MUST store the Cryptographic Hardware Key Tag in local storage. .. note:: - **WSCD**: The Wallet Instance MAY use a local WSCD for key generation on devices that support this feature. On Android devices, Strongbox is RECOMMENDED, Trusted Execution Environment (TEE) SHOULD be used only when Strongbox is unavailable. For iOS devices, Secure Elements (SE) SHOULD be used. Given that each OEM offers a distinct SDK for accessing the local WSCD, the discussion hereafter will address this topic in a general context. - + **WSCD**: The Wallet Instance MAY use a local WSCD for key generation on devices that support this feature. On Android devices, Strongbox is RECOMMENDED; Trusted Execution Environment (TEE) MAY be used only when Strongbox is unavailable. For iOS devices, Secure Elements (SE) MUST be used. Given that each OEM offers a distinct SDK for accessing the local WSCD, the discussion hereafter will address this topic in a general context. -**Step 7**: The Wallet Instance uses the Device Integrity Service, providing a "challenge" and the Cryptographic Hardware Key Tag to acquire the Key Attestation. +**Step 7**: The Wallet Instance uses the Device Integrity Service, providing the "challenge" and the Cryptographic Hardware Key Tag to acquire the Key Attestation. .. note:: - **Device Integrity Service**: In this section the Device Integrity Service is considered as it is provided by device manufacturers. This service allows the verification of a key being securely stored within the device's hardware through a signed object. Additionally, it offers the verifiable proof that a specific Wallet Instance is authentic, unaltered, and in its original state using a specialized signed document made for this scope. + **Device Integrity Service**: In this section, the Device Integrity Service is considered as it is provided by device manufacturers. This service allows the verification of a key being securely stored within the device's hardware through a signed object. Additionally, it offers verifiable proof that a specific Wallet Instance is authentic, unaltered, and in its original state using a specialized signed document made for this purpose. - The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess the device has not been compromised. For Android, the DIS is represented by *Key Attestation*, a feature supported by *StrongBox Keymaster*, which is a physical HSM installed directly on the motherboard, and the *TEE* (Trusted Execution Environment), a secure area of the main processor. *Key Attestation* aims to provide a way to strongly determine if a key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage. Developers can leverage its functionality through the *Play Integrity API*.For Apple devices, the DIS is represented by *DeviceCheck*, which provides a framework and server interface to manage device-specific data securely. *DeviceCheck* is used in combination with the *Secure Enclave*, a dedicated HSM integrated into Apple's SoCs. *DeviceCheck* can be used to attest the integrity of the device, apps, and/or encryption keys generated on the device, ensuring they were created in a secure environment like *Secure Enclave*. Developers can leverage *DeviceCheck* functionality by using the framework itself. + The service also incorporates details in the signed object, such as the device type, model, app version, operating system version, bootloader status, and other relevant information to assess whether the device has been compromised. For Android, the DIS is represented by *Key Attestation*, a feature supported by *StrongBox Keymaster*, which is a physical HSM installed directly on the motherboard, and the *TEE* (Trusted Execution Environment), a secure area of the main processor. *Key Attestation* aims to provide a way to strongly determine if a key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage. Developers can leverage its functionality through the *Play Integrity API*. For Apple devices, the DIS is represented by *DeviceCheck*, which provides a framework and server interface to manage device-specific data securely. *DeviceCheck* is used in combination with the *Secure Enclave*, a dedicated HSM integrated into Apple's SoCs. *DeviceCheck* can be used to attest to the integrity of the device, apps, and/or encryption keys generated on the device, ensuring they were created in a secure environment like *Secure Enclave*. Developers can leverage *DeviceCheck* functionality by using the framework itself. These services, specifically developed by the manufacturer, are integrated within the Android or iOS SDKs, eliminating the need for a predefined endpoint to access them. Additionally, as they are specifically developed for mobile architecture, they do not need to be registered as Federation Entities through national registration systems. - For Apple devices *Secure Enclave* is available since the iPhone 5s (2013). - For Android devices, the inclusion of **Strongbox Keymaster** may vary by each smartphone manufacturer, who decides whether to include it or not. + *Secure Enclave* has been available on Apple devices since the iPhone 5s (2013). + For Android devices, the inclusion of **Strongbox Keymaster** may vary by manufacturer, who decides whether to include it or not. **Step 8**: The Device Integrity Service performs the following actions: diff --git a/docs/en/wallet-solution.rst b/docs/en/wallet-solution.rst index 398aa1b17..37afa165e 100644 --- a/docs/en/wallet-solution.rst +++ b/docs/en/wallet-solution.rst @@ -5,32 +5,31 @@ Wallet Solution ------------------- -The Wallet Solution is a comprehensive product offered by the Wallet Provider to cater to the needs of Users in managing their digital assets securely. It is issued by the Wallet Provider in the form of a mobile app, it also consists of services and web interfaces for the exchange of data between the Wallet Provider and its Wallet Instances for the requirements of the trust model and in total respect of the User's privacy, in accordance with national and EU legislation. +The Wallet Solution is a comprehensive product offered by the Wallet Provider to cater to the needs of Users in managing their digital assets securely. It is issued by the Wallet Provider in the form of a mobile app and consists of services and web interfaces for the exchange of data between the Wallet Provider and its Wallet Instances to meet the requirements of the trust model and ensure full respect for the User's privacy, in accordance with national and EU legislation. -The mobile app serves as the primary interface for Users, allowing them to access and interact with their digital Credentials conveniently. These are a set of data that can uniquely identify a natural or a legal person, along with other Qualified and non-qualified Electronic Attestations of Attributes, also known as QEAAs and EAAs respectively, or (Q)EAAs for short[1]. Once a User installs the mobile app on their device, it is referred to such an installation as a Wallet Instance for the User. +The mobile app serves as the primary interface for Users, allowing them to access and interact with their digital Credentials conveniently. These Credentials are a set of data that can uniquely identify a natural or legal person, along with other Qualified and non-qualified Electronic Attestations of Attributes, also known as QEAAs and EAAs respectively, or (Q)EAAs for short[1]. Once a User installs the mobile app on their device, such an installation is referred to as a Wallet Instance for the User. -By supporting the mobile app, the Wallet Provider plays a vital role in ensuring the security and reliability of the entire Wallet Solution, since it is responsible for issuing the Wallet Attestation, that is a cryptographic proof that allow the evaluation of the authenticity and the integrity of the Wallet Instance. +By supporting the mobile app, the Wallet Provider plays a vital role in ensuring the security and reliability of the entire Wallet Solution, as it is responsible for issuing the Wallet Attestation, which is a cryptographic proof that allows the evaluation of the authenticity and integrity of the Wallet Instance. The Wallet Provider MUST offer a RESTful set of services for issuing the Wallet Attestations. Requirements ^^^^^^^^^^^^ -This section lists below the essential requirements that must be met by the Wallet Solution to ensure its functionality, security, and compliance with relevant standards and regulations. +This section lists the essential requirements that must be met by the Wallet Solution to ensure its functionality, security, and compliance with relevant standards and regulations. - **Trustworthiness within the Wallet ecosystem**: the Wallet Instance MUST establish trust and reliability within the Wallet ecosystem. - **Compliance with Provider specifications for obtaining PID and (Q)EAA**: the Wallet Instance MUST adhere to the specifications set by Providers for obtaining Personal Identification (PID) and (Q)EAAs. - - **Support for Android and iOS operating systems**: the Wallet Instance MUST be compatible and functional at least on both Android and iOS operating systems, as well as available on the Play Store and App Store respectively. + - **Support for Android and iOS operating systems**: the Wallet Instance MUST be compatible and functional on both Android and iOS operating systems and available on the Play Store and App Store, respectively. - **Verification of device ownership by the User**: the Wallet Instance MUST provide a mechanism to verify the User's actual possession and full control of their personal device. - Wallet Instance ^^^^^^^^^^^^^^^ -The Wallet Instance serves as a unique and secure device for authenticating the User within the Wallet ecosystem. It establishes a strong and reliable mechanismm for the User to engage various digital transactions in a secure and privacy-preserving manner. +The Wallet Instance serves as a unique and secure device for authenticating the User within the Wallet ecosystem. It establishes a strong and reliable mechanism for the User to engage in various digital transactions in a secure and privacy-preserving manner. -The Wallet Instance establishes the trust within the Wallet ecosystem by consistently presenting a Wallet Attestation during interactions with other ecosystem actors such as PID Providers, (Q)EAA Providers, and Relying Parties. These verifiable attestations, provided by the Wallet Provider, purpose to authenticate the Wallet Instance itself, ensuring its realiability when engaging with other ecosystem actors. +The Wallet Instance establishes trust within the Wallet ecosystem by consistently presenting a Wallet Attestation during interactions with other ecosystem actors such as PID Providers, (Q)EAA Providers, and Relying Parties. These verifiable attestations, provided by the Wallet Provider, serve to authenticate the Wallet Instance itself, ensuring its reliability when engaging with other ecosystem actors. -To guarantee the utmost security, these cryptographic keys MUST be securely stored within the WSCD which MAY be internal (device's Trusted Execution Environment (TEE)[3]), external, or hybrid. This ensures that only the User is allowed to access them, thus preventing unauthorized usage or tampering. For more detailed information please refer to the `Wallet Attestation section`_ and the `Trust Model section`_ of this document. +To guarantee the utmost security, these cryptographic keys MUST be securely stored within the WSCD, which MAY be internal (device's Trusted Execution Environment (TEE)[3]), external, or hybrid. This ensures that only the User can access them, thus preventing unauthorized usage or tampering. For more detailed information, please refer to the `Wallet Attestation section`_ and the `Trust Model section`_ of this document. Wallet Instance Lifecycle ^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -38,53 +37,47 @@ The Wallet Instance has three distinct states: Operational, Valid, and Deactivat Initialization Process ~~~~~~~~~~~~~~~~~~~~~~ -To activate the Wallet Instance, the Users MUST install the mobile Wallet application on their device and open it. Furthermore, Users will be asked to set their preferred method of unlocking their device; this can be accomplished by entering a personal identification number (PIN) or by utilizing biometric authentication, such as fingerprint or facial recognition, according to their personal preferences and device's capabilities. +To activate the Wallet Instance, Users MUST install the mobile Wallet application on their device and open it. Furthermore, Users will be asked to set their preferred method of unlocking their device; this can be accomplished by entering a personal identification number (PIN) or by utilizing biometric authentication, such as fingerprint or facial recognition, according to their personal preferences and device's capabilities. -After completing these steps, the Wallet Instance sets the Operational state. +After completing these steps, the Wallet Instance enters the Operational state. Transition to Valid state ~~~~~~~~~~~~~~~~~~~~~~~~~ To transition from the Operational state to the Valid state, the Wallet Instance MUST obtain a valid Personal Identification (PID). Once a valid PID is acquired, the Wallet Instance becomes Valid. -To securely and unambiguously authenticate Users, the Wallet Instance necessitates a High Level of Assurance (LoA 3) for User authentication. The method to achieve this LoA is selected by the PID Provider based on the identity proofing method employed during the provisioning of the Digital Credential to the User. Furthermore, to store the acquired Digital Credential, the Wallet Instance MUST demonstrate to the Credential Issuer an adequate security compliance to maintain the Credential at the same LoA at which it was issued. +The Wallet Instance MUST demonstrate to the Credential Issuer adequate security compliance to maintain the Credential at the same LoA at which it was issued. -Once the Wallet Instance is in the Operational state, Users can: +Once the Wallet Instance is in the Valid state, Users can: - Obtain, view, and manage (Q)EAAs from trusted (Q)EAA Providers[1]; - Authenticate to Relying Parties[1]; - - Authorize the presentation of their digital Credentials with Relying Parties. - -Please refer to the relative sections for further information about PID and (Q)EAAs issuance and presentation. + - Authorize the presentation of their digital Credentials to Relying Parties. +Please refer to the relevant sections for further information about PID and (Q)EAAs issuance and presentation. Return to Operational state ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A Valid Wallet Instance may revert to the Operational state under specific circumstances. These circumstances include the expiration or the revocation of the associated PID by its PID Provider. - +A Valid Wallet Instance may revert to the Operational state under specific circumstances. These circumstances include the expiration or revocation of the associated PID by its PID Provider. Deactivation ~~~~~~~~~~~~ Users have the ability to deactivate the Wallet Instance voluntarily. This action removes the operational capabilities of the Wallet Instance and sets it to the Deactivated state. Deactivation provides Users with control over access and usage according to their preferences. - Wallet Provider Endpoints ^^^^^^^^^^^^^^^^^^^^^^^^^ -The Wallet Provider that issues the Wallet Attestations MUST -made available its APIs in the form of RESTful services, as listed below. +The Wallet Provider that issues the Wallet Attestations MUST make its APIs available in the form of RESTful services, as listed below. Wallet Provider Metadata -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -An HTTP GET request to the **/.well-known/openid-federation** endpoint allows the retrieval of the Wallet -Provider Entity Configuration. +~~~~~~~~~~~~~~~~~~~~~~~~ +An HTTP GET request to the **/.well-known/openid-federation** endpoint allows the retrieval of the Wallet Provider Entity Configuration. The Wallet Provider Entity Configuration is a JWS containing the public keys and supported algorithms of the Wallet Provider metadata definition. It is structured in accordance with the `OpenID Connect Federation `_ and the Trust Model section outlined in this specification. -The returning Entity Configuration of the Wallet Provider MUST contain the -attributes listed below: +The returning Entity Configuration of the Wallet Provider MUST contain the attributes listed below: Header -^^^^^^^ +^^^^^^ .. list-table:: :widths: 20 80 :header-rows: 1 @@ -92,12 +85,11 @@ Header * - **Key** - **Value** * - alg - - Algorithm used to verify the token signature. It MUST be one of the possibile values indicated in this `table `_ (e.g., ES256). + - Algorithm used to verify the token signature. It MUST be one of the possible values indicated in this `table `_ (e.g., ES256). * - kid - - Thumbprint of the public key used for signing, according to :rfc:`7638`. + - Thumbprint of the public key used for signing, according to :rfc:`7638`. * - typ - - Media type, set to ``entity-statement+jwt``. - + - Media type, set to ``entity-statement+jwt``. Payload ^^^^^^^ @@ -110,20 +102,19 @@ Payload * - iss - Public URL of the Wallet Provider. * - sub - - Public URL of the Wallet Provider. + - Public URL of the Wallet Provider. * - iat - - Issuance datetime in Unix Timestamp format. + - Issuance datetime in Unix Timestamp format. * - exp - - Expiration datetime in Unix Timestamp format. + - Expiration datetime in Unix Timestamp format. * - authority_hints - - Array of URLs (String) containing the list of URLs of the immediate superior Entities, such as the Trust Anchor or an Intermediate, that MAY issue an Entity Statement related to this subject. + - Array of URLs (String) containing the list of URLs of the immediate superior Entities, such as the Trust Anchor or an Intermediate, that MAY issue an Entity Statement related to this subject. * - jwks - - A JSON Web Key Set (JWKS) `RFC 7517 `_ that represents the public part of the signing keys of the Entity at issue. Each JWK in the JWK set MUST have a key ID (claim kid). + - A JSON Web Key Set (JWKS) `RFC 7517 `_ that represents the public part of the signing keys of the Entity at issue. Each JWK in the JWK set MUST have a key ID (claim kid). * - metadata - - Contains the metadata ``wallet_provider`` and the ``federation_entity`` metadata. + - Contains the ``wallet_provider`` and ``federation_entity`` metadata. - -`wallet_provider` metadata +wallet_provider metadata ~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------------------------+---------------------------------------------------------------------+ @@ -157,6 +148,7 @@ Payload | lues_supported | algorithms for the token endpoint. | +---------------------------------------------+---------------------------------------------------------------------+ + .. note:: The `aal_values_supported` parameter is experimental and under review.