feat: wrong data notification from wallet instance to vci

docs/en/credential-issuance-endpoint.rst

@@ -1028,6 +1028,7 @@ The Notification Request MUST be an HTTP POST using the *application/json* media
       - *credential_accepted*: when the Credential was successfully stored in the Wallet Instance.
       - *credential_deleted*: when the unsuccessful Credential issuance was caused by a user action.
       - *credential_failure*: in all other unsuccessful cases.
+
 
     - Section 10.1 of [`OpenID4VCI`_].
   * - **event_description**
@@ -1084,3 +1085,19 @@ In the following table are listed HTTP Status Codes and related error codes that
     * - *504 Gateway Timeout* [OPTIONAL]
       - `-`
       - The Credential Issuer cannot fulfill the request within the defined time interval.
+
+
+.. _notification-data-correction:
+
+Data Correction using credential_failure
+........................................
+
+According to `OpenID4VCI Section 11 <https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-11>`_, in all other unsuccessful cases ``event`` MUST use ``credential_failure`` and additional Notification Request parameters MAY be defined and used. The Credential Issuer MUST ignore any unrecognized parameters.
+
+For holder-initiated data correction, the Wallet Instance SHOULD send a Notification Request with ``event=credential_failure`` and include additional parameters to signal the data correction context. At minimum:
+
+- ``event_description``: concise human-readable description of the discrepancy.
+- ``failure_reason`` (OPTIONAL): a short machine-readable code, e.g., ``data_correction_requested``.
+- ``correction_details`` (OPTIONAL): object with minimal fields indicating impacted attributes without sensitive values (e.g., attribute identifiers only).
+
+Upon receipt, the Credential Issuer MAY verify against Authentic Sources and, if confirmed, SHOULD proceed with the :ref:`credential-issuance-low-level:Re-Issuance Flow`.

docs/en/credential-revocation.rst

@@ -217,6 +217,8 @@ Users MAY change their Digital Credential validity status by:
       - Verify data authenticity.
       - View and update validity status (revoke their Digital Credentials and, if it is supported by the Issuer, suspend them).
 
+In addition, when Users detect incorrect data in an issued Digital Credential, the Wallet Instance SHOULD initiate a data correction request via the Notification Endpoint as specified in :ref:`notification-data-correction`. Upon confirmation of the discrepancy, the Issuer SHOULD follow the :ref:`credential-issuance-low-level:Re-Issuance Flow`.
+
 .. note::
   If the User activates another Wallet Instance from the same Wallet Provider and using the same Wallet Solution and obtains a new PID, the previous PID MUST be revoked, and the previous Wallet Instance MUST transition to operational status.
 

docs/it/credential-issuance-endpoint.rst

@@ -1027,6 +1027,7 @@ La Notification Request DEVE essere una HTTP POST utilizzando il media type *app
       - *credential_accepted*: quando l'Attestato ELettronico è stato memorizzato con successo nell'Istanza del Wallet.
       - *credential_deleted*: quando l'emissione non riuscita dell'Attestato Elettronico è stata causata da un'azione dell'utente.
       - *credential_failure*: in tutti gli altri casi di insuccesso.
+
 
     - Sezione 10.1 di [`OpenID4VCI`_].
   * - **event_description**
@@ -1082,3 +1083,19 @@ Nella seguente tabella sono elencati i *Status Code HTTP* e i relativi codici di
     * - *504 Gateway Timeout* [OPZIONALE]
       - `-`
       - Il Credential Issuer non può soddisfare la richiesta entro l'intervallo di tempo definito.
+
+
+.. _it-notification-data-correction:
+
+Correzione dati usando credential_failure
+.........................................
+
+Secondo `OpenID4VCI Sezione 11 <https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-11>`_, in tutti gli altri casi di insuccesso ``event`` DEVE usare ``credential_failure`` e parametri addizionali della Notification Request POSSONO essere definiti e usati. Il Credential Issuer DEVE ignorare i parametri non riconosciuti.
+
+Per la correzione dati iniziata dall'Utente, l'Istanza del Wallet DOVREBBE inviare una Notification Request con ``event=credential_failure`` includendo parametri aggiuntivi per segnalare il contesto della correzione dati. Al minimo:
+
+- ``event_description``: descrizione concisa e leggibile della discrepanza.
+- ``failure_reason`` (OPZIONALE): breve codice machine-readable, ad es. ``data_correction_requested``.
+- ``correction_details`` (OPZIONALE): oggetto con campi minimi per indicare gli attributi impattati senza valori sensibili (es. soli identificativi degli attributi).
+
+A seguito della ricezione, il Credential Issuer PUÒ verificare presso le Fonti Autentiche e, se confermato, DOVREBBE procedere con il :ref:`credential-issuance-low-level:Re-Issuance Flow`.

docs/it/credential-revocation.rst

@@ -215,6 +215,8 @@ Gli Utenti POSSONO modificare lo stato di validità del loro Attestato Elettroni
       - Verificare l'autenticità dei dati.
       - Visualizzare e aggiornare lo stato di validità (revocare i loro Attestati Elettronici e, se supportato dal Fornitore di Attestati Elettronici, sospenderle).
 
+Inoltre, quando gli Utenti rilevano dati non corretti in un Attestato Elettronico rilasciato, l'Istanza del Wallet DOVREBBE avviare una richiesta di correzione dati tramite il Notification Endpoint come specificato in :ref:`it-notification-data-correction`. A seguito della conferma della discrepanza, il Fornitore di Attestati Elettronici DOVREBBE seguire il :ref:`credential-issuance-low-level:Re-Issuance Flow`.
+
 .. note::
   Se l'Utente attiva un'altra Istanza del Wallet dallo stesso Fornitore di Wallet utilizzando la stessa Soluzione Wallet e ottiene un nuovo PID, il PID precedente DEVE essere revocato e l'Istanza del Wallet precedente DEVE passare allo stato operativo.