Is Notification Endpoint intended to be used post-issuance?

[joelposti]

I am designing lifecycle management of a long-lived credential that supports revocation. The issuance service of such a credential will implement the Notification Endpoint as it allows the issuer to immediately revoke the issued credential, if directly after the issuance the wallet signals with a Notification Request that the user rejected the credential or if there was some other issue in storing the credential to the wallet.

Beyond the issuance it would also be useful, if the wallet signaled that the user deleted the credential from their wallet eg. two weeks later. Let's call it post-issuance notification. Is post-issuance notification a use case that the Notification Endpoint supports?

The current description of the Notification Endpoint and the description of the event parameter quite heavily imply that the endpoint is intended to be used immediately after the issuance. Below are citations that hopefully illustrate this.

The Wallet MUST present to the Notification Endpoint a valid Access Token issued at the Token Endpoint as defined in Section 7.

Given that an Access Token is short-lived the above part of the description seems to imply that the Notification Endpoint is intended to be used only a short amount of time after the issuance. To use the Notification Endpoint much later the wallet would have to make a Token Request with a Refresh Token to get hold of a new Access Token and then make a Notification Request with that Access Token and with the notification_id value it received in the Credential Response during the issuance of the credential. This can be done, but it is not explained.

event: REQUIRED. Type of the notification event. It MUST be a case sensitive string whose value is either credential_accepted, credential_failure, or credential_deleted. credential_accepted is to be used when the Credentials were successfully stored in the Wallet, with or without user action. credential_deleted is to be used when the unsuccessful Credential issuance was caused by a user action. In all other unsuccessful cases, credential_failure is to be used. Partial errors during issuance of multiple Credentials as a batch (e.g., one of the Credentials could not be stored) MUST be treated as the overall issuance flow failing.

According to the descriptions above, all of the possible event parameter values are tied to the issuance process. If the user originally accepted the credential, the wallet stored it succesfully and two weeks later the user decides to delete the credential, I would not know which event value to use. The supported values and their descriptions seem to rule out post-issuance notification.

There is another issue #133 titled “A Wallet -> Issuer ‘credential deleted’ signal” where @selfissued has commented that the Notification Endpoint could be used for the “credential deleted signal” which is a post-issuance notification use case. However, as I have hopefully illustrated in this issue the Notification Endpoint is not well defined to support that.