diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 2df499f5..77d62256 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -125,7 +125,7 @@ The PID/(Q)EAA Provider performs the following checks upon the receipt of the PA 2. It MUST check that the used algorithm for signing the request in the ``alg`` header is one of the listed within the Section `Cryptographic Algorithms `_. 3. It MUST check that the ``client_id`` in the request body of the PAR request matches the ``client_id`` claim included in the Request Object. 4. It MUST check that the ``iss`` claim in the Request Object matches the ``client_id`` claim in the Request Object (:rfc:`9126`, :rfc:`9101`). - 5. It MUST check that the ``aud`` claim in the Request Object is equal to the PID/(Q)EAA Provider authorization endpoint uri (:rfc:`9126`, :rfc:`9101`). + 5. It MUST check that the ``aud`` claim in the Request Object is equal to the identifier of the PID/(Q)EAA Provider (:rfc:`9126`, :rfc:`9101`). 6. It MUST reject the PAR request, if it contains the ``request_uri`` parameter (:rfc:`9126`). 7. It MUST check that the Request Object contains all the mandatory parameters which values are validated according to :ref:`Table of the HTTP parameters ` [derived from :rfc:`9126`]. 8. It MUST check that the Request Object is not expired, checking the ``exp`` claim. @@ -943,7 +943,7 @@ The JWT proof type MUST contain the following parameters for the JOSE header and - The value of this claim MUST be the **client_id** of the Wallet Instance. - [`OpenID4VCI`_], [:rfc:`7519`, Section 4.1.1]. * - **aud** - - The value of this claim MUST be the identifier URL of the PID/(Q)EAA Issuer. + - It MUST be set to the identifier of the PID/(Q)EAA Provider. - [`OpenID4VCI`_]. * - **iat** - UNIX Timestamp with the time of JWT issuance, coded as NumericDate as indicated in :rfc:`7519`. diff --git a/docs/en/remote-flow.rst b/docs/en/remote-flow.rst index bfda1118..07c28afd 100644 --- a/docs/en/remote-flow.rst +++ b/docs/en/remote-flow.rst @@ -3,7 +3,6 @@ .. _Trust Model: trust.html - Remote Flow =========== @@ -437,7 +436,7 @@ Where the following parameters are used: * - **vp_token** - JSON Array containing the Verifiable Presentation(s). There MUST be at least two signed presentations in this Array: - - The requested Digital Credential (one or more, in format of SD-JWT VC or MDOC CBOR) + - The requested Digital Credential (one or more, in format of SD-JWT VC) - The Wallet Attestation * - **presentation_submission** - JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the `Presentation Exchange `_. This is expressed via elements in the ``descriptor_map`` array (Input Descriptor Mapping Objects) that contain a field called ``path``, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where ``n`` is the index to select. The Relying Party receiving the `presentation_submission` descriptor therefore is able to use the correct method to decode each credential data format provided within the ``vp_token``. @@ -446,7 +445,7 @@ Where the following parameters are used: The items contained in the ``vp_token`` array are Verifiable Presentations of Credentials. -Both SD-JWT and mdoc CBOR provide indications for the presentation, according to their specifications. + SD-JWT Presentation ------------------- @@ -460,7 +459,7 @@ by appending the ``KB-JWT`` at the end of the of the SD-JWT, as represented in t ~~~...~~ To validate the signature on the Key Binding JWT, the Verifier MUST use the key material included in the Issuer-Signed-JWT. -The Key Binding JWT MUST specify which key material the Verifier needs to use to validate the Key Binding JWT signature, +The Key Binding JWT (KB-JWT) signature validation MUST use the public key included in the SD-JWT, using the ``cnf`` parameter contained in the Issuer-Signed-JWT. When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS header: @@ -495,10 +494,18 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in - REQUIRED. The base64url-encoded hash digest over the Issuer-signed JWT and the selected disclosures. -MDOC-CBOR Presentation ----------------------- +Revocation Checks +~~~~~~~~~~~~~~~~~ + +The revocation mechanisms that the Relying Parties MUST implement are defined in the section (:ref:`Revocations `). + +In the context of Digital Credential evaluation, any Relying Parties (RPs) establishes internal policies that define the meaning and value of presented Credentials. This is particularly important in scenarios where a Credential may be suspended but still holds value for certain purposes. For example, a suspended mobile driving license might still be valid for verifying the age of the holder. + +The process begins with the RP requesting specific Credentials from the Holder. This request should align with the Relying Party's requirements and the context in which the Credentials will be used. The Holder then responds by releasing the requested Credentials. + +Upon receiving the Credentials, the Relying Party evaluates their validity and value based on its internal policies. This evaluation considers the current status of the Credential (e.g., active, suspended, revoked) and the specific use case for which the Credential is being presented. -TBD. +Relying Parties should develop comprehensive internal policies that outline how different types of Credentials are to be evaluated. These policies should address scenarios where a Credential may be partially valid or have limited applicability. Flexibility in evaluation processes is important to accommodate various use cases. For instance, a Credential that is suspended for driving purposes might still be acceptable for age verification. Authorization Response Errors diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e43cc210..867861e0 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -140,7 +140,7 @@ The request MUST be signed with the private key related to the public key contai Host: pid-provider.example.org Content-Type: application/json - revocation_requests : ["${base64url(json({typ: (some pop for revocation-assertion)+jwt, ...}))}.payload.signature", ... ] + revocation_requests : ["${base64url(json({typ: revocation-assertion+jwt, ...}))}.payload.signature", ... ] Below, is given a non-normative example of a single Revocation Assertion Request object with decoded JWT headers and payload and without signature for better readability: @@ -164,7 +164,7 @@ Below, is given a non-normative example of a single Revocation Assertion Request "credential_hash_alg": "sha-256" } -**Step 2 (PoP verification)**: The Credential Issuer verifies the proof of possession of the Credential requested to be revoked, using the the confirmation method that was attested in the Credential. If the verification is successful the revocation request is allowed. +**Step 2 (Revocation Assertion Request verification)**: The Credential Issuer verifies the proof of possession of the Credential requested to be revoked, using the the confirmation method that was attested in the Credential. If the verification is successful the revocation request is allowed. **Step 3 (Credential Revocation)**: The Credential Issuer revokes the Credential provided in the Revocation Request object. After the revocation, the Credential Issuer MAY also send a notification to the User (e.g. using a User's email address, telephone number, or any other verified and secure communication channel), with all needed information related to the Credential revocation status update. This communication is out of scope of the current technical implementation profile. @@ -379,7 +379,7 @@ Below a non-normative example representing a Status Assertion Request array with Content-Type: application/json { - "status_assertion_requests" : ["${base64url(json({typ: (some pop for status-assertion)+jwt, ...}))}.payload.signature", ... ] + "status_assertion_requests" : ["${base64url(json({typ: status-assertion+jwt, ...}))}.payload.signature", ... ] } The Status Assertion HTTP request can be sent to a single Credential Issuer regarding multiple Digital Credentials, and MUST contain a JSON object with the member `status_assertion_requests`. @@ -387,7 +387,7 @@ The `status_assertion_requests` MUST be set with an array of strings, where each A non-normative example of Credential Proof of Possession is provided :ref:`in the previous section `. -**Step 2 (PoP verification)**: The Credential Issuer that receives the Status Assertion Request object MUST validate that the Wallet Instance making the request is authorized to request Status Assertions. Therefore the following requirements MUST be satisfied: +**Step 2 (Status Assertion Request verification)**: The Credential Issuer that receives the Status Assertion Request object MUST validate that the Wallet Instance making the request is authorized to request Status Assertions. Therefore the following requirements MUST be satisfied: - The Credential Issuer MUST verify the compliance of all elements in the `status_assertion_requests` object using the confirmation method contained within the Digital Credential where the Status Assertion Request object is referred to; @@ -605,7 +605,7 @@ The Credential Proof of Possession (**credential_pop**) MUST be a JWT that MUST - UNIX Timestamp with the time of JWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **jti** - - Unique identifier for the PoP proof JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. + - Unique identifier for the proof of possession JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. - :rfc:`7519#section-4.1.7`. * - **credential_hash** - It MUST contain the hash value of a Digital Credential, derived by computing the base64url encoded hash of the Digital Credential. diff --git a/docs/en/trust.rst b/docs/en/trust.rst index cfd609d1..2ee1d9a0 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -74,15 +74,39 @@ General Properties The architecture of the trust infrastructure based on OpenID Federation is built upon several core principles: -- [P1] **Security**: incorporates mechanisms to ensure the integrity, confidentiality, and authenticity of the trust relationships and interactions within the federation. -- [P2] **Privacy**: designed to respect and protect the privacy of the entities and individuals involved, minimal disclosure is part of this. -- [P3] **Interoperability**: supports seamless interaction and trust establishment between diverse systems and entities within the federation. -- [P4] **Transitive Trust**: trust established indirectly through a chain of trusted relationships, enabling entities to trust each other based on common authorities and trusted intermediaries. -- [P6] **Scalability**: designed to efficiently manage an increasing number of entities or interactions without a significant increase in trust management complexity. -- [P5] **Delegation**: technical ability/feature to delegate authority or responsibilities to other entities, allowing for a distributed trust mechanism. -- [P7] **Flexibility**: adaptable to various operational and organizational needs, allowing entities to define and adjust their trust relationships and policies. -- [P8] **Autonomy**: while part of a federated ecosystem, each entity retains control over its own definitions and configurations. -- [P9] **Decentralization**: unlike traditional centralized systems, the OpenID Federation model promotes a decentralized approach. This ensures that no single entity has control over the entire system, enhancing privacy and security for all participants. +.. list-table:: + :header-rows: 1 + + * - Identifier + - Property + - Description + * - P1 + - **Security** + - Incorporates mechanisms to ensure the integrity, confidentiality, and authenticity of the trust relationships and interactions within the federation. + * - P2 + - **Privacy** + - Designed to respect and protect the privacy of the entities and individuals involved, minimal disclosure is part of this. + * - P3 + - **Interoperability** + - Supports seamless interaction and trust establishment between diverse systems and entities within the federation. + * - P4 + - **Transitive Trust** + - Trust established indirectly through a chain of trusted relationships, enabling entities to trust each other based on common authorities and trusted intermediaries. + * - P5 + - **Delegation** + - Technical ability/feature to delegate authority or responsibilities to other entities, allowing for a distributed trust mechanism. + * - P6 + - **Scalability** + - Designed to efficiently manage an increasing number of entities or interactions without a significant increase in trust management complexity. + * - P7 + - **Flexibility** + - Adaptable to various operational and organizational needs, allowing entities to define and adjust their trust relationships and policies. + * - P8 + - **Autonomy** + - While part of a federated ecosystem, each entity retains control over its own definitions and configurations. + * - P9 + - **Decentralization** + - Unlike traditional centralized systems, the OpenID Federation model promotes a decentralized approach. This ensures that no single entity has control over the entire system, enhancing privacy and security for all participants. Trust Infrastructure Functional Requirements ---------------------------------------------- @@ -94,63 +118,63 @@ This section includes the requirements necessary for the successful implementati * - ID - Description - * - [FR #1] + * - FR1 - **Federation Trust Establishment**: the system must be able to establish trust between different entities (Credential Issuers, Relying Parties, etc.) within a federation, using cryptographic signatures for secure information exchange about the participants in the ecosystem. - * - [FR #2] + * - FR2 - **Entity Authentication**: the system must implement mechanisms for authenticating entities within the federation, ensuring compliance with the shared rules. - * - [FR #3] + * - FR3 - **Signature Validation**: the system must support the creation, verification, and validation of electronic signatures and provide standard and secure mechanisms to obtain the public keys required for the signature validation. - * - [FR #4] + * - FR4 - **Time Stamping**: the signed artifacts must contain time stamps to ensure the integrity and non-repudiation of transactions over time, thanks to the interfaces, services, storage model and approaches defined within the federation. - * - [FR #5] + * - FR5 - **Certificate Validation**: the system requires confidential transmission, secured via TLS over HTTP, and validation of certificates for website authentication, ensuring they meet eIDAS criteria. - * - [FR #6] + * - FR6 - **Interoperability and Standards Compliance**: ensure interoperability between federation members by adhering to technical standards, facilitating cross-border electronic transactions. - * - [FR #7] + * - FR7 - **Data Protection and Privacy**: implement data protection measures in compliance with GDPR and eIDAS regulations, ensuring the privacy and security of personal data processed within the federation. - * - [FR #8] + * - FR8 - **User Consent and Control**: design mechanisms for obtaining and managing user consent, empowering users with control over their personal information. - * - [FR #9] + * - FR9 - **Audit and Logging**: the system must minimize data, anonymize if possible, define retention periods, secure access, and storage encryption. This protects privacy while enabling security and accountability. - * - [FR #10] + * - FR10 - **Dispute Resolution and Liability**: establish clear procedures for dispute resolution and define liability among federation members, in accordance with eIDAS provisions. - * - [FR #11] + * - FR11 - **Accessibility**: ensure that the system is accessible to all users, including those with disabilities, aligning with eIDAS and local accessibility standards. - * - [FR #12] + * - FR12 - **Emergency and Revocation Services**: implement mechanisms for the immediate revocation of electronic identification means and participants in case of security breaches or other emergencies. - * - [FR #13] + * - FR13 - **Scalable Trust Infrastructure**: the system must support scalable trust establishment mechanisms, leveraging approaches and technical solutions that complement delegation transitive approaches to efficiently manage trust relationships as the federation grows, removing central registries that might technically or administratively fail. - * - [FR #14] + * - FR14 - **Efficient Storage Scalability**: implement a storage solution that scales horizontally to accommodate increasing data volumes while minimizing central storage and administrative costs. The system should enable members to independently store and present historical trust attestations and signed artifacts during dispute resolutions, with the federation infrastructure maintaining only a registry of historical keys to validate the historical data, stored and provided by the participants. - * - [FR #15] + * - FR15 - **Verifiable Attestation (Trust Mark)**: incorporate a mechanism for issuing and verifying verifiable attestations that serve as proof of compliance with specific profiles or standards. This allows entities within the federation to demonstrate adherence to agreed-upon security, privacy, and operational standards. - * - [FR #16] + * - FR16 - **Dynamic Policy Language**: develop and implement a dynamic, extensible policy language that allows for the creation and modification of federation policies in response to evolving requirements, technological advancements, and regulatory changes. This policy language should support the specification of rules governing entity behavior, metadata handling, and trust validation within the federation. - * - [FR #17] + * - FR17 - **Automated Policy Enforcement**: the system must automatically enforce federation policies as defined by policy language and verifiable attestations, ensuring that all operations and transactions comply with current rules and standards. - * - [FR #18] + * - FR18 - **Decentralized Dispute Resolution Mechanism**: design a decentralized mechanism for dispute resolution that allows federation members to independently verify historical trust establishment and signed artifacts, reducing reliance on central authorities and streamlining the resolution process. - * - [FR #19] + * - FR19 - **Adaptive Load Management**: implement adaptive load management strategies to ensure the system remains responsive and efficient under varying loads, particularly during peak usage times or when processing complex tasks. - * - [FR #20] + * - FR20 - **Cross-Federation Interoperability**: ensure the system is capable of interoperating with other federations or trust frameworks, facilitating cross-federation transactions and trust establishment without compromising security or compliance. - * - [FR #21] + * - FR21 - **Future-Proof Cryptography**: the system should employ a flexible cryptographic framework that can be updated in response to new threats or advancements in cryptographic research, ensuring long-term security and integrity of federation operations. - * - [FR #22] + * - FR22 - **Autonomous Registration Bodies**: the system must facilitate the integration of autonomous registration bodies that operate in compliance with federation rules. These bodies are tasked with evaluating and registering entities within the federation, according to the pre-established rules and their compliance that must be periodically asserted. - * - [FR #23] + * - FR23 - **Compliance Evaluation for Federation Entity Candidates**: registration bodies must evaluate the compliance of candidate entities against federation standards before their registration in the federation. - * - [FR #24] + * - FR24 - **Periodic Auditing of Registration Bodies and Entities**: implement mechanisms for the periodic auditing and monitoring of the compliance status of both registration bodies and their registered entities. This ensures ongoing adherence to federation standards and policies. - * - [FR #25] + * - FR25 - **Certification of Compliance for Personal Devices**: trusted bodies, in the form of federation entities, should issue certifications of compliance and provide signed proof of such compliance for the hardware of personal devices used within the federation. These certifications should be attested and periodically renewed to ensure the devices meet current security standards. - * - [FR #26] + * - FR26 - **Certification of Compliance for Cryptographic Devices**: similar to personal devices, personal cryptographic devices used within the federation must also receive certifications of compliance and signed proof thereof from trusted bodies. These certifications should be subject to periodic renewal to reflect the latest security and compliance standards. - * - [FR #27] + * - FR27 - **Transparent Compliance Reporting**: develop a system for transparent reporting and publication of compliance statuses, audit results, and certification renewals for all federation entities. This transparency fosters trust within the federation and with external stakeholders. - * - [FR #28] + * - FR28 - **Automated Compliance Monitoring**: the system should include automated tools for monitoring the compliance of entities with federation standards. This automation aids in the early detection of potential compliance issues. - * - [FR #29] + * - FR29 - **Secure Protocol Capabilities Binding**: the secure protocol must enable the exchange of protocol-specific capabilities data as cryptographically-bound metadata attached to a specific identity. This metadata should define the technical capabilities associated with the identity, ensuring verifiable proof and tamper-proof association for robust trust establishment and access control. @@ -255,9 +279,6 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e "https://registry.spid.eidas.trust-anchor.example.eu", "https://private.other.intermediary.org" ] - }, - "constraints": { - "max_path_length": 1 } } @@ -558,6 +579,8 @@ The Entity Statement issued by Trust Anchors and Intermediates contains the foll Trust Evaluation Mechanism -------------------------- +Trust Anchors MUST distribute their Federation Public Keys through secure out-of-band mechanisms, such as publishing them on a verified web page or storing them in a remote repository as part of a trust list. The rationale behind this requirement is that relying solely on the data provided within the Trust Anchor's Entity Configuration does not adequately mitigate risks associated with DNS and TLS manipulation attacks. To ensure security, all participants MUST obtain the Trust Anchor's public keys using these out-of-band methods. They should then compare these keys with those obtained from the Trust Anchor's Entity Configuration, discarding any keys that do not match. This process helps to ensure the integrity and authenticity of the Trust Anchor's public keys and the overall security of the federation. + The Trust Anchor publishes the list of its Subordinates (Federation Subordinate Listing endpoint) and the attestations of their metadata and public keys (Entity Statements). Each participant, including Trust Anchor, Intermediate, Credential Issuer, Wallet Provider, and Relying Party, publishes its own metadata and public keys (Entity Configuration endpoint) in the well-known web resource **.well-known/openid-federation**. diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index d7920090..5c2b9e16 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -59,14 +59,14 @@ 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 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 + :target: https://www.plantuml.com/plantuml/uml/ZLJ1RjD04BtlLupQ0sqKVY07L5H2MXKe8WKkNCRsn1d5tZMpiu7mzSpQROYZK3WuMis-z-QzjrAkeg9eQXk7IODFRK7YrbmHh4BG8lnqBpe3SCaTUdKEImq2PvyZoHbWX1GDVu20iw_ODAHmwqtPbzIZiEjWZ7f3Mox9K4griEvWIP8d0nmrmddiX7rT2v4_kU6ZXAqP5IYmt92lUcfHRfoh9QGEWczsaBhWOSKI5TWS6HELRHHMe6lAnboEyFALdMRGbn6VRk1Y81hWCWVdBUf0iU-HSRscSWCyg5L3g9ReKQHbpsrg8LAP-fH2tnCBjUGrVlFegqoTJFxMncG2706to0qM3JadFYX1s99a7rDB2-VlRXSt3ujFy_a7DxWvxiSaSdzFcT-I3OSMie5GAB87rcZ65IjKTDPclycv8QhjcS62rAoMwwpkQ_EsxwHltRuzq9FaSV04oYtb1e-e6JrKU7HHqKXrt_HUrV3Nikiqr8BTcakuGQb-e13SqIvQOnsozCcY1daU3WzOsyvX2MgS0QfILBkws9kQmlC2bovJ_wJ9uzUzJ5-oEOfSUwgWsC7z_Fr1eqlhUHn_Uf9lOVuhnkdd-88DLpOURpeDEDezWYt_MMSSF-pztOdNjCiKIMPmz3zX1rOs9x-eEgGPnLbDxif-Kjly1W00 **Step 1**: The User starts the Wallet Instance mobile app for the first time. **Step 2**: The Wallet Instance: - * Checks if the Device Integrity Service is available. * Checks whether the device meets the minimum security requirements. + * Checks if the Device Integrity Service is available. .. note:: @@ -246,7 +246,7 @@ Below a non-normative example of the ``client_data``. **Steps 11-12**: The Wallet Instance: - * Constructs the Wallet Attestation Request in the form of a JWT. This JWT includes the ``integrity_assertion``, ``hardware_signature``, ``challenge``, ``hardware_key_tag``, and ``cnf``, and is signed using the private key of the initially generated ephemeral key pair. + * Constructs the Wallet Attestation Request in the form of a JWT. This JWT includes the ``integrity_assertion``, ``hardware_signature``, ``challenge``, ``hardware_key_tag``, ``cnf`` and other configuration related parameters (see :ref:`Table of the Wallet Attestation Request Body ` below) and is signed using the private key of the initially generated ephemeral key pair. * Submits the Wallet Attestation Request to the token endpoint of the Wallet Provider Backend. Below an non-normative example of the Wallet Attestation Request JWT without encoding and signature applied: @@ -283,6 +283,17 @@ Below an non-normative example of the Wallet Attestation Request JWT without enc }, }, }, + authorization_endpoint": "https://wallet-solution.digital-strategy.europa.eu/authorization", + "response_types_supported": [ + "vp_token" + ], + "response_modes_supported": [ + "form_post.jwt" + ], + "request_object_signing_alg_values_supported": [ + "ES256" + ], + "presentation_definition_uri_supported": false, "iat": 1686645115, "exp": 1686652315 } @@ -446,6 +457,21 @@ The body of the Wallet Attestation Request JWT MUST contain: * - **vp_formats_supported** - JSON object with name/value pairs, identifying a Credential format supported by the Wallet. - + * - **authorization_endpoint** + - URL of the Wallet Authorization Endpoint (custom url schema or universal link of the Wallet Instance). + - + * - **response_types_supported** + - JSON array containing a list of the OAuth 2.0 ``response_type`` values. + - + * - **response_modes_supported** + - JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports. + - :rfc:`8414` + * - **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 by reference. MUST be set to false. + - .. _table_wallet_attestation_claim: diff --git a/images/wallet_instance_initialization.svg b/images/wallet_instance_initialization.svg index 5f5237a0..9cd56123 100644 --- a/images/wallet_instance_initialization.svg +++ b/images/wallet_instance_initialization.svg @@ -1 +1 @@ -UserWallet InstanceDevice Integrity ServiceWallet Provider backendonly upon first installation of the app1starts the app (first use)2Check if Device Integrity Service is availableCheck Wallet Provider is part of the Federation and obtain its metadata3Getchallenge4Generate one time usechallenge5challenge6GenerateCryptographic Hardware Keyspair and storeCryptographic Hardware Key Tag7attestKey(challenge, Cryptographic Hardware Key Tag)8Key Attestationsigned by OEM9Sendchallenge,Key AttestationandCryptographic Hardware Key Tag10Validatechallenge11ValidateKey Attestation12StoreCryptographic Hardware Keys13OK14Wallet Instance Initialized \ No newline at end of file +UserWallet InstanceDevice Integrity ServiceWallet Provider backendonly upon first installation of the app1starts the app (first use)2Check if the device meets the minimum security requirementsand ifDevice Integrity Serviceis availableCheck Wallet Provider is part of the Federation and obtain its metadata3Getchallenge4Generate one time usechallenge5challenge6GenerateCryptographic Hardware Keyspair and storeCryptographic Hardware Key Tag7attestKey(challenge, Cryptographic Hardware Key Tag)8Key Attestationsigned by OEM9Sendchallenge,Key AttestationandCryptographic Hardware Key Tag10Validatechallenge11ValidateKey Attestation12StoreCryptographic Hardware Keys13OK14Wallet Instance Initialized \ No newline at end of file