Digital Identity Provider
An entity, recognized and accredited by the State, responsible for identifying citizens for the issuance of an Electronic Identity Certificate.
Electronic Attestation of Identity
Electronic attestation of attributes referring to master data already present in Italian digital identity systems.
Digital Credential
Digital Credential
An signed Credential whose integrity can be cryptographically verified using the public keys of its Issuer. It is also known as Credential.
Federation Authority
Federation Authority
A public governance entity that issues guidelines and technical rules, and administers - directly or through its intermediary - Trusted Lists, services, and accreditation processes, the status of participants, and their eligibility evaluation. It also performs oversight functions.
Wallet Instance
Wallet Instance
An instance of the Wallet Solution, installed on a personal mobile device and controlled by a specific User who is its sole owner. It is the application that enables citizens to fully and autonomously manage their digital identity and EAAs.
Wallet Provider
Wallet Provider
All public and/or private entities, conforming to a technical profile and accredited by the Federation Authority, that provide citizens with an IT Wallet Instance.
Wallet Attestation
Wallet Attestation
Verifiable Attestation, issued by the Wallet Provider, that proves the security compliace of the Wallet Instance.
Wallet Secure Cryptographic Device
Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. A WSCD MAY implement an association proof in different ways. This largely depends on the implementation of the WSCD for example: remote HSM, external smart card, internal UICC, internal native cryptographic hardware, such as the iOS Secure Enclave or the Android Hardware Backed Keystore or StrongBox
Credential Status Attestation
Verifiable Attestation proving that a related Digital Credential is not revoked.
Wallet Attestation Service
Device manufacturer service that allows you to certify the authenticity of the mobile app (Wallet Instance).
Device Integrity Service
A service provided by device manufacturers that verifies the integrity and authenticity of the app instance (Wallet Instance), as well as certifying the secure storage of private keys generated by the device within its dedicated hardware. It's important to note that the terminology used to describe this service varies among manufacturers.
Qualified Electronic Attestation of Attributes (QEAA)
Cryptographic Hardware Keys
During the app initialization, the Wallet Instance generates a pair of keys, one public and one private, which remain valid for the entire duration of the Wallet Instance's life. Functioning as a Master Key for the personal device, these Cryptographic Hardware Keys are confined to the OS domain and are not designed for signing arbitrary payloads. Their primary role is to provide a unique identification for each Wallet Instance.
Cryptographic Hardware Key Tag
A unique identifier created by the operating system for the Cryptographic Hardware Keys, utilized to gain access to the private key stored in the hardware.
Key Attestation
An attestation from the device's OEM that enhances your confidence in the keys used in your Wallet Instance being securely stored within the device's hardware-backed keystore.
Qualified Electronic Attestation of Attributes (QEAA)
A digitally verifiable attestation in electronic form, issued by a QTSP, that substantiates a person's possession of attributes.
Qualified Electronic Signature Provider
Qualified Electronic Signature Provider
The Electronic Trust Service Provider responsible for the issuing of Qualified Electronic Signature certificates to the User.
Relying Party
Relying Party
A natural or legal person that implements an authentication system requiring electronic attribute attestation submissions as an authentication mechanism.
Verifier
Verifier
See Relying Party.
Trust Attestation
Trust Attestation
Electronic attestation of an entity's compliance with the national regulatory framework, which is cryptographically verifiable and cannot be repudiated over time by the entity that issued it. A Trust Attestation is always related to a particular Trust Framework.
Trust Layer
Trust Layer
An architectural component that enables IT Wallet system participants to establish trust, in terms of reliability and compliance of all participants with the regulatory framework governing the digital identity system.
Trust Model
Trust Model
System defining how the participants of the ecosystem establish and maintain trust in their interactions. The Trust Model outlines the rules and the procedures for the entities (like users, systems, or applications) should validate each other's identities, authenticate, and establish the level of trust before exchanging information.
Level of Assurance
Level of Assurance
The degree of confidence in the vetting process used to establish the identity of the User and the degree of confidence that the User who presents the credential is the same User to whom the Digital Credential was issued.
Holder Key Binding
Holder Key Binding
Ability of the Holder to prove legitimate possession of the private part, related to the public part attested by a Trusted Third Party.
LoA
Level of Assurance
AAL
Authenticator Assurance Level as defined in https://csrc.nist.gov/glossary/term/authenticator_assurance_level
WSCD
Wallet Secure Cryptographic Device
OpenID Connect Federation 1.0
OpenID Connect Federation 1.0.
T. Lodderstedt, K. Yasuda, T. Looker, "OpenID for Verifiable Credential Issuance", February 2023.
Lodderstedt, K. Yasuda, T. Looker, "OpenID for Verifiable Credential Issuance", February 2023.
O. Terbu, D.Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)".
Terbu, D.Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)".
EUDI Wallet - Architecture and Reference Framework
EUDI Wallet - Architecture and Reference Framework.
OpenID for Verifiable Presentations - draft 19
OpenID for Verifiable Presentations.
Presentation Exchange 2.0 for Presentation Definition
Presentation Exchange 2.0 for Presentation Definition.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" BCP 14, RFC 2119, March 1997.
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999.
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002.
Uniform Resource Identifier (URI): Generic Syntax
Lodderstedt, T., Dronia, S., Scurtescu, M., “OAuth 2.0 Token Revocation,” RFC7009, August 2013.
Uniform Resource Identifier (URI): Generic Syntax.
Bray, T., “The JavaScript Object Notation (JSON) Data Interchange Format,” RFC 7159, March 2014.
Bray, T., “The JavaScript Object Notation (JSON) Data Interchange Format” RFC 7159, March 2014.
Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
Jones, M., Hildebrand, J., "JSON Web Encryption (JWE)", May 2015.
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015.
Jones, M., "JSON Web Algorithms (JWA)", May 2015.
Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.
Jones, M., Sakimura, N., “JSON Web Key (JWK) Thumbprint,”RFC7638, September 2015.
Jones, M., Sakimura, N., “JSON Web Key (JWK) Thumbprint”, September 2015.
Jones, M., Bradley, J. and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, DOI 10.17487/RFC8174, May 2017.
Jones, M., D. Hardt, Sheffer, Y., "JSON Web Token Best Current Practices", February 2020.
Lodderstedt, T., Campbell, B., "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)", November 2022.
The OAuth 2.0 Authorization Framework
The OAuth 2.0 Authorization Framework.
D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite, "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)"
Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite, "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)".
Lodderstedt, T., K. Yasuda, "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC"
Lodderstedt, T., K. Yasuda, "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC".
The Wallet Attestation containing details about the Wallet Instance and the device's security level where the Wallet Instance is installed. It generally attests the authenticity, integrity, security, privacy, and trust of a specific Wallet Instance. The Wallet Attestation MUST contain a Wallet Instance public key.
-The Wallet Attestation:
-MUST be issued and MUST be signed by Wallet Provider;
MUST give all the relevant information to attests the integrity and security of the device where the Wallet Instance is installed.
It is necessary for each Wallet Instance to obtain a Wallet Attestation before entering the Operational state.
-Wallet Attestation contains information regarding the security level of the device hosting the Wallet Instance. It primarily certifies the authenticity, integrity, security, privacy, and trustworthiness of a particular Wallet Instance. The Wallet Attestation MUST contain a Wallet Instance public key.
The following requirements for the Wallet Attestation are met:
-The Wallet Attestation MUST use the signed JSON Web Token (JWT) format.
The Wallet Provider MUST offer a RESTful set of services for issuing the Wallet Attestations.
The Wallet Attestation MUST be securely bound to the Wallet Instance public key (Holder Key Binding).
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 issued and signed by an accredited and reliable Wallet Provider, thereby providing integrity and authenticity to the attestation.
The Wallet Attestation MUST ensure the integrity and authenticity of the Wallet Instance, verifying that it was accurately created and provided by the Wallet Provider.
Each Wallet Instance SHOULD be able to request multiple attestations with different 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 number 10, listed below).
The Wallet Attestation SHOULD 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 SHOULD have an expiration date time, after which it will no longer be considered valid.
When the private key associated with the Wallet Instance is lost or deleted, the attestation MUST become invalid to prevent unauthorized use of the 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 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 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.
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.
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.
+This section describes the Wallet Attestation format and how the Wallet Provider issues it.
-The detailed design is explained below.
-To obtain a Wallet Attestation from the Wallet
-Provider it is necessary to send a Wallet Attestation
-Request from the Wallet Instance containing the associated public key
-, the nonce
value provided by the App Attestation Service and a jti
value.
This section describes the Wallet Attestation format and how the Wallet Provider issues it.
+Step 1:: The User initiates a new operation that necessitates the acquisition of a Wallet Attestation.
+Steps 2-3:: The Wallet Instance checks if a Cryptographic Hardware Key exists and generates an ephemeral asymmetric key pair. The Wallet Instance also:
++++
+- +
MUST ensure that Cryptographic Hardware Keys exist. If they do not exist, it is necessary to reinitialize the Wallet.
- +
MUST generates an ephemeral asymmetric key pair whose public key will be linked with the Wallet Attestation.
- +
MUST check if Wallet Provider is part of the federation and obtain its metadata.
Steps 4-6:: The Wallet Instance solicits a one-time "challenge" from the Wallet Provider Backend. This "challenge" takes the form of a "nonce," which is required to be unpredictable and serves as the main defense against replay attacks. The backend MUST produce the "nonce" in a manner that ensures its single-use within a predetermined time frame.
+GET /nonce HTTP/1.1
+Host: walletprovider.example.com
+
HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+ "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
+}
+
Step 7: The Wallet Instance performs the following actions:
++++
+- +
Creates a
client_data
, a JSON structure that includes the challenge and the ephemeral publicjwk
.- +
Computes a
client_data_hash
by applying the SHA256 algorithm to theclient_data
.
Below a non-normative example of the client_data
.
{
+ "challenge": "0fe3cbe0-646d-44b5-8808-917dd5391bd9",
+ "jwk": {
+ "crv": "P-256",
+ "kty": "EC",
+ "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
+ "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
+ "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
+ }
+}
+
Steps 8-10: The Wallet Instance takes the following steps:
++++
+- +
It produces an hardware_signature by signing the
client_data_hash
with the Wallet Hardware's private key, serving as a proof of possession for the Cryptographic Hardware Keys.- +
It requests the Device Integrity Service to create an
integrity_assertion
linked to theclient_data_hash
.- +
It receives a signed
integrity_assertion
from the Device Integrity Service, authenticated by the OEM.
Note
+integrity_assertion
is a custom payload generated by Device Integrity Service, signed by device OEM and encoded in base64 to have uniformity between different devices.
Constructs the Wallet Attestation Request in the form of a JWT. This JWT includes the integrity_assertion
, hardware_signature
, challenge
, wallet_hardware_key_tag
, and public_jwk
, and is signed using the private key from the initially generated ephemeral key pair.
Submits the Wallet Attestation Request to the Wallet Provider's backend through the token endpoint.
Below an non-normative example of the Wallet Attestation Request JWT without encoding and signature applied:
+{
+ "alg": "ES256",
+ "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
+ "typ": "war+jwt"
+}
+.
+{
+ "iss": "https://wallet-provider.example.org/instance/vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
+ "sub": "https://wallet-provider.example.org/",
+ "challenge": "6ec69324-60a8-4e5b-a697-a766d85790ea",
+ "hardware_signature": "KoZIhvcNAQcCoIAwgAIB...redacted",
+ "integrity_assertion": "o2NmbXRvYXBwbGUtYXBwYX...redacted",
+ "hardware_key_tag": "WQhyDymFKsP95iFqpzdEDWW4l7aVna2Fn4JCeWHYtbU=",
+ "cnf": {
+ "jwk": {
+ "crv": "P-256",
+ "kty": "EC",
+ "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
+ "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
+ "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
+ },
+ "vp_formats_supported": {
+ "jwt_vc_json": {
+ "alg_values_supported": ["ES256K", "ES384"],
+ },
+ "jwt_vp_json": {
+ "alg_values_supported": ["ES256K", "EdDSA"],
+ },
+ },
+ },
+ "iat": 1686645115,
+ "exp": 1686652315
+}
+
The Wallet Instance MUST do an HTTP request to the Wallet Provider's token endpoint, using the method POST.
The token endpoint (as defined in RFC 7523 section 4) requires the following parameters
encoded in application/x-www-form-urlencoded
format:
grant_type
set to urn:ietf:params:oauth:grant-type:jwt-bearer
;
assertion
containing the signed JWT defined in the Section Wallet Attestation Request.
assertion
containing the signed JWT of the Wallet Attestation Request.
Below a non-normative example of the HTTP request.
POST /token HTTP/1.1
Host: wallet-provider.example.org
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
-&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeGRxd2xVTl9LWl83NTVUT1ZEbmJIaDg2TW1KcHh2a1UifQ.eyJpc3MiOiAidmJlWEprc000NXhwaHRBTm5DaUc2bUN5dVU0amZHTnpvcEd1S3ZvZ2c5YyIsICJhdWQiOiAiaHR0cHM6Ly93YWxsZXQtcHJvdmlkZXIuZXhhbXBsZS5vcmciLCAianRpIjogImY1NjUyMDcyLWFiZWYtNDU5OS1iODYzLTlhNjkwNjA3MzJjYyIsICJub25jZSI6ICIuLi4uLiIsICJjbmYiOiB7Imp3ayI6IHsiY3J2IjogIlAtMjU2IiwgImt0eSI6ICJFQyIsICJ4IjogIjRITnB0SS14cjJwanlSSktHTW56NFdtZG5RRF91SlNxNFI5NU5qOThiNDQiLCAieSI6ICJMSVpuU0IzOXZGSmhZZ1MzazdqWEU0cjMtQ29HRlF3WnRQQklScXBObHJnIiwgImtpZCI6ICJ2YmVYSmtzTTQ1eHBodEFObkNpRzZtQ3l1VTRqZkdOem9wR3VLdm9nZzljIn19LCAiaWF0IjogMTY5MTQ4ODk2MiwgImV4cCI6IDE2OTE0OTYxNjJ9.Dg_yFaiv6lVftR3FFx0v5JW250mBgXLVP1j0ezZcHRyitqSY7xGmx4y-MGur93FAS85vf_Da-L-REVEltwU2Jw
+&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeG...
The response is the Wallet Attestation in JWT format:
+Steps 13-17: The Wallet Provider's backend assesses the Wallet Attestation Request and issues a Wallet Attestation, if the requirements described below are satisfied:
++++
+- +
It MUST check the Wallet Attestation Request contains all the defined parameters according to Table of the Wallet Attestation Request parameters.
- +
It MUST verify that the signature of the received Wallet Attestation Request is valid and associated with public
jwk
.- +
It MUST verify that the
challenge
was generated by Wallet Provider and has not already been used.- +
It MUST check that there is a Wallet Instance registered with that
hardware_key_tag
and that it is still valid.- +
It MUST reconstruct the
client_data
via thechallenge
and thejwk
public key, to validatehardware_signature
via the Cryptographic Hardware Key public key registered and associated with the Wallet Instance.- +
It MUST validate the
integrity_assertion
as defined by the device manufacturers' guidelines.- +
It MUST verify that the device in use has no security flaws and reflects the minimum security requirements defined by the Wallet Provider.
- +
It MUST check that the URL in
iss
parameter is equal to the URL identifier of Wallet Provider.
If all checks are passed, Wallet Provider issues a Wallet Attestation with an expiration limited to 24 hours.
+Below an non-normative example of the Wallet Attestation without encoding and signature applied:
+ {
+ "alg": "ES256",
+ "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
+ "trust_chain": [
+ "eyJhbGciOiJFUz...6S0A",
+ "eyJhbGciOiJFUz...jJLA",
+ "eyJhbGciOiJFUz...H9gw",
+ ],
+ "typ": "wallet-attestation+jwt",
+}
+.
+{
+ "iss": "https://wallet-provider.example.org",
+ "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
+ "aal": "https://trust-list.eu/aal/high",
+ "cnf":
+ {
+ "jwk":
+ {
+ "crv": "P-256",
+ "kty": "EC",
+ "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
+ "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
+ "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
+ }
+ },
+ "authorization_endpoint": "eudiw:",
+ "response_types_supported": [
+ "vp_token"
+ ],
+ "response_modes_supported": [
+ "form_post.jwt"
+ ],
+ "vp_formats_supported": {
+ "vc+sd-jwt": {
+ "sd-jwt_alg_values": [
+ "ES256",
+ "ES384"
+ ]
+ }
+ },
+ "request_object_signing_alg_values_supported": [
+ "ES256"
+ ],
+ "presentation_definition_uri_supported": false,
+ "iat": 1687281195,
+ "exp": 1687288395
+}
+
Step 18: The Wallet Instance receives the Wallet Attestation signed by the Wallet Provider and performs security and integrity verifications.
HTTP/1.1 201 OK
Content-Type: application/jwt
-eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGxldC1hdHRlc3RhdGlvbitqd3QiLCJraWQiOiI1dDVZWXBCaE4tRWdJRUVJNWlVenI2cjBNUjAyTG5WUTBPbWVrbU5LY2pZIiwidHJ1c3RfY2hhaW4iOlsiZXlKaGJHY2lPaUpGVXouLi42UzBBIiwiZXlKaGJHY2lPaUpGVXouLi5qSkxBIiwiZXlKaGJHY2lPaUpGVXouLi5IOWd3Il19.eyJpc3MiOiJodHRwczovL3dhbGxldC1wcm92aWRlci5leGFtcGxlLm9yZyIsInN1YiI6InZiZVhKa3NNNDV4cGh0QU5uQ2lHNm1DeXVVNGpmR056b3BHdUt2b2dnOWMiLCJ0eXBlIjoiV2FsbGV0SW5zdGFuY2VBdHRlc3RhdGlvbiIsInBvbGljeV91cmkiOiJodHRwczovL3dhbGxldC1wcm92aWRlci5leGFtcGxlLm9yZy9wcml2YWN5X3BvbGljeSIsInRvc191cmkiOiJodHRwczovL3dhbGxldC1wcm92aWRlci5leGFtcGxlLm9yZy9pbmZvX3BvbGljeSIsImxvZ29fdXJpIjoiaHR0cHM6Ly93YWxsZXQtcHJvdmlkZXIuZXhhbXBsZS5vcmcvbG9nby5zdmciLCJhdHRlc3RlZF9zZWN1cml0eV9jb250ZXh0IjoiaHR0cHM6Ly93YWxsZXQtcHJvdmlkZXIuZXhhbXBsZS5vcmcvTG9BL2Jhc2ljIiwiY25mIjp7Imp3ayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6IjRITnB0SS14cjJwanlSSktHTW56NFdtZG5RRF91SlNxNFI5NU5qOThiNDQiLCJ5IjoiTElablNCMzl2RkpoWWdTM2s3alhFNHIzLUNvR0ZRd1p0UEJJUnFwTmxyZyIsImtpZCI6InZiZVhKa3NNNDV4cGh0QU5uQ2lHNm1DeXVVNGpmR056b3BHdUt2b2dnOWMifX0sImF1dGhvcml6YXRpb25fZW5kcG9pbnQiOiJldWRpdzoiLCJyZXNwb25zZV90eXBlc19zdXBwb3J0ZWQiOlsidnBfdG9rZW4iXSwidnBfZm9ybWF0c19zdXBwb3J0ZWQiOnsiand0X3ZwX2pzb24iOnsiYWxnX3ZhbHVlc19zdXBwb3J0ZWQiOlsiRVMyNTYiXX0sImp3dF92Y19qc29uIjp7ImFsZ192YWx1ZXNfc3VwcG9ydGVkIjpbIkVTMjU2Il19fSwicmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCI6WyJFUzI1NiJdLCJwcmVzZW50YXRpb25fZGVmaW5pdGlvbl91cmlfc3VwcG9ydGVkIjpmYWxzZSwiaWF0IjoxNjg3MjgxMTk1LCJleHAiOjE2ODcyODgzOTV9.tNvCyFPCL5tUi2NakKwdaG9xbrtWWl4djSRYRfHrF8NdmffdT044U55pRn35J2cl0LZxbesEDrfSAz2pllw2Ug
+eyJhbGciOiJFUzI1NiIsInR5cCI6IndhbGx... redacted
Below are described the JWT headers and the payload claims -of the assertion used in the request.
-The JOSE header of the Wallet Attestation Request JWT MUST contain:
key |
-value |
+|||||
JOSE header |
+Description |
+Reference |
||||
---|---|---|---|---|---|---|
alg |
-Algorithm to verify the token -signature (es. ES256). |
+|||||
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 Section Cryptographic Algorithms and MUST NOT be set to |
+|||||
kid |
-Key id of the public key -created by the Wallet Instance. |
+|||||
kid |
+Unique identifier of the |
+|||||
typ |
-Media type, set to
- |
+|||||
typ |
+It MUST be set to |
+
The body of the Wallet Attestation Request JWT MUST contain:
Claim |
+Description |
+Reference |
+
---|---|---|
key |
-value |
+|
iss |
+Identifier of the Wallet Provider concatenated with thumbprint of the JWK in the |
+|
-
-iss
- |
-
-
-Thumbprint value
-of the JWK of the Wallet Instance
-for which the attestation is
-being requested.
- |
+|
aud |
+It MUST be set to the identifier of the Wallet Provider. |
+|
-
-aud
- |
-
-
-The public url of the Wallet
-Provider.
- |
+|
exp |
+UNIX Timestamp with the expiry time of the JWT. |
+|
-
-jti
- |
-- | +|
iat |
+UNIX Timestamp with the time of JWT issuance. |
+|
-
-nonce
- |
-
-
-The nonce value obtained from the
-App Attestation Service.
- |
+|
challenge |
+Challenge data obtained from |
+|
-
-cnf
- |
-
-
-JSON object, according to
-
-containing the public part of an asymmetric key pair owned
-by the Wallet Instance.
- |
+|
hardware_signature |
+The signature of |
+|
-
-iat
- |
-
-
-Unix timestamp of attestation request
-issuance time.
- |
+|
integrity_assertion |
+The integrity assertion obtained from the Device Integrity Service with the holder binding of |
+|
-
-exp
- |
-
-
-Unix timestamp regarding the
-expiration date time.
- |
+|
hardware_key_tag |
+Unique identifier of the Cryptographic Hardware Keys |
++ |
cnf |
+JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance. |
+
Below a non-normative example of the Wallet Attestation -request where the decoded JWS headers and payload are separated by a comma:
-{
- "alg": "ES256",
- "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
- "typ": "wiar+jwt"
-}
-.
-{
- "iss": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
- "aud": "https://wallet-provider.example.org",
- "jti": "6ec69324-60a8-4e5b-a697-a766d85790ea",
- "nonce" : ".....",
- "cnf": {
- "jwk": {
- "crv": "P-256",
- "kty": "EC",
- "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
- "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
- "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
- }
- },
- "iat": 1686645115,
- "exp": 1686652315
-}
-
Whose corresponding JWS is verifiable using the public part of an asymmetric -key pair owned by the Wallet Instance that has a key id which is the same -as the kid made available in the JWS header.
-The Wallet Attestation MUST be provisioned in JWT format, with -headers and payload claims are listed below.
-The JOSE header of the Wallet Attestation JWT MUST contain:
key |
-value |
-|||||
alg |
-Algorithm to verify the token -signature (es. ES256). |
+|||||
JOSE header |
+Description |
+Reference |
||||
---|---|---|---|---|---|---|
kid |
-The key id of the key used by the -Wallet Provider to sign the -attestation. |
+|||||
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 Section Cryptographic Algorithms and MUST NOT be set to |
+|||||
typ |
-Media type, set to -wallet-attestation+jwt, -according to -[OPENID4VC-HAIP] |
+|||||
kid |
+Unique identifier of the |
+|||||
x5c |
-Array containing the X.509 -chain -of certificates used to attest -the public key of the Wallet -Provider. |
+|||||
typ |
+It MUST be set to |
+|||||
trust_chain |
-Array containing the Federation -Trust Chain relating to the -Wallet Provider. |
+|||||
trust_chain |
+Sequence of Entity Statements that composes the Trust Chain related to the Relying Party. |
+OIDC-FED Section 3.2.1. Trust Chain Header Parameter. |
Note
-One of the claims trust_chain and x5c MUST be provisioned. -If they are both provided, the related public key -MUST be the same in both trust_chain and x5c.
-The body of the Wallet Attestation JWT MUST contain:
key |
-value |
+|||||
Claim |
+Description |
+Reference |
||||
---|---|---|---|---|---|---|
-
-iss
- |
-
-
-The public url of the Wallet Provider
- |
+|||||
iss |
+Identifier of the Wallet Provider |
+|||||
-
-sub
- |
-
-
-Thumbprint value
-of the JWK of the Wallet Instance
-for which the attestation is
-being issued.
- |
+|||||
aud |
+Identifier of the Wallet Provider concatenated with thumbprint of the Wallet Instance. |
+|||||
-
-iat
- |
-
-
-Unix timestamp of attestation
-issuance time.
- |
+|||||
exp |
+UNIX Timestamp with the expiry time of the JWT. |
+|||||
-
-exp
- |
-
-
-Unix timestamp regarding the
-expiration date time.
-A good practice to avoid security
-problems is to have a limited
-duration of the attestation.
- |
+|||||
iat |
+UNIX Timestamp with the time of JWT issuance. |
+|||||
-
-aal
- |
-
-
-JSON String asserting the authentication level
-of the Wallet and the key as asserted in
-the cnf claim.
- |
+|||||
cnf |
+JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance. |
+|||||
-
-cnf
- |
-
-
-This parameter contains the
-jwk parameter
-with the public key of the Wallet Instance
-necessary for the Holder Key Binding.
- |
+|||||
aal |
+JSON String asserting the authentication level of the Wallet and the key as asserted in the cnf claim. |
+|||||
-
-authorization_endpoint
- |
-
-
-URL of the SIOPv2
-Authorization Endpoint.
- |
+|||||
authorization_endpoint |
+URL of the Wallet Authorization Endpoint (Universal Link). |
+|||||
-
-response_types_supported
- |
-
-
-JSON array containing a list of
-the OAuth 2.0
-response_type values. |
+|||||
response_types_supported |
+JSON array containing a list of the OAuth 2.0 |
+|||||
-
-response_modes_supported
- |
-
-
-JSON array containing a list of the OAuth 2.0
-"response_mode" values that this
-authorization server supports.
-
- |
+|||||
response_modes_supported |
+JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports. |
+|||||
-
-vp_formats_supported
- |
-
-
-JSON object with name/value pairs,
-identifying a Credential format supported
-by the Wallet.
- |
+|||||
vp_formats_supported |
+JSON object with name/value pairs, identifying a Credential format supported by the Wallet. |
+|||||
-
-request_object_signing
-_alg_values_supported
- |
-
-
-JSON array containing a list of the
-JWS signing algorithms (alg values)
-supported.
- |
+|||||
request_object_signing_alg_values_supported |
+JSON array containing a list of the JWS signing algorithms (alg values) supported. |
+|||||
-
-presentation_definition
-_uri_supported
- |
-
-
-Boolean value specifying whether the
-Wallet Instance supports the transfer of
-presentation_definition byreference. MUST set to false.
- |
+|||||
presentation_definition_uri_supported |
+Boolean value specifying whether the Wallet Instance supports the transfer of presentation_definition by reference. MUST be set to false. |
+
Below is an example of Wallet Attestation:
-{
- "alg": "ES256",
- "kid": "5t5YYpBhN-EgIEEI5iUzr6r0MR02LnVQ0OmekmNKcjY",
- "trust_chain": [
- "eyJhbGciOiJFUz...6S0A",
- "eyJhbGciOiJFUz...jJLA",
- "eyJhbGciOiJFUz...H9gw",
- ],
- "typ": "wallet-attestation+jwt",
-}
-.
-{
- "iss": "https://wallet-provider.example.org",
- "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c",
- "aal": "https://trust-list.eu/aal/high",
- "cnf":
- {
- "jwk":
- {
- "crv": "P-256",
- "kty": "EC",
- "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
- "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
- "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
- }
- },
- "authorization_endpoint": "eudiw:",
- "response_types_supported": [
- "vp_token"
- ],
- "response_modes_supported": [
- "form_post.jwt"
- ],
- "vp_formats_supported": {
- "vc+sd-jwt": {
- "sd-jwt_alg_values": [
- "ES256",
- "ES384"
- ]
- }
- },
- "request_object_signing_alg_values_supported": [
- "ES256"
- ],
- "presentation_definition_uri_supported": false,
- "iat": 1687281195,
- "exp": 1687288395
-}
-
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. Designed to provide a seamless User experience, this solution enables Users to leverage the capabilities of the Wallet effectively.
-The Wallet Solution 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 mobile app serves as the primary interface for Users, allowing them to access and interact with their digital assets conveniently. These digital assets, known as Attestations, include Personal Identification Data (PID[1]), 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 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 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.
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.
+The Wallet Provider MUST offer a RESTful set of services for issuing the Wallet Attestations.
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.
- @@ -1085,28 +1080,28 @@
Trustworthiness within the Wallet ecosystem: the Wallet Instance MUST establish trust and reliability within the Wallet ecosystem.
Requirements
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 identity for the User, enabling them 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, reference the public part of the asymmetric cryptographic key owned by the Wallet Instance. Their purpose is to authenticate the Wallet Instance itself, ensuring its realiability when engaging with other ecosystem actors.
-To guarantee the utmost security, these cryptographic keys are securely stored within the device's Trusted Execution Environment (TEE)[3]. 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.
+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 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.
+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.
Wallet Instance Lifecycle¶
The Wallet Instance has three distinct states: Operational, Valid, and Deactivated. Each state represents a specific functional status and determines the actions that can be performed[2].
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, 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.
After completing these steps, the Wallet Instance sets 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.
-In order to securely and unambiguously identify Users, the Wallet Instance adopts a Level of Assurance (LoA) 3 authentication, which guarantees a high level of confidence in the User's identity. The authentication method is chosen by the PID Provider from among the notified eID solutions at the national level.
+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.
Once the Wallet Instance is in the Operational 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.
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.
diff --git a/versione-corrente/it/.doctrees/environment.pickle b/versione-corrente/it/.doctrees/environment.pickle index 1b2b2089c..8adad33b1 100644 Binary files a/versione-corrente/it/.doctrees/environment.pickle and b/versione-corrente/it/.doctrees/environment.pickle differ