Joseph Heenan

We discussed on yesterday's WG call; though people probably need more time to think about it. > A single top-level attribute credential_response_encryption is expected to be send with request to...

Are you suggesting this is mandatory to implement? That seems like it might trigger the same objections that resulted in the notification endpoint being optional to implement. "1c" is inevitably...

Another suggestion after discussion on today's WG call - if this only makes sense in the case where a credential offer is used (which seemed to be the consensus today),...

Did any of them have thoughts that might help answer questions 1 or 2 above? Or can we ask them to give some feedback on that?

> How many implementations are there that use Document? The issuer implementation I was aware of that used Document has now changed to IssuerSigned.

Thanks @cobward - we raised that with the 23220-3 author (in particular Matthias in March 2024), and it was raised again on https://gitlab.opencode.de/potential/interop-event/-/issues/9. As far as I know in 23220-3...

I think this change as suggested would make the security issue highlighted in https://github.com/openid/OpenID4VCI/issues/19 worse? On Paul's comment: > Additionally it relates to the latest thinking that wallet/client attestation could...

I don't think we currently use 'null' JSON values anywhere in the VCI spec. I would argue that JSON nulls are generally problematic and should be avoided as many JSON...

> If everyone could please review this section in VC Type Metadata and provide feedback before I create the PR for VCI on Monday, that would be very helpful: https://vcstuff.github.io/sd-jwt-vc-types/danielfett/fix-claims/draft-fett-oauth-sd-jwt-vc-types.html#name-claim-metadata...

I had a look after the call and would definitely not object to moving that section, I agree in the current position it does somewhat make the credential endpoint section...