Martijn Haring

This issue indeed addresses it quite well. I would even go one step further and consider to remove all error codes that could potentially leak information unless providing that specific...

As discussed here, there is no disagreement to have response encryption as a mandatory item. As such, both RPs and wallets will need to implement support for response encryption. Since...

As mentioned in https://github.com/openid/OpenID4VP/pull/155#discussion_r1668871320 in order to provide interoperability of the browser api, we need to define the full details and require support of at least one mechanism for response...

As also mentioned in this comment: https://github.com/openid/OpenID4VP/pull/266/files#r1775413078 optionality should not exist for data elements or credentials but only on a use-case basis. Within satisfying a certain use case, optionality doesn't...

> After quite a bit of back and forth, I made changes to this PR that hopefully find a good compromise between all proposed solutions. Based on Tobias' latest proposals,...

#380 doesn't describe how both the RP and the wallet know which parameters go into the detached information. (in the case of ECDH-ES, what goes into the APU and APV...

As this item is labeled 1.1, I would like to make sure that we don't need to do anything in 1.0, however I don't think that's the case. To give...

I was asked what a potential solution would look like. This depends quite a bit on what's already possible, but one potential solution could be to add an extra parameter...

I don't think "validate_apu_apv" would address the full problem. (Also if this would require a change to JWE, then that seems like it's not a solution that we should pursue)....

> The following two statements allow for a gap in implementations that lead to broken flows, right? > > > the Verifier MUST verify that one of the referenced profiles...