
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Hi all,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Below are the notes for today’s call</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Best Regards,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Christian</div></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">-------</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div>--- Attendees:</div><div><br></div><div>Brian Campbell</div><div>Bjorn Hjelm</div><div>Christian Bormann</div><div>Daniel Fett</div><div>David Waite</div><div>David Zeuthen</div><div>Gareth Oliver</div><div>Joseph Heenan</div><div>Kristina Yasuda</div><div>Martijn Haring</div><div>Michael Jones</div><div>Peter Sorotokin</div><div>Rajvardhan Deshmukh</div><div>Tobias Looker</div><div>Tom Jones</div><div>Torsten Lodderstedt</div><div>Victor Lu</div><div>--- Events/Updates:</div><div><br></div><div>- IETF 123 coming, consider joining sessions at relevant working groups like OAuth!</div><div>- Openid4VP vote got closed and has been approved as final 1.0, congrats!</div><div><br></div><div>--- Issues/PRs:</div><div><br></div><div>OpenID4VCI:</div><div><br></div><div>Presentation During Issuance #509 - <a href="https://github.com/openid/OpenID4VCI/pull/509">https://github.com/openid/OpenID4VCI/pull/509</a>:</div><div><br></div><div>Gareth summarizes that the current status quo boils down to bike shedding smaller details how it fits into the overall process, especially the binding between the issuance and presentation flows. He concludes that the solution proposed by Daniel addresses the issue that was discussed, but the discussion focuses around currently the endpoints and response mode (since we are modifying the session transcript). Tobias adds that from his perspective it makes sense to post the response of the oid4vp request directly to the iar endpoint instead of a different one and also a bit easier to extend to other purposes. Daniel responds that there might be some protocols that you want to leverage that are not using http, but he is fine with optimizing for the openid4vp case. Daniel recommends to at least turn the current proposal into implementer's advice if they want to introduce new protocols on top of this endpoint to avoid the possible dangers of missing this possible attack vector. Daniel also mentions that he won't be available next week and asks if someone can take over the PR.</div><div>Kristina asks about the response mode and Daniel agrees that it would probably be cleaner to introduce a new response mode. Tobias responds that he created an interaction diagram to illustrate the proposal re-using the iar endpoint, but agrees that we should not lose the possibility to also leverage other endpoints. He continues to explain that you could just keep calling the iar endpoint for different authorization steps and the authorization server has complete control how to split the services internally.</div><div><br></div><div>Gareth explains that the request/response would be very similar to DC API and it should basically use the requirements for the DC API flow (even though the request isn't going through DC API). Joseph adds that we might need to add a client id scheme/prefix for that flow. Torsten asks about the Client ID Scheme and why would we need a new one and how the client id is authenticated. Joseph answers that we can re-use existing schemes, but we might need a new client id scheme for the unsigned case (since we are bootstrapping from an existing flow). Gareth adds that the wallet is already initiating an issuance process with that endpoint and is continuing in that flow. Martijn adds that the crucial bit from a security perspective is that the origin that initiated the session is the same. These kind of flows where you are sending evidence are the biggest risk for forwarding attacks and as long as we should be sure that whatever is initiating the session needs to be protected. Torsten asks what exactly the current mode means and advocates to treat this flow as a usual openid4vp invocation.</div><div><br></div><div>Tobias responds that the similarity is that the authorization request is going directly to the wallet and back whereas vanilla openid4vp requires redirect in same device flow. He continues that from that perspective, the security is more similar to the DC API since you are staying in the session. The wallet knows how sent the request since it made the request to the endpoint. Torsten responds that it has consequences how we deal with that request and we should be careful from a security perspective. Daniel comments that from his perspective the flow is similar to DC API since the wallet knows where the request comes from similar to how it does for DC API. From that perspective, we are a lot close to DC API and can re-use things that were introduced in the DC API. Daniel continues that we should not use origin as the client id scheme, but a lot of considerations apply. Torsten asks why we shouldn't support the multi-rp request and Daniel responds that from his perspective we probably don't need it. Daniel explains that right now the processing described in the PR is almost the same as DC API.</div><div><br></div><div>Peter brings up that from his implementation experience, implementing it with the same endpoint felt a lot better (tunneling). Gareth asks if we should use the DC API response mode then and Joseph responds that he would prefer a new response mode to make it clearer. Tobias agrees. Gareth volunteers to update the PR while Daniel is away for a bit and Tobias volunteers to help if possible. Gareth asks about version and type support similar to DC API? Joseph states that he doesn't agree on the versioning and we should base support upon the wallet indicating its support in the initial request. Tobias states that type values alone will create problems if it's the only solution to communicate type and asks if we can get type somehow higher level type with more detailed information, that is provided via the client (wallet) metadata.</div><div><br></div><div>Kristina summarizes that we need a bit more time to think about the wallet protocol support discovery and we should focus on the response mode and finishing this PR and move the supported types discussion into a separate discussion/PR.</div><div><br></div><div>HAIP: </div><div><br></div><div>remove any mandatory requirements for attestations #188 - <a href="https://github.com/openid/oid4vc-haip/issues/188">https://github.com/openid/oid4vc-haip/issues/188</a>:</div><div><br></div><div>Martijn asks to not mandate attestations in HAIP and Torsten asks to clarify if we are talking about key attestations or about all attestations. Torsten agrees with the requirement scoped for key attestations and states that he believes we need one mechanism for client attestation. Christian agrees that key attestations are a bit special and it would be better to have native key attestations, but client attestations are part of your normal interaction with the authorization server which is already happening in oauth/jwt land, so it makes sense to limit choices there.</div><div><br></div></body></html>