Jan Vereecken

Suggest to also correctly reference the Key Binding JWT (KB JWT) in the section on "Crypto Suites", now it says HB JWT, which I think references the KB JWT from...

My preference would be 1. Prefix parameters to decrease collisions (e.g. `__display`) (option 2(-2)) 2. Use `nested` attribute (option 2(-1)) It keeps things simple, closely linked to the attribute and...

@Sakurann in the same way that the OID4VP spec allows a DID to be the `client_id` (when `client_id_scheme` = `did`) for a Verifier. it does seem consistent to me to...

I enquired with Steve Pannifer and Neil McEvoy from Consult Hyperion who have a lot of experience in payments industry. Below is the initial feedback that they gave. --- It...

I interpreted that discussion that using client metadata doesn't allow you to differentiate which alg you want for which credential. To use an example to clarify. You would convey the...

Having said that, I support @tplooker 's sentiment that having two places in the spec to negotiate this will lead to confusion especially if there are dependencies between the two....

I think the following also relates to this clause which I find confusing (Section 5.7) > redirect_uri: This value indicates that the Verifier's redirect URI is also the value of...

Good idea. Some thoughts: - It very likely that this information would be useful beyond this point (display in wallet, in a presentation flow). Doing it this way would probably...

I was wondering if we also should relax the link of `scope` to Presentation Definition. The current text reads > ## Using `scope` Parameter to Request Verifiable Credential(s) {#request_scope} >...

In my mind this is one of the only options to present self-issued/self-asserted credentials. I don't agree removing it from HAIP necessarily, but are we sure we don't remove a...