[Openid-specs-ab] OID4VCI notification of acceptance/rejection of issued credential
David Luna
david.luna at forgerock.com
Wed May 3 13:11:17 UTC 2023
Hi folks,
Great to meet some of you in person a few weeks back at the OIDF and IIW meetings. Congratulations on the recent approval for OID4VP second implementer’s draft.
With regards to OID4VCI, I’m wondering what consideration has been given to the optional notification of the issuer once a credential or set of credentials has been successfully stored (or not) in the wallet. This would be an action the wallet may take that occurs after a Credential Response has been received by the wallet, synchronous or deferred.
After the issuer has sent credential(s) to the wallet, as far as I can tell there’s no way for the issuer to know that the wallet actually accepted and successfully processed the storage of them. Some wallets upon receiving a credential will still prompt the user to accept or reject its storage, even if the wallet initiated the credential request flow. (This seems to align with 11.2 which mentions that a wallet mustn’t accept a credential just because it was issued via this mechanism).
I could see this being useful - e.g. if in a pre-authorised issuance of a credential occurs in the middle of a flow on an issuer that only wants to continue if the issuer is sure the credential is now in the user’s possession, but without having to instantly demand presentation of the just-issued credential. Or simply so that an issuer doesn’t alway presume that every issuance was successful, accepted, the wallet didn’t error or crash after receiving the issuance, etc.
I could imagine the issuer understanding at least two messages, 'credential not stored' (covering errors and storage rejection), and 'credential stored’.
While I can see there being issues with being notified of rejection in the case of a verifiable presentation request, a message following the AS’s Credential Response doesn’t seem to hold those same concerns for me (e.g. wallet phishing).
From what I can tell, a similar result can be achieved by wallet initiated issuance by the issuer performing a presentation request for the about-to-be-issued credential (similar to Use Case D.4.) but it seems somewhat counterintuitive to get notified on issuance only by triggering that issuance by a presentation request. Be good to know if this is something that’s already been discussed and/or I’m missing something.
Thanks,
David Luna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230503/36eeff76/attachment.html>
More information about the Openid-specs-ab
mailing list