<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;">
Thanks Tim!
<div><br>
</div>
<div>Just one clarifying point on spec work - we did discuss shortening the WGLC period to approx 2 days (which seemed reasonable as we’ve already had quite a few discussions in the WG about starting WGLC once the last two PRs were merged), to try and get the
45 days public review period started before various OIDF staff vacations and hence the ID published a few weeks earlier, and several people spoke in support of that and I believe there were no notable objections. (As always WG members will also be able to
raise any comments on the spec during the public review period, and the editors/chairs will endeavour to respond to any issues raised before the formal vote on publishing starts.)</div>
<div><br>
</div>
<div>(If anyone thought differently let us know!)</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Joseph</div>
<div><br>
</div>
<div><br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 18 Dec 2024, at 04:36, Tim Cappalli via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols@lists.openid.net> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div>
<div style="color:rgb(59,59,59);font-family:"Roboto Mono",Menlo,Monaco,"Courier New",monospace,Menlo,Monaco,"Courier New",monospace;font-size:12px;line-height:18px;white-space:pre">
<div><span style="color:rgb(128,0,0);font-weight:bold"># DCP Working Group 2024-12-17</span></div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## Attendees</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> Kristina</div>
<div><span style="color:rgb(4,81,165)">-</span> Tim Cappalli</div>
<div><span style="color:rgb(4,81,165)">-</span> Steve Venema</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee Campbell</div>
<div><span style="color:rgb(4,81,165)">-</span> David Zeuthen</div>
<div><span style="color:rgb(4,81,165)">-</span> Brian Campbell</div>
<div><span style="color:rgb(4,81,165)">-</span> Hicham Lozi</div>
<div><span style="color:rgb(4,81,165)">-</span> Ryan Galluzzo</div>
<div><span style="color:rgb(4,81,165)">-</span> Daniel Fett</div>
<div><span style="color:rgb(4,81,165)">-</span> Christian Bormann</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul Bastian</div>
<div><span style="color:rgb(4,81,165)">-</span> Andrew Regenscheid</div>
<div><span style="color:rgb(4,81,165)">-</span> Bjorn Hjelm</div>
<div><span style="color:rgb(4,81,165)">-</span> Lukasz Jaromin</div>
<div><span style="color:rgb(4,81,165)">-</span> Victor Lu</div>
<div><span style="color:rgb(4,81,165)">-</span> Nemanja</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph Heenan</div>
<div><span style="color:rgb(4,81,165)">-</span> John Bradley</div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## Administrivia</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> vote for OID4VP ID3. <a href="https://openid.net/foundation/members/polls/346">https://openid.net/foundation/members/polls/346</a></div>
<div><span style="color:rgb(4,81,165)">-</span> schedule: Thursday (19) call is the last call of 2024. First 2025 call is 2025-01-07.</div>
<div><span style="color:rgb(4,81,165)">-</span> Hybrid meeting @ OSW (Tuesday before), no registration link yet.</div>
<div><span style="color:rgb(4,81,165)">-</span> Steve: Is the appendix of (?) duplicative?</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: VP is defining framework, HAIP is telling you how to use that framework interopable</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul: HAIP is just narrowing down options</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: Nothing in HAIP should be new, just referencing bits</div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## 2025 Budget and Goals</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> Kristina reviews the planned schedule for 2025 (documented in agenda)</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: like the idea of the test events, need to put call out early. Need to get early Jan if doing feb, more time if doing IIW</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: IIW is too late for 1.0 feedback</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: then need to do Feb 25. More details in Jan</div>
<br>
<div>From chat:</div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> MOSIP Connect is 3/10 in Manila. TBC who from OIDF staff would lead, but they have a desire to propose a conformance process to countries including OIDF4VC test suites</div>
<div><span style="color:rgb(4,81,165)">-</span> DICE is March 4/5 in Zurich, with a Unconference model, cohosted by Kaliya.</div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> David Z: might be an ISO test event the same day</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: 4th</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: why don't we test OpenID4VP at the ISO test event?</div>
<div><span style="color:rgb(4,81,165)">-</span> Hicham: if it's ready, will be included</div>
<div><span style="color:rgb(4,81,165)">-</span> Gail: Same time as STA event?</div>
<div><span style="color:rgb(4,81,165)">-</span> David Z: will get back with dates</div>
<br>
<div>Add comments: <a href="https://docs.google.com/document/d/137R2qJmsTHlalXUMV8W6kEQSTaFAMga6HFpu7vY1KlE/edit?tab=t.0">
https://docs.google.com/document/d/137R2qJmsTHlalXUMV8W6kEQSTaFAMga6HFpu7vY1KlE/edit?tab=t.0</a></div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## Conformance Tests</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: have verifier tests now, used with Funke</div>
<div><span style="color:rgb(4,81,165)">-</span> Gathering more requirements</div>
<div><span style="color:rgb(4,81,165)">-</span> DC API is listed, as well as DCQL</div>
<div><span style="color:rgb(4,81,165)">-</span> Next is VCI</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph can help on the tests or if you have feedback</div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## Spec Work</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> 276: thanks for all the work</div>
<div><span style="color:rgb(4,81,165)">-</span> Can we start implementer's draft for OpenID4VCI?</div>
<div><span style="color:rgb(4,81,165)">-</span> Realistically 45 day review would start post-12/24</div>
<div><span style="color:rgb(4,81,165)">-</span> Second ID should come before the end of February</div>
<div><span style="color:rgb(4,81,165)">-</span> Any objections? None</div>
<div><span style="color:rgb(4,81,165)">-</span> Chairs will send out WGLC email by tomorrow</div>
<div><span style="color:rgb(4,81,165)">-</span> Discussion around process and timelines, no action</div>
<br>
<div><span style="color:rgb(128,0,0);font-weight:bold">## HAIP</span></div>
<br>
<div><span style="color:rgb(4,81,165)">-</span> 122: ready for merge, will be merged after pipeline issues</div>
<div><span style="color:rgb(4,81,165)">-</span> 135: session transcript for DC API</div>
<div><span style="color:rgb(4,81,165)">-</span> question around hashing nonce, clientId, and origin due to other parties being in the flow</div>
<div><span style="color:rgb(4,81,165)">-</span> David Z: makes sense to hash it, ex: cloud HSM, might need to send the whole thing, more privacy</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul: agree, same as for normal OID4VP</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: weren't we going to put it in the base spec and have it be generic for all credential formats?</div>
<div><span style="color:rgb(4,81,165)">-</span> David Z: mdoc to create the mdoc specific device response.</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: it was the AAD</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: last week made decision to put session encryption over DC API in the base spec, and specific algos in HAIP</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: SD-JWT KB defined in VP, maybe handover should be there too?</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: Think VP is a better place</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul: agreed</div>
<div><span style="color:rgb(4,81,165)">-</span> Objections?</div>
<div><span style="color:rgb(4,81,165)">-</span> Hicham: what about origin in the API vs here?</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: origin comes from platform, client ID comes from verifier</div>
<div><span style="color:rgb(4,81,165)">-</span> John: client ID may be operating from different origins. Trust mark is over the client ID.</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: multiple client IDs on same origin</div>
<div><span style="color:rgb(4,81,165)">-</span> Hicham: there may be cases where audience should be restricted</div>
<div><span style="color:rgb(4,81,165)">-</span> John: running a verifier as a service, origin and client ID will be different</div>
<div><span style="color:rgb(4,81,165)">-</span> Brian: re: SD-JWT, right now there's onyl the facility to include the client ID, based on audience. Is there a need to diverge for mdoc?</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: each thing has a reason: nonce for replay, origin for mitm protection</div>
<div><span style="color:rgb(4,81,165)">-</span> John: if signed, no need for platform</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: yes, you do, sign origin into response</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: need to be able to tell where it comes from</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: unsigned, already passing it in the client ID parameter</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: need to have expected origins</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: why wouldn't we universally opt to trust the origin from the platform in both cases. more consistent.</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul: suggest adding origin to KB JWT then?</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: yes</div>
<div><span style="color:rgb(4,81,165)">-</span> Tim: RP ID in WebAuthn is similar to client ID and origin is the same. Matching origin to client ID is server side.</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: Doesn't hurt to sign it</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: agree, most robust way forward</div>
<div><span style="color:rgb(4,81,165)">-</span> Hicham: agree that client ID is controlled by verifier,even if you have multiple client IDs per origin, verifier will still verify. owner of origin controls the signature, doesn't provide more value.</div>
<div><span style="color:rgb(4,81,165)">-</span> John: to route it back to the appropriate party is important</div>
<div><span style="color:rgb(4,81,165)">-</span> Brian: No downside to signing the origin, just potentially divergence from other credential formats</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: whatever we do here would affect KB JWT as well. When the request is signed, put cliet ID as audience, when unsigned, use platform provided origin as the client ID and put it in the response. Why is
this not sufficient?</div>
<div><span style="color:rgb(4,81,165)">-</span> Daniel: makes sense to add it here and to KB JWT.</div>
<div><span style="color:rgb(4,81,165)">-</span> Paul: agree. fine for OID4VP to define parmaeter for KB JWT. unique to DC API not for other transports.</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: need to be careful about defining overlapping behaviors for signed requests. Bit weird to have verifier also verify if wallet is.</div>
<div><span style="color:rgb(4,81,165)">-</span> Kristina: might be an argument to not have origin in KB JWT</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: for signed requests, you don't get any value from the verifier for origin. no value in verifier checking the origin.</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: Still need to trust the wallet did that. Wallet is more likely to skip the check. Verifier wants to know the response is for them. Wallet may just want requests to suggest. More robust check.</div>
<div><span style="color:rgb(4,81,165)">-</span> Joseph: veriifer still needs to trust the wallet, wallet could just change origin. verifiers skip checks all the time</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: maybe an argument for no expected origins, so it can't be skipped</div>
<div><span style="color:rgb(4,81,165)">-</span> Lee: expected origins still gives you the MITM attacker not getting anything. I think Joseph is right in that for a signed request the verifier origin check is somewhat redundant if everything is working correctly.
So really is just a question of consistancy between keeping the structure the same between signed and unisgned requests</div>
<div><span style="color:rgb(4,81,165)">-</span> Tobias: clarify Lee's comment, it is redunant under teh assumption the wallet has done what its supposed to do. Still useful server side, but understand it is redundant. In signed request, allows wallet to fail
faster.</div>
<br>
</div>
</div>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
Openid-specs-digital-credentials-protocols@lists.openid.net<br>
https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols<br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>