[OpenID4VCI] UserPIN description and length

[Paul Bastian]

In Pre-authorized code flow the OpenID4VCI protocol offers the option to use a userPIN to further protect the code from theft/replay. The spec (rightfully) does not make any further assumptions about how and where this userPIN is communicated between Issuer and Holder. But this also means that situations might occur, where the Holder is prompted for the UserPIN in his wallet and he might be clueless of what the PIN is or where it might be communicated. The issuer might give this information on the website, where the QR-Code is displayed but

a) in a same-device scenario the website is not visible anymore for the user

b) in a cross-device scenario the user’s attention is now on the wallet (we have seen problems in the past with DIDComm cross-device flows)

UserPINs might be send as SMS Code or an email might not be aware to the user in this situation.

I therefore propose to extend the properties in the Credential Offer with either

1. add `user_pin_description` that is a short text describing how and where to get the userPIN OR
2. add `user_pin_description` in the metadata of the issuer

Additionally wallet implementers told us, they would favor a user_pin_length that says how many digits are expected for the userPIN such that this could be displayed in the app and might give further indications for the user what the correct PIN might be and improve the UI/UX in general.

`user_pin_description` might need i18n similar to what is already existing in the metadata, otherwise the issuer might know the language from the browser metadata.

‌

[Niels Klomp]

I am not really sold on the descriptions, as that would also mean you would need i18n etc like you mentioned. If you want to do something like that it makes sense to have predefined values only, so a wallet could determine how to react/display something. But IMO this is a concern of the issuer application to begin with. The issuer itself can be fully decoupled from the application, and could even have multiple applications using the same issuer.

Regarding the userpin length. That for sure would be something which improves UI/UX, as the wallet now knows how render the pin screen. I like individual digits more than having an input field up till a certain amount of digits.

Another improvement would be to have a hash that combines the nonce and the pin, so the wallet would be able to know that the user is entering the correct pin, instead of having to rely on failure later down the road.

[Kristina Yasuda]

+1 to user_pin_length.

on user_pin_description, I think it should be up to the issuer to display to the user where to find the pin. could sending over the wire where to find pin, help attackers compromise that pin?

[Paul Bastian]

I can see that user_pin_description is more difficult, but in my opinion average users can be very dumb. In a scenario, where users will be “trained” to just scan QR-Codes and buttons, these users will easily overlook the message by the issuer that was next to the Depp-Link/QR-Code. In these cases the additional hint in the user_pin_descrption could come in handy. But yes, the user_pin_descrption could help an attacker.

Concerning the i18n, I think we will be running into similar issues with the display properties from the Issuers metadata, so the solution might be similar. Put the user_pin_descption into the issuer metadata? If metadata is requested with query like lang=en or this is part of a path, this would drastically reduce the size for issuer metadata and could be the same spot where to put a user_pin_descrption. Only downside is that you have the same description for all users, but that’s an acceptable tradeoff.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI