diff --git a/docs/en/revocation-lists.rst b/docs/en/revocation-lists.rst index e681c6509..c4e6b968b 100644 --- a/docs/en/revocation-lists.rst +++ b/docs/en/revocation-lists.rst @@ -5,65 +5,112 @@ Credential Revocations ++++++++++++++++++++++ -The value of Digital Credentials is contingent on their validity. -A credential that has been revoked, due to legal requirements, inaccuracy or compromise, is not only valueless but potentially harmful. -For these reasons a robust mechanism for managing the validity and revocation of Digital Credentials is required. +The value of a Digital Credential is conditional on its validity. +A Credential that has been revoked, due to legal requirements, inaccuracy or compromise, is valueless and potentially harmful. +For these reasons a robust mechanism for managing the life-cycle and the revocation of a Digital Credential is required. This section outlines the key technical requirements and processes related to the revocation of the Digital Credentials. Furthermore, it provides the technical details that the Relying Parties MUST implement to verify, in a secure and reliable manner, the validity of a Digital Credential during the presentation phase. -This section is structured into several subsections, these are listed below. - -* The :ref:`"General Assumptions" ` subsection outlines the main assumptions relevant to the design of a suitable solution for the main revocation scenarios. -* The :ref:`"Requirements" ` subsection outlines basic requirements, particularly regarding security and privacy aspects. -* The :ref:`"Entities Relationship" ` describes the roles and responsibilities of the main entities involved in ensuring the validity of credentials and managing their revocation. -* The :ref:`"High Level Revocation Flow" ` subsection outlines the main revocation scanarios and relevant processes. -* The :ref:`"Wallet Instance Initiated Revocation Flow" ` subsections outline how Wallet Instances request a revocation of a given credential to Issuers. -* The :ref:`"Non-Revocation Attestation Request" ` subsections decribe how the Wallet Instance interacts with the Issuer to obtain a Non-Revocation Attestation related to a credential own by the Holder. -* The :ref:`"Non-Revocation Proof during the Presentation Phase" ` subsection details how a Non-Revocation Attestation, in the form of a cryptographic proof that the credential has not been revoked, is provided by the Wallet Instance to the Verifier requesting a credential. +It also provides the technical requirements that the Wallet Instance MUST implement to +request and present a status attestation about a Digital Credential, +theirein defined as Non-Revocation Attestation. +Generally, the Non-Revocation Attestation enables: +- the verification of the digital Credential when both the Wallet Instance and the Verifier are offline; +- a better privacy of the User since the Relyign Party cannot check over time the validity of a specific digital Credential related to the User. .. _sec_revocation_assumption: General Assumptions ------------------- -A Credential Issuer is in charge of the creation and the issuance of credentials, its lifecycle, and ultimately, its validity status. Some credentials may have regulatory value given by national or european laws, therefore also revocations of credentials MUST be non-repudiable. -Some credentials may be a digital representation of a physical document issued, under a well defined national law, by an Authentic Source which, in the Wallet Ecosystem, acts as a repository or system that contains attributes and provides them to the Issuer. For this reason, an exchange of information between the two entities is required not only for the issuing the credential but also for the proper handling of its revocation. -Moreover, due to digital signature of the credentials, any updates on them MUST result in a re-issuance. -Finally, it is assumed that, to facilitate the association between physical document and digital credentials, the identifier of the physical document is always present as an attribute within the Digital Credentials. +Similar to the Wallet Instance Attestation, Non-Revocation Attestations do not necessitate the User authentication. +The attestations acquired by the Holder (Wallet Instance) for its proper functioning are procured via assessments +and Holder's authentication with the attestation providers, entirely in an automated fashion. + +All the attestations can only be acquired when the Wallet Instance has an internet connection and is actively executed by the User. + +A Credential Issuer, together with the owner of the Credential (User), +is in charge of the creation and the issuance of Credentials, +its lifecycle and its validity status. + +Digital Credentials may be linked to a physical documents issued by an Authentic Source in a previous period. +The Authentic Sources are National organizations that implements repositories of data containing attributes +related to the Users to be provided to the Issuers duringthe issuance phase. +When one or more Authentic Sources are involved in the issuance of a Digital Credential, +the information exchanged between the Authentic Source and the PID/(Q)EAA Provider is required for the +issuance of the Credential and, in some cases also for the the revocation of the Credential. + +Finally, it is assumed that, to facilitate the association between physical document and a digital Credential, +the identifier of the physical document should be always present as an attribute within the Digital Credential. .. _sec_revocation_requirements: +Revocation Use Cases +-------------------- + +The revocation requests of a Credential MAY be communicated to the Issuer by: + +- Users using their personal Wallet Instance. +- Authentic Sources (e.g., for attribute updates) following administrative purposes. +- Law-Enforcing Bodies for the fulfillment of their functions and any other judicial reasons (e.g., Police). + + +The revocation requests of a physical document MAY be communicated to Authentic Source by: + +- A Law-Enforcing Body (e.g., Police) on behalf of the User or directly for the fulfillment of their functions and any other judicial reasons. +- The User using any out-of-band procedure in force by national regulations. + Requirements ------------ General Requirements ^^^^^^^^^^^^^^^^^^^^ - -- The Issuer MUST be the only responsible for the lifecycle of credentials including the revocation status. -- Credentials SHOULD be updated whenever one or more attributes are changed. -- Any credential update MUST result in a new fresh issuance of it, following the principle that the credential SHOULD always have updated data. In this case, the old Credentials of the same type MUST be revoked. -- The revocation of a credential for technical reasons (loss or theft of the device, compromise of cryptographic keys) MAY not have an impact on any other Digital Credentials issued of the same type and MUST NOT lead to the revocation of a physical document associated with it. -- The revocation of a physical document which one or more Credentials are associated with MUST result in their revocation. -- The revocation requests of a credential MAY be communicated to the Issuer by: - - - Holders using their personal Wallet Instance. - - Authentic Sources (e.g., for attribute updates) following administrative purposes. - - Law-Enforcing Bodies for the fulfillment of their functions and any other judicial reasons (e.g., Police). -- The revocation requests of a physical document MAY be communicated to Authentic Source by: - - - A Law-Enforcing Body (e.g., Police) on behalf of the User or directly for the fulfillment of their functions and any other judicial reasons. - - The Holder using any out-of-band procedure in force by national regulations. -- The Authentic Source MUST provide an interface for the data provisioning regarding the attributes update and revocation status of a physical document the credential is associated with. -- The Issuer MUST provide an interface handling the revocation flows (Revocation request/response, data access regarding the revocation status of a credential, etc.). -- The Issuer MUST provide the Wallet Instance with a proof of non-revocation of a given Holder's credential (Non-Revocation Attestation). -- The Holders MAY provide the Verifiers with a proof of non-revocation of their Credentials (Non-Revocation Attestations). -- The Verifiers MAY require a proof of non-revocation, even in the future after the credential presentation, for the fulfillment of their functions and for any other regulatory reasons (deferred). + +Below the requirements that must be satisfied, the Non-Revocation Attestation: + +- MUST be presented in conjunction with the digital Credential, and it MUST be timestamped with the issuance datetime, always referring to a previous period; +- MUST contain the expiration datetime after which it MUST NOT be considered valid anymore; +- expiration datetime MUST NOT be greater the one contained in the digital Credential which it refers to; +- enables offline use cases as it MUST be statically validated using the cryptographic signature of the Issuer; +- provides the proof about the non-revocation of the digital Credential which is related to; +- MUST be verifiable with a cryptographic signature. +- does not reveal any information about the Relying Party or the User's data contained in the digital Credential the attestation is related to. + + +Below the requirements that must be satisfied by the PID/(Q)EAA Providers, then the Issuer: + +- MUST provide a web service for allowing an authenticated User to ask the revocation using the Wallet Instance; +- MUST provide a web service for allowing a Wallet Instance, with a proof of possession of a specific Digital Credential, to obtain a Non-Revocation Attestation; +- MUST be responsible for the lifecycle of Credentials including the revocation status; +- MUST revoke a Digital Credential when it requires to be updated, whenever one or more attributes are changed; +- in the case of attributes update, the Issuer MUST provide a fresh issuance of the Digital Credential to the User; +- MUST multiple communication channels and services where the User can request the revocation of their Digital Credentials, using a robust procedure for identity proofing and User authentication, in particular when the User is unable to use the personal Wallet for asking the revocations. +- MUST provide a web service where the authorized Authentic Sources MAY notify the updates related to the data of a specific User for which the Issuer has requested the data, in a previous period, for the issuance of a Digital Credential related to that User; +- each time an Authentic Source notify a data update regarding a specific User, the Issuer MUST revoke the already issued Digital Credential. +- MUST provide Non-Revocation Attestation in a non-repudiable manner, using cryptographic mechanisms. + +Below the requirements that must be satisfied by the User: + +- the revocation of a Digital Credential may happen for technical reasons, such as the loss or theft of the device, or the compromission of the cryptographic keys. In these cases the User MUST ask the revocation of its Digital Credentials to their Issuers. + + +Below the requirement that must be satisfied by the Wallet Instance: + +- The Wallet Instance MAY provide the Verifiers and Relying Parties with a proof of non-revocation of their Credentials when the issued Credential contains the status object configuring the status check using a Non-Revocation Attestation. + + +Below the requirements related to the Authentic Sources: + +- The Authentic Source MUST provide web service where the allowed Issuers can be authenticated and authorized in obtaining the data for a specific User for the scope of the issuance of a Digital Credential; +- Each time an Issuer requests data of a specific User to the Authentic Source, the Authentic Source MUST keep track of which Issuer has asked and obtained the data for which User; +- Each time the data of a User is updated, the Authentic Source MUST notify to the Issuers that have requested the data for that specific User in a previous time; +- The revocation of a physical document which one or more Credentials are associated with, MUST result in the revocation of those Credentials. In these cases the Authentic Source MUST notify to the Issuers that the data are changed. Security Requirements @@ -77,11 +124,10 @@ Security Requirements Privacy Requirements ^^^^^^^^^^^^^^^^^^^^ -- The Authentic Source MUST store in local databases only the minimum information required to notify the Issuer of a change in attributes or a change in the validity status of a physical document associated with one or more credentials. -- Access to credential status information by a Verifier MUST be authorized by the Holder, except for checks carried out by Law-Enforcement Bodies on a regulatory basis. -- The Issuer SHOULD not directly or indirectly have any information related to the Verifier, type of credentials, and Holder such that it is impossible to track the Holder's usage of the Credentials. -- A proof of non-revocation (Non-Revocation Attestation) provided by the Issuer, in whatever format it is, SHOULD NOT reveal any information about the Verifier nor the User's attributes contained in the credential the attestation is related to. - +- The Authentic Source MUST store in local databases only the minimum information required to notify the Issuer of a change in attributes or a change in the validity status of a physical document associated with one or more Credentials. +- Access to Credential status information by a Verifier MUST be authorized by the Holder, except for checks carried out by Law-Enforcement Bodies on a regulatory basis. +- The Issuer SHOULD not directly or indirectly have any information related to the Verifier, type of Credentials, and Holder such that it is impossible to track the Holder's usage of the Credentials. +- A proof of non-revocation (Non-Revocation Attestation) provided by the Issuer, in whatever format it is, SHOULD NOT reveal any information about the Verifier nor the User's attributes contained in the Credential the attestation is related to. .. _sec_revocation_entity_relationship: @@ -100,9 +146,8 @@ The entities involved in the main revocation processes are depicted in the diagr The revocation scenarios involve two main flows: - - The Revocation Request flow: this flow describes how an entity requests for a credential revocation to the Issuer of that credential. - - The Non-Revocation Attestation Request flow: this flow defines the technical protocol for requesting and obtaining a Non-Revocation Attestation and how the Wallet Instance will provide it with a Verifier as a proof of validity of a credential. - + - The Revocation Request flow: this flow describes how an entity requests for a Credential revocation to the Issuer of that Credential. + - The Non-Revocation Attestation Request flow: this flow defines the technical protocol for requesting and obtaining a Non-Revocation Attestation and how the Wallet Instance will provide it with a Verifier as a proof of validity of a Credential. .. _sec_revocation_high_level_flow: @@ -112,9 +157,9 @@ High Level Revocation Flow A Credential Revocation Flow can start under different scenarios: - - The Holders report the loss or theft of their own physical document to the Law-Enforcement Authorities: this implies that the credentials, if any, shall be revoked. + - The Holders report the loss or theft of their own physical document to the Law-Enforcement Authorities: this implies that the Credentials, if any, shall be revoked. - The Holders notify an Authentic Source that one or more attributes are changed (e.g. the current resident address): in this case the Credentials SHALL be revoked, as they are no longer valid due to the change in attributes. - - The Holders who no longer have access to their Wallet Instance (e.g. theft or loss of the device), may request the Issuer of the credentials to revoke them. + - The Holders who no longer have access to their Wallet Instance (e.g. theft or loss of the device), may request the Issuer of the Credentials to revoke them. - The Law-Enforcing Authorities, for the fulfillment of their functions and any other judicial reasons, may request the Authentic Source to revoke entitlements, licences, certificates, identification documents, etc., which in turn leads to the revocation of any linked Credentials. - The Authentic Sources that for any administrative reasons update one or more attributes of a Holder, SHALL inform the Issuer of related Credentials. - The Issuers, for technical security reasons (e.g. in the case of compromised cryptographic keys), can decide to revoke the Credentials. @@ -132,13 +177,12 @@ Some of the sub-processes involved in the above scenarios are already well defin The susequent section defines the protocol interface between the Wallet Instance and the Issuer during the revocation request. The communication between the Authenitc Source and the Issuer is out of scope of this technical implementation profile. - .. _sec_revocation_wi_initiated_flow: Wallet Instance Initiated Revocation Flow ----------------------------------------- -A Wallet Instance MUST request the revocation of a credential as defined below. +A Wallet Instance MUST request the revocation of a Credential as defined below. .. _fig_Low-Level-Flow-Revocation: .. figure:: ../../images/Low-Level-Flow-Revocation.svg @@ -148,7 +192,7 @@ A Wallet Instance MUST request the revocation of a credential as defined below. Wallet Instance Initiated Revocation Flow -**Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request includes the Wallet Instance Attestation with its Proof of Possession and a Credential Proof of Possession as a JWT. It MUST be signed with the private key related to the public key contained within the credential (Issuer Signed JWT). Then, the Wallet Instance sends the request to the Issuer as in the following non-normative example. +** Step 1 (Credential Revocation Request)**: The Wallet Instance initiates the process by creating a Credential Revocation Request. This request includes the Wallet Instance Attestation with the Proof of Possession and a Credential Proof of Possession as a JWT. It MUST be signed with the private key related to the public key contained within the Credential (such as the Issuer Signed JWT in the case of SD-JWT, or the MSO in the case of Mdoc CBOR). Then, the Wallet Instance sends the request to the Issuer as in the following non-normative example. .. _credential_revocation_request_ex: .. code-block:: @@ -175,7 +219,7 @@ where a non-normative example of a Credential PoP is given by the following JWT . { "iss": "0b434530-e151-4c40-98b7-74c75a5ef760", - "aud": "https://pid-provider.example.org", + "aud": "https://pid-provider.example.org/revoke", "iat": 1698744039, "exp": 1698744139, "jti": "6f204f7e-e453-4dfd-814e-9d155319408c", @@ -183,9 +227,9 @@ where a non-normative example of a Credential PoP is given by the following JWT "credential": "$Issuer-Signed-JWT" } -**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the Wallet Instance Attestation and the credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Wallet Instance Attestation and credential, and therefore is entitled to request its revocation. +**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the Wallet Instance Attestation and the Credential. If the verification is successful, it means that the Wallet Instance owns the private keys associated with the Wallet Instance Attestation and Credential, and therefore is entitled to request its revocation. -**Step 3 (Credential Revocation)**: The Issuer revokes the credential provided in the Credential PoP JWT. After the revocation, the Issuer MAY also send a notification to the Holder (e.g. using a Holder contact certified during the issuance phase), with all needed information related to the credential revocation status update. This communication is out of scope of the current technical implemetation profile. +**Step 3 (Credential Revocation)**: The Issuer revokes the Credential provided in the Credential PoP JWT. After the revocation, the Issuer MAY also send a notification to the User (e.g. using a User's email address, or 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 implemetation profile. **Step 4 (Credential Revocation Response)**: The Issuer sends a response back to the Wallet Instance with the result of the revocation request. @@ -209,8 +253,8 @@ The requests to the *Issuer Revocation endpoint* MUST be HTTP with method POST, * - **Claim** - **Description** - **Reference** - * - **credential_proof** - - It MUST contain a JWT proof of possession of the cryptographic key the credential to be revoked shall be bound to. + * - **Credential_proof** + - It MUST contain a JWT proof of possession of the cryptographic key the Credential to be revoked shall be bound to. - This specification * - **client_assertion_type** - It MUST be set to ``urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation``. @@ -237,7 +281,7 @@ The Credential Proof of Possession MUST be a JWT that MUST contain the paramters - A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms listed in the Section `Cryptographic Algorithms `_ and MUST NOT be set to ``none`` or any symmetric algorithm (MAC) identifier. - :rfc:`7516#section-4.1.1`. * - **kid** - - Unique identifier of the ``jwk`` inside the ``cnf`` claim of the credential to be revoked, as base64url-encoded JWK Thumbprint value. + - Unique identifier of the ``jwk`` inside the ``cnf`` claim of the Credential to be revoked, as base64url-encoded JWK Thumbprint value. - :rfc:`7638#section_3`. .. list-table:: @@ -262,19 +306,18 @@ The Credential Proof of Possession MUST be a JWT that MUST contain the paramters * - **jti** - Unique identifier for the PoP proof JWT. The value SHOULD be set using a *UUID v4* value according to [:rfc:`4122`]. - [:rfc:`7519`. Section 4.1.7]. - * - **credential_format** - - The data format of the credential to be revoked. It MUST be set to ``vc+sd-jwt`` or ``vc+mdoc`` + * - **Credential_format** + - The data format of the Credential to be revoked. It MUST be set to ``vc+sd-jwt`` or ``vc+mdoc`` - This specification. - * - **credential** - - It MUST contain the credential to be revoked encoded according to the data format given in the ``credential_format`` claim. + * - **Credential** + - It MUST contain the Credential to be revoked encoded according to the data format given in the ``Credential_format`` claim. - [:rfc:`7519`. Section 4.1.7]. Credential Revocation HTTP Response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -TBD. - +The response MUST be an HTTP Response using the status code set to 204 (No-Content). .. _sec_revocation_nra_request: @@ -282,10 +325,10 @@ TBD. Non-Revocation Attestation Request ---------------------------------- -The presentation of a credential to a Verifier may occur long after it has been issued by the Issuer. During this time interval, the credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Issuer provides the Wallet Instance with a *Non-Revocation Attestation*. This Attestation is bound to a credential so that the Wallet Instance can present it to a Verifier, along with the credential itself, as a proof of non-revocation status of the credential. +The presentation of a Credential to a Verifier may occur long after it has been issued by the Issuer. During this time interval, the Credential can be invalidated for any reason and therefore the Verifier also needs to verify its revocation or suspension status. To address this scenario, the Issuer provides the Wallet Instance with a *Non-Revocation Attestation*. This Attestation is bound to a Credential so that the Wallet Instance can present it to a Verifier, along with the Credential itself, as a proof of non-revocation status of the Credential. -The Non-Revocation Attestation MUST be presented in conjunction with the digital credential. The Non-Revocation Attestation MUST be timestamped with its issuance datetime, always referring to a previous period. -The Non-Revocation Attestation MUST contain the expiration datetime after which the digital credential MUST NOT be considered valid anymore. +The Non-Revocation Attestation MUST be presented in conjunction with the digital Credential. The Non-Revocation Attestation MUST be timestamped with its issuance datetime, always referring to a previous period. +The Non-Revocation Attestation MUST contain the expiration datetime after which the digital Credential MUST NOT be considered valid anymore. The Non-Revocation Attestation enables offline use cases as it MUST be statically validated using the cryptographic signature of the Issuer. Relying Parties MUST reject an expired Non-Revocation Attestation and, in the case of valid Attestations, they MAY still reject them according to their own policies (e.g., if the issue date doesn't meet their security requirements). @@ -299,7 +342,7 @@ The following diagram shows how the Wallet Instance MUST request a Non-Revocatio Non-Revocation Attestation Request Flow -**Step 1 (Non-Revocation Attestation Request)**: The Wallet Instance sends the Non-Revocation Attestation Request to the Issuer. The request MUST contain the Wallet Instance Attestation with its Proof of Possession and a Credential Proof of Possession JWT, signed with the private key related to the public key contained within the credential. +**Step 1 (Non-Revocation Attestation Request)**: The Wallet Instance sends the Non-Revocation Attestation Request to the Issuer. The request MUST contain the Wallet Instance Attestation with its Proof of Possession and a Credential Proof of Possession JWT, signed with the private key related to the public key contained within the Credential. .. code:: @@ -307,29 +350,29 @@ The following diagram shows how the Wallet Instance MUST request a Non-Revocatio Host: pid-provider.example.org Content-Type: application/x-www-form-urlencoded - credential_proof=$CredentialPoPJWT + Credential_proof=$CredentialPoPJWT &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation &client_assertion=$WIA~WIA-PoP -For a non-normative example of Credential Proof of Possession see :ref:`the one provided in the prevoius section `. +For a non-normative example of Credential Proof of Possession see :ref:`the one provided in the prevoius section `. -**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the Wallet Instance Attestation and the credential, which is the proof that the Wallet Instance owns the private keys associated with the Wallet Instance Attestation and credential. Therefore the Wallet Instance is entitled to request its Non-Revocation Attestation. +**Step 2 (PoP verification)**: The Issuer verifies the signature of the PoP JWTs using the public key that was attested in the Wallet Instance Attestation and the Credential, which is the proof that the Wallet Instance owns the private keys associated with the Wallet Instance Attestation and Credential. Therefore the Wallet Instance is entitled to request its Non-Revocation Attestation. -**Step 3 (Non-Revocation Attestation Creation)**: The Issuer checks the status of the credential and creates a Non-Revocation Attestation bound to it. Then it creates a new Non-Revocation Attestation, a non-normative example of which is given below. +**Step 3 (Non-Revocation Attestation Creation)**: The Issuer checks the status of the Credential and creates a Non-Revocation Attestation bound to it. Then it creates a new Non-Revocation Attestation, a non-normative example of which is given below. .. code:: { "alg": "ES256", "typ": "non-revocation-attestation+jwt", - "kid": "$ISSUER-JWKID" + "kid": $ISSUER-JWKID } . { "iss": "https://pid-provider.example.org", "iat": 1504699136, "exp": 1504700136, - "credential_hash": "$CREDENTIAL-HASH", + "credential_hash": $CREDENTIAL-HASH, "credential_hash_alg": "sha-256", "cnf": { "jwk": {...} @@ -359,7 +402,7 @@ The *Credential status endpoint* MUST be provided by the Issuer within its Metad Non-Revocation Attestation HTTP Response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The *Credential status endpoint* MUST return a response with a *HTTP status code 201 OK* if the credential is valid at the time of the request, otherwise a *HTTP status code 404 Not Found* MUST be given by the Issuer. The responses MUST be encoded in ``application/json`` format. It MUST contain the following mandatory claims. +The *Credential status endpoint* MUST return a response with a *HTTP status code 201 OK* if the Credential is valid at the time of the request, otherwise a *HTTP status code 404 Not Found* MUST be given by the Issuer. The responses MUST be encoded in ``application/json`` format. It MUST contain the following mandatory claims. .. _table_http_response_claim: .. list-table:: @@ -415,13 +458,13 @@ The Non-Revocation Attestation MUST contain the following claims. - UNIX Timestamp with the expiry time of the JWT. - :rfc:`9126` and :rfc:`7519`. * - **credential_hash** - - Hash value of the credential the Non-Revocation Attestation is bound to. + - Hash value of the Credential the Non-Revocation Attestation is bound to. - This specification. * - **credential_hash_alg** - - The Algorithm used of hashing the credential to which the Non-Revocation Attestation is bound. The value MUST be set to ``S256``. + - The Algorithm used of hashing the Credential to which the Non-Revocation Attestation is bound. The value MUST be set to ``S256``. - This specification. * - **cnf** - - JSON object containing the proof-of-possession key materials. The ``cnf`` jwk value MUST match with the one provided within the related credential. + - JSON object containing the proof-of-possession key materials. The ``cnf`` jwk value MUST match with the one provided within the related Credential. - `[RFC7800, Section 3.1] `_. @@ -431,7 +474,7 @@ The Non-Revocation Attestation MUST contain the following claims. Non-Revocation Proof during the Presentation Phase -------------------------------------------------- -During the presentation phase, a Verifier MAY request the Wallet Instance to provide a Non-Revocation Attestation along with the requested credential (e.g. using the ``scope`` parameter). The Wallet Instance MUST provide the Verifier with a most recent Non-Revocation Attestation. If the Attestation is requested by the Verifier and the Wallet Instance is not able to provide it or it is expired the Verifier MUST reject the credential. If the Attestation is issued far back in time, the Verifier MAY decide to accept or reject the credential according to its security policy. +During the presentation phase, a Verifier MAY request the Wallet Instance to provide a Non-Revocation Attestation along with the requested Credential (e.g. using the ``scope`` parameter). The Wallet Instance MUST provide the Verifier with a most recent Non-Revocation Attestation. If the Attestation is requested by the Verifier and the Wallet Instance is not able to provide it or it is expired the Verifier MUST reject the Credential. If the Attestation is issued far back in time, the Verifier MAY decide to accept or reject the Credential according to its security policy. Law-Enforcement Authorities or Third Parties authorized by national law, MAY require deferred non-revocation status verification but the definition of these protocols is currently out-of-scope for this technical implementation profile.