Kristina

@David-Chadwick I tried bring clarity along the lines you suggest here: https://github.com/openid/OpenID4VP/pull/258/files#r1766818286

discussed on the wg call, agreed to modify the PR in the direction that allows to change the structure of VP Token in the future. and change `defined by this...

The way the discussion has gone, - if PE is the only query language in 1.0 (ie mandatory in 1.0), there is no consensus that PE is mandatory in 1.1,...

> I do not think that these two statements logically follow. PE is the only query language in 1.0, this is true. But in other versions there are other languages....

superseded by https://github.com/openid/OpenID4VP/pull/266

for vanilla openid4vp, didn't we solve this with request_uri_method=post? where the wallet can tell its trust framework when obtaining the request object? and for openid4vp browser api profile, there is...

> Unfortunately not, there's clauses like this: > > > The Client Identifier value in the client_id Authorization Request parameter and the Request Object client_id claim value MUST be identical....

discussed in a WG, agreed on the requirements/problem statement: - when the same wallet being able to hold multiple credentials coming from different trust frameworks, one request (one DCQL query)...

i think @GarethCOliver also put some thoughts in this issue thread https://github.com/openid/OpenID4VCI/issues/339#issuecomment-2877238722

WG discussion: - clarification: only applies to credential response - what needs to be non-encrypted is outside credentials parameter; ie what does not need ot be encrypted is not credentials...