OpenID4VCI
OpenID4VCI copied to clipboard
[AS] `wallet_issuer` and `user_hint` requires accurate explaination about their scopes and usefulness
My colleagues and I never really understood the parameters wallet_issuer and user_hint and this PR doesn't solve that either. I think the specification is missing text on this, but unsure if this should be a target of this PR
Originally posted by @paulbastian in https://github.com/openid/OpenID4VCI/issues/142#issuecomment-1848953666
I also don't believe we need yet another identifier for a wallet, especially if it is about identifying the wallet provider towards the credential issuer, because the credential issuer has the wallets client ID.
@tplooker my PR goes in this direction, where wallet_issuer is renamed to wallet_id
https://github.com/openid/OpenID4VCI/pull/142#issuecomment-1848953666
This seems related to the discussion about whether to have a wallet identifier at all that is distinct from its Client ID. See issue #142.
I think both parameters were meant to facilitate using OID4VP during OID4VCI to obtain additional VCs from the user to authenticate the user. However, it is currently not very clear how those parameters gets passed from issuance flow to the presentation flow. might also be related to #20
from @jogu
https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#name-dynamic-credential-request contains:
Note to the editors: We need to sort out the Credential Issuer's client_id with the Wallet and potentially add an example with wallet_issuer and user_hint.
We should fix/remove this.
Thanks Kristina! Tagging onto the 1.0 milestone then as we should at a minimum remove that note before 1.0 :)
Perhaps the wallet_issuer and user_hint parameters should be removed along with the note? They have honestly never made sense to me and still don't.
#473 is related in so far as I can tell
Discussed on 1st May WG call - we should just delete the Dynamic Credential Request and the references to it spread through the spec, in favour of eventually having #473