Torsten Lodderstedt

Paul and Torsten agreed on this proposal to add the key attestation to the existing JWT proof type: ``` { "typ": "openid4vci-proof+jwt", "alg": "ES256", "attestation" : ["",""] }.{ "aud": "https://credential-issuer.example.com",...

created https://github.com/openid/oid4vc-haip/pull/210

I see a couple of issues with this requirement and wouldn’t aim for a fully automatic solution. 1) the user data is typically provided in the context of a registration...

I see the benefit of early syntax checks, I also see the challenges associated with it. Just checking whether a JSON request object is correct JSON is one thing, going...

> Based on my implementation experience, having nonce endpoint issue nonces/challenges that can be used by any session is a big red flag. It is not a big issue on...

WG Call 19.6 - It seems the access token would primarily be used to manage/shard nonces. - for c_nonces, self contained nonces are sufficient - there might be value in...

I think adding the option to authenticate/authorize the call to the nonce endpoint significantly adds complexity due to the side effects for DPoP nonces and DPoP bound access tokens for...

Negotiation requires the POST request based approach, right? How should that work for the DC API? Is the RP supposed to send two request objects at once?

> then my suggestion would be to consider change the text you quote to say that there is no need to include client_id in the first request from the verifier...

As the question came up in the call today, here is the rational for this feature as fas as I remember from the initial discussions: The idea is to provide...