Joseph Heenan

The same text also appears in the [ISO mDL section](https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#appendix-E.2). I think the 'A non-exhaustive list of valid values defined by this specification' part of the sentence is very weird...

I agree with removing the batch credential endpoint, given that the normal credential endpoint can now issue multiple instances of a credential.

I think it would be worth asking if we actually need `client_metadata_uri`. Given we have federation entity_ids and a suggestion for a client_id_scheme that includes pulling metadata from a .well-known...

> sorry, I am probably missing something, if client_id belongs to a compromised or malicious client that is part of the ecosystem using the same client_id_scheme, how does including client_id_scheme...

@danielfett yes, exactly. For clarity whilst I can't identify a practical attack with the current client id schemes I do agree there's a real issue here we need to look...

> I've come to believe that the security concerns discussed in this thread primarily pertain to the redirect_uri client_id_scheme. If other client id schemes do not share this vulnerability There...

@David-Chadwick > then redefining client_id_scheme to indicate the trust scheme in operation (which in fact some of the values already do e.g. entity_id indicates OpenID Federation) then we might have...

@tplooker > * Simplify to have one client ID scheme of `uri` where when used, the URI needs to have a scheme of either `https` or `did`. > * To...

@David-Chadwick > The worst thing that can happen to the user is that RP1 (which is trusted) receives unexpected credentials from the wallet when it had not requested them. I...

> Wouldn't it require two different users to be colluding with a rogue RP (RP2) in order to gain access to a trustworthy RP (RP1)? In which case the two...