OID4VCI - Notification of acceptance/rejection of issued credential

[David Luna]

As mentioned on the mailing list (https://lists.openid.net/pipermail/openid-specs-ab/2023-May/009904.html) and last SIOP WG call.

I'd like to suggest a final step in the VC issuance flow, that I think is particularly relevant for the pre-authorized code flow. I'd like for a wallet, once a credential has been received via the Credential Response, to be able to (optionally) notify the issuer that the credential was accepted and successfully stored in the wallet. I would expect this to take the form of a credential receipt that indicates that the wallet successfully stored the specific credential that was included in the Credential Response. This receipt would be tied to the credential being issued, as well as proof of possession of the public key to which it was issued. It would also be useful to have a flag in the Credential Response indicating that such a receipt is desired (or potentially even required?) by the issuer.

‌

Use-Cases:

When issuing credentials (particularly high-assurance credentials such as mDLs or PIDs), issuers may need to receive confirmation that an issued credential has been successfully received and stored in the wallet. 

There are two main concerns that have been raised in discussion: 

• Failed storage of a credential, due to errors or other unforeseen circumstances, the credential not being delivered for whatever reason, etc.
• Rejection of a credential by the wallet holder.

While the latter of these is not a failure of any kind, we're looking to be able to indicate to our customers that a just-issued credential is now in the possession of the holder.

In the case where a receipt was received, workflows can continue with a higher level of assurance that the user now has the credential. We have spoken about requesting presentation of a credential immediately after its issuance, but this is considered to create significant additional friction for the end-user, as well as convoluting the workflows themselves (every issuance having to now be followed by a presentation request).

In the case where a receipt was not received, or came back indicating that the credential had been rejected, we wish to be able to branch from the current flow, to perform some other action. This may be a repetition of the credential issuance flow (starting with a new Credential Offer), or it may be to divert to some other actions entirely.

‌

We have such flows already implemented via a non-standard integration, and are hoping we can standardise around this, rather than having to bolt-on this feature ourselves and with our partners.

[Kristina Yasuda]

+1. We also have this problem that “A lot of things can go wrong after the issuer sends a credential response and the Issuer wants to know that the credential has been successfully stored in the wallet“.

Based on our implementation experience, I think there are two components that should be standardized:

• how the issuer communicates to the wallet the callback endpoint. should probably be issuer metadata
• the structure of the callback the wallet sends after an (un)successful processing of a credential response

‌

[David Luna]

Thanks for the +1 Kristina.
I think a callback mechanism is the right way to go. Adding further responsibilities to an existing endpoint doesn’t seem right. Along with standardising the communication of the callback endpoint and the structure of the callback, I also think that we’d need to standardise the mechanism to indicate to the Wallet when the callback should be used (when its ”desired”).

I see a number of routes here:

1. Define the callback in the issuer metadata. All credentials in the credentials_supported are assumed to have the callback use desired. // Not very granular, not very flexible
2. Define the callback in the issuer metadata. On a per-credential basis, the credentials_supported parameter could include the desire for the use of the callback, and be assumed for it to not be desired if not present. // Granular, but not flexible
3. Define the callback in the issuer metadata. Include the desire in a given Credential Response. This keeps the callback endpoint in the “right place” (alongside the other endpoint locations) and also gives the granular / flexbile benefits. // Granular and flexible with the endpoint defined in the well-known endpoint
4. Define the callback in the Credential Response. Its presence could be used to indicate that desire. // Granular and flexible but the endpoint is no longer defined in the well-known endpoint

Our current implementation uses something analogous to 3, and it’s my preferred approach to pursue for standardisation.

For the structure of the callback, we would need to ensure that it contains an indication of which credential(s) in the credential response it’s associated with, as well as suitable cryptographic proof of key possession. I don’t think anything changes between the synchronous and deferred, and/or batched cases.

[Kristina Yasuda]

discussed at the SIOP Aug-10-2023 SIOP call

there were no objections to adding this feature as long as it is optional for the wallet. I think this is ready for PR.

[Kristina Yasuda]

PR #608

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI