Kristina

discussed in the WG call, @awoie supported. no strong opinions otherwise.

i think there is misunderstanding and the examples in the issues should not be taken without the context and without the specification text around them. the first example in what...

a quick note that a proposal that introduces any changes to the token response (like a new top level claim `credential_identifier`) would not work for implementations like Microsoft's that re-use...

To the question... As discussed during DCP WG call, one information that needs to be communicated between the issuer and the wallet is how many copies of credentials need to...

One of the ways forward that minimizes breaking changes would be - keep Credential Endpoint as-is - modify the proof structure in the batch endpoint - add metadata for how...

WG discussion: - make a suggestion to recommend people to follow FAPI 2.0 instead of security BCP, to make it actionable - but we need to clarify that some of...

so that Issuer can use c_nonce from the access token in the credential error response when telling the wallet which c_nonce to use? that is an implementation detail, i don't...

Access Token is opaque to the Wallet, it is consumed by the Issuer. the wallet cannot look into the AT and extract any claims.

does anyone remember why we chose c_nonce as opposed to putting access token hash into the proof? if access token is sender-constrained, wouldn't that be stronger than c_nonce, so maybe...

labelling pending-close and closing in a week, unless objections, because we discussed this extensively especially in the context of this PR https://github.com/openid/OpenID4VCI/pull/392, and I beleive the outcome was consensus to...