<div dir="ltr">Agenda:<br><br>Conformance team hiring <a href="https://openid.net/certification-program-recruiting-java-developer/">https://openid.net/certification-program-recruiting-java-developer/</a><br>Conflicts of 9th & 11th April calls with TDI/OAuthSecWorkshop<br>Browser API consensus to create a PR: <a href="https://github.com/openid/OpenID4VP/issues/125">https://github.com/openid/OpenID4VP/issues/125</a><br>Request uri extension now has many approval, final consensus to merge: <a href="https://github.com/openid/OpenID4VP/pull/59">https://github.com/openid/OpenID4VP/pull/59</a><br>SD JWT VC PR: <a href="https://github.com/openid/OpenID4VP/pull/115">https://github.com/openid/OpenID4VP/pull/115</a><br>Please review VP mdoc/mdl section updates: <a href="https://github.com/openid/OpenID4VP/pull/128">https://github.com/openid/OpenID4VP/pull/128</a><br>Anything else to do for VP ID3? Current proposed list: <a href="https://github.com/openid/OpenID4VP/issues?q=label%3Aid3+">https://github.com/openid/OpenID4VP/issues?q=label%3Aid3+</a><br>EU interop event profiles: <a href="https://drive.google.com/drive/u/3/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR">https://drive.google.com/drive/u/3/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR</a><br>Mechanism for wallet to detect cross device flows: <a href="https://github.com/openid/OpenID4VP/issues/134">https://github.com/openid/OpenID4VP/issues/134</a><br><br>Attendance:<br><br>- Orie Steele<br>- Kristina Yasuda<br>- Joseph Heenan<br>- Jan Vereecken<br>- Bjon Hjelm<br>- Christian Bormann<br>- Daniel Fett<br>- David Chadwick<br>- David Waite<br>- George Fletcher<br>- John Bradley<br>- Lukasz Jaromin<br>- Oliver Terbu<br>- Ryan Galluzzo<br>- Sam Goto<br>- Sebastien Bahloul<br>- Tim Cappalli<br>- Tobias Looker<br>- Torsten Lodderstedt<br><br>Introductions:<br><br>Sam Goto: Work for Google Chrome, glad to be here.<br><br>External Organizations and Upcoming Events:<br><br>Discussion of canceling upcoming calls that conflict with OAuthSecWorkshop.<br><br>Decision to cancel both 9th and 11th calls in April.<br><br>Tim: Federated Identity WG charter approved at W3C, see request to join as member organizations shortly.<br>... We will look at OIDC Profiles for the FedCM API.<br><br>Joseph: We're hiring a Java Developer for conformance tests.<br><br><a href="https://openid.net/certification-program-recruiting-java-developer/">https://openid.net/certification-program-recruiting-java-developer/</a><br><br>... Vote on first implementers draft for OIDC 4 VCI is open.<br><br>Topic: Browser API Proposal<br><br><a href="https://github.com/openid/OpenID4VP/issues/125">https://github.com/openid/OpenID4VP/issues/125</a><br><br>Torsten: We've been looking at how OIDC4VP can be profiled for W3C Digital Credentials API.<br>... There have been iterations in the Google Doc.<br>... This API will replace custom schemes, and help wallet discovery and invocation and support cross device flows.<br>... The proposal also covers regulatory requirements.<br>... see <a href="https://docs.google.com/document/d/1A10PZ_DviMJeyy2mDFt2QLcXUbT4O2dc_BizNXAD2PQ/edit">https://docs.google.com/document/d/1A10PZ_DviMJeyy2mDFt2QLcXUbT4O2dc_BizNXAD2PQ/edit</a><br><br>Summary of the default mode in the document.<br><br>Summary of Request URI with POST method.<br><br>There exist regulatory requirements for a wallet to trust an EU cert that is not in the web PKI.<br>See the section on RP Authentication.<br><br>Wallet posts nonce to verifier, in order to ensure freshness of signed presentation requirements.<br><br>Torsten: Please provide feedback on this proposal.<br>... Are we ready to start a PR based on this proposal to OIDC4VP?<br><br>John: I like the proposal, but how will this work with the German repudiable presentation flow?<br>Torsten: Great question, the PID style presentation would not use the same session, we would use an hmac.<br>... the difference would be only in the credential and credential presentation.<br><br>John: Seems like the credential is HMAC'd to verifier, instead of issuer signed... and this will work with the German credential system.<br>... We can't do terminal verification in the same way, we will need to the request URI scheme.<br><br>Tobias: Regarding <a href="https://github.com/WICG/digital-identities/issues/92">https://github.com/WICG/digital-identities/issues/92</a><br>... It seems like the wallet always needs to validate the web origin, plus a possible additional layer based on certificates or wallet provider nonce.<br>... Will the user need to select the trust model?<br><br>Torsten: The wallet would always get an attested origin, ... the wallet would get some data about the RP.<br>... The web origin has some meaning, but it does not fulfill all regulatory requirements.<br><br>Tobias: If negotiation happens out of band, the user might select a credential, but then the system might dead end... this could impact capability negotiation.<br><br>Torsten: Everything necessary for selection should be in the first request.<br>... I would like to see the full protocol flow happen through the browser API.<br>... current proposal uses OIDC4VP for components that we might not see supported in the browser API.<br>... we need to get implementer feedback.<br><br>Tim: Can we add a new parameter called "expected origin" instead of overloading client id.<br>... A single client id might support multiple origins.<br><br>Torsten: The web platform provides the client id to the wallet.<br><br>Tim: The web origin was never meant to be a client id.<br><br>Torsten: Client id would be matched to the origin, we might need to rework that part.<br><br>Oliver: In request URI post message flow<br><br>Torsten: Today, we assume it's the same client id and the web origin.<br><br>...<br><br>Torsten: we can use all the parameters of OIDC4VP... <br><br>John: If we do allow direct post, we will still need a response to the browser... regarding dead end credentials, that's going to be hard to eliminate... The idea with the web api, is that you don't know which wallets the user has... the same RP might have several trust marks for different organizations... what can we put into credential selection, in the request, so that all metadata is offline available.<br>possibly trust paths, trust marks, etc... This information will help filter wallets that cannot satisfy requirements.<br><br>Joseph: Not hearing any objections to this proposal. Any objections to starting a PR for this as an appendix in OIDC4VP?<br><br>Tobias: We discussed alternative models that don't require nonce... seems there are many parts of the solution still in progress.<br><br>Joseph: We will need implementation experience.<br><br>Oliver: I reserve the right to comment on the query syntax.<br><br>Joseph: We have consensus on the path forward.<br><br>Topic: <a href="https://github.com/openid/OpenID4VP/pull/59">https://github.com/openid/OpenID4VP/pull/59</a><br><br>Joseph: Any objections?<br><br>Torsten: Impressive number of approvals.<br>... big improvement, I will merge after the meeting.<br><br>Topic: <a href="https://github.com/openid/OpenID4VP/pull/115">https://github.com/openid/OpenID4VP/pull/115</a><br><br>Jan: Some comments on language, such as "unsecured payload" which was added to SD-JWT-VC.<br>... there were questions on how to actually do the matching based on the Path... based on the unsecured payload.<br><br>Kristina: We have 2 options... issuer signed jwt and sd-jwt won't have values.<br>... so PE needs to assume the wallet reconstructs the verified version( with disclosures / processing applied).<br>... or do something like mDoc... I agree with oliver that the unsecured payload is probably the best path.<br><br>Oliver: the path parameter in PEx is defined over the input document... so it's ambiguous in the context of SD-JWT.<br><br>Jan: sounds like you support the new query format.<br><br>Kristina: There is a thread on client id scheme, which I thought we agreed to resolve on another issue.<br>... and one on algorithm values and client metadata.<br><br>Tobias: we have explicit language on this<br><br>Kristina: the verifier cannot specify per credential algorithms.<br><br>Kristina: in client metadata, it cannot be put into input descriptor level algorithms. (ES256, EdDSA, ECDH).<br><br>Torsten: the format and input descriptor only applies to SD-JWT, syntax, it's not about algorithms.<br><br>Tobias: Seems like a mistake to do negotiation in 2 places.<br><br>Torsten: Then we should do it in Presentation Definition only.<br><br>Oliver: We can't do that, it would be a breaking change.<br><br>Tobias: It should be in client metadata.<br><br>Kristina: This disagreement is not new, but this PR is not the place to resolve it.<br><br>Jan: Why was the object empty being mentioned in the HAIP.<br><br>Torsten: because Mike Jones and I were resolving it, and Mike said as much as possible belonged in the client metadata.... format was the only thing that went into the input descriptor.<br><br>Oliver: Why?<br><br>Kristina: Client metadata applies to all credentials, input descriptor is per credential requirements.<br><br>Tobias: Why request per credential?... we don't do this kind of negotiation in OIDC.<br><br>Torsten: Because code paths are format specification.<br><br>Tobias: If you support SD-JWT with an alg for a given credential, why create a new layer?<br><br>Torsten: We can get rid of client metadata, except it would be a breaking change.<br>... we should address in a future PR, separate issue.<br><br>Orie: can we make breaking changes?<br><br>Joseph: Yes, we just want to keep them in small PRs when possible.<br><br>Topic: <a href="https://github.com/openid/OpenID4VP/pull/128">https://github.com/openid/OpenID4VP/pull/128</a><br><br>Joseph: Some updates regarding mdl/doc.<br>... please review.<br><br>Kristina: There seems to be several issues for id3.<br><br>Tobias: Is there any conversation about query syntax on id3?<br><br>Joseph: We wanted to defer, so we can land the browser API related stuff first.<br><br>Topic: EU Interop Profiles<br><br>Joseph: Please review: <a href="https://drive.google.com/drive/u/0/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR">https://drive.google.com/drive/u/0/folders/1uNFHfqV9GSi4HjZX3PCP-0m3auBDsZVR</a><br>... send your feedback to the list.<br><br>This Thursday, we will discuss high level requirements and priorities.<br><br><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:10pt 0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">ORIE STEELE</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap"><br></span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Chief Technology Officer</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span><span style="font-size:8pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">www.transmute.industries</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:0pt 0pt 10pt"><a href="https://transmute.industries" target="_blank"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></a><br></p></span></div></div></div></div></div></div></div>