
<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>Attendees:</div><div><br></div><div>Giuseppe De Marco</div><div>Joseph Heenan</div><div>Michael Jones</div><div>Kristina</div><div>Torsten</div><div>David Luna</div><div>Andrew Hughes</div><div>Arnaud Bruyer</div><div>Brian Campbell</div><div>Oliver Terbu</div><div>Victor Lu</div><div>Jin Wen</div><div><br></div><div><br></div>David Luna introduced himself - he’s in the CTO office at Forgerock.<div><br></div><div>Next week’s call with be cancelled due to EIC.</div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/pull-requests/488">https://bitbucket.org/openid/connect/pull-requests/488</a><br></div><div><br></div><div><br></div><div>Torsten ask if we have a need to add support for authorization_pending in the code flow</div><div><br></div><div>Oliver says he does have a use case that needs it and that the preauthorised code flow does not work for his use case, but he was okay if this was deferred to a later PR.</div><div><br></div><div>Brian thinks there was various other references in the document that suggest authorization_pending is only for pre-auth flow, and that using it in the code flow is weird - the user completes authorization, then gets redirected back to the RP, and then the RP is told authorization is still pending. And would not work well with existing OAuth clients. It also overlaps with differed issuance.</div><div><br></div><div>Torsten said his preference would be to only have one mechanism and hence to remove either authorization_pending or differed issuance.</div><div><br></div><div>Oliver said scenario is when user is providing evidence remotely and that needs to be in some cases manually checked before any credential can be issued.</div><div><br></div><div>Kristina suggested using pre-auth code flow instead. Torsten said this was tricky if the flow had been started in a wallet.</div><div><br></div><div>Joseph noted that there was a similar discussion about this in the ekyc-ida working group but didn’t think they had found a solution.</div><div><br></div><div>There was a fairly long discussion with 4 or 5 possible alternative approaches but no clear way forward.</div><div><br></div><div>Kristina/Torsten agreed to put the code flow change into a separate PR so we can merge the original fix that moves authorization_pending from success to error. Oliver to open a ticket so we can discuss further.</div><div><br></div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/pull-requests/472">https://bitbucket.org/openid/connect/pull-requests/472</a></div><div><br></div><div>Torsten to fix conflicts, then this will be merged and Kristina will apply her editorial suggestions separately.</div><div><br></div><div><br></div><div><br></div><div>https://lists.openid.net/pipermail/openid-specs-ab/2023-May/009904.html</div><div><br></div><div>David talked about his email on how the issuer might know if a wallet has accepted a credential or not.</div><div><br></div><div>Kristina said MS sent a proprietary callback from the wallet in this case. David said they were doing the same. Giuseppe might also have interest.</div><div><br></div><div>Torsten asked why it was needed. David said because the wallet/user can reject the credential and the issuer might want to try again. Torsten said the wallet has control back at that point so could send the user back to the issuer. Kristina said it depends how the flow had started - e.g. the issuer might send an sms saying “sorry it failed, click here to try again”.</div><div><br></div><div><br></div><div><br></div><div></div></body></html>