Gareth Oliver

I think it's worth noting that the solution being proposed for push notification does not require the wallet backend to be aware of which issuers have credentials in the wallet,...

I'm generally supportive of the feature and most of the mechanism. I strongly disagree with the approach of performing the notification endpoint registration in credential request. I don't think that...

I am not sure I agree with the assessment that v) is really an issue. We are considers flows where the user is initiating by activating a url (either through...

Oh, sure. From prior conversation with others on the spec my understanding was that OpenID4VCI was intended to support both going through some wallet sever infrastructure as well as directly...

@bc-pi: My understanding of your objection was that you do not agree that a wallet server infrastructure is a valid architecture, and therefore the complexity is not warranted. As a...

To provide completeness on the different approaches possible: A per-field or part-encrypted request/response provides the advantage (both now and in the future) of allowing some fields to be provided or...

As an added note: We may want to consider using a JWT rather than a JWE and provide the option to sign it to integrity protect the contents, and bind...

> We had a bit more discussion on this after the call and I think the cleanest solution would be to include the encryption key in the proof types (jwt...

Given time to think: As it stands, if we mandate request encryption if you want to use response encryption (and require that the client retrieves the encrypted keys in a...

> I think we'd have to decide whether to support this in the unsigned DC API request case, in which case we'd probably need some new rules around validation of...