Christian Bormann

>But I cannot express that: in openid4vci as it stands I have to accept any of the outstanding nonces. In contrast if my issuer is happy to honor any valid...

> > I think it might be an option to require the wallet to pass an access token, but leave it upto the issuer whether it actually requires & checks...

That would mean that display information inside the credential response would overrule the generic display information inside the issuer metadata if I understand correctly?

> How will this work in combination with vct metadata? > > Should a wallet generally use this order for display in the wallet (1. Is highest priority): > >...

> All of the Client Identifier Prefixes defined in OpenID4VP other than origin contain an underscore, rendering them an invalid URI scheme. If the origin prefix were changed to e.g....

> The verifier (in this case the wallet) is not known to the client (RP) at the time the request is sent with the client identifier prefix (Looking at the...

This PR is not a 100% done, but the core parts should be here and we need a bit more discussion/attention so I'll convert to ready for review. My take...

Some eyes especially on the possible values for `user_authentication` and `key_type` would be really helpful imho

I would prefer to completely remove `key_storage_type` and `user_authentication` and directly go to `apr` only which should then become a mandatory claim. It feels like we need the complexity of...

> This is some feedback that I got from security advisors: > > "We think the key_storage_type and user_authentication are not needed, but the APR should be split into two...