<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Spec Call Notes 3-Oct-22<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">George Fletcher<o:p></o:p></p>
<p class="MsoNormal">Tobias Looker<o:p></o:p></p>
<p class="MsoNormal">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">David Waite (DW)<o:p></o:p></p>
<p class="MsoNormal">Dima Postnikov<o:p></o:p></p>
<p class="MsoNormal">Karthik Sivasamy<o:p></o:p></p>
<p class="MsoNormal">Andrii Deinega<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Pull Requests<o:p></o:p></p>
<p class="MsoNormal">              <a href="https://bitbucket.org/openid/connect/pull-requests/">
https://bitbucket.org/openid/connect/pull-requests/</a><o:p></o:p></p>
<p class="MsoNormal">              PR #309: Addresses issues 1644 and 1647<o:p></o:p></p>
<p class="MsoNormal">                           Merged<o:p></o:p></p>
<p class="MsoNormal">                           We will republish the prompt=create spec<o:p></o:p></p>
<p class="MsoNormal">              PR #312: fix: [Federation] signed_jwks_uri explanatory text<o:p></o:p></p>
<p class="MsoNormal">                           Merged<o:p></o:p></p>
<p class="MsoNormal">                           We will start a two-week working group last call review of the Federation spec<o:p></o:p></p>
<p class="MsoNormal">              PR 310: Clean up of SIOPv2<o:p></o:p></p>
<p class="MsoNormal">                           Torsten approved<o:p></o:p></p>
<p class="MsoNormal">                           Mike still plans to review<o:p></o:p></p>
<p class="MsoNormal">                           Tobias made a comment<o:p></o:p></p>
<p class="MsoNormal">              PR #291: relaxed the requirement to use openid4vp for presentation during issuance (Issue #1599)<o:p></o:p></p>
<p class="MsoNormal">                           Was updated to reflect Thomas Bellebaum's concerns<o:p></o:p></p>
<p class="MsoNormal">                           Tobias now also approved<o:p></o:p></p>
<p class="MsoNormal">                           Merged<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Native SSO Spec<o:p></o:p></p>
<p class="MsoNormal">              We merged PR #306: Updates to Native SSO spec during the last call<o:p></o:p></p>
<p class="MsoNormal">              We will now start the Implementer's Draft review<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Issues<o:p></o:p></p>
<p class="MsoNormal">              <a href="https://bitbucket.org/openid/connect/issues?status=new&status=open">
https://bitbucket.org/openid/connect/issues?status=new&status=open</a><o:p></o:p></p>
<p class="MsoNormal">              #1589: Proposal for supporting "client discovery" in OIDC / OAuth2<o:p></o:p></p>
<p class="MsoNormal">                           We discussed the desire to pass client metadata in a DID document<o:p></o:p></p>
<p class="MsoNormal">                           Automatic registration is already a way to enable just-in-time client usage without pre-registration<o:p></o:p></p>
<p class="MsoNormal">                                         <a href="https://openid.net/specs/openid-connect-federation-1_0.html#name-automatic-registration">
https://openid.net/specs/openid-connect-federation-1_0.html#name-automatic-registration</a><o:p></o:p></p>
<p class="MsoNormal">                                         This is used by SIOPv2<o:p></o:p></p>
<p class="MsoNormal">                           Kristina asked about why the Automatic Registration requests need to be signed<o:p></o:p></p>
<p class="MsoNormal">                                         Mike answered that it's to prove possession of the keys published by the entity statement<o:p></o:p></p>
<p class="MsoNormal">                           Tobias described an effort to create an OAuth draft<o:p></o:p></p>
<p class="MsoNormal">                                         Mike expressed his desire to have it be compatible with Entity Statements<o:p></o:p></p>
<p class="MsoNormal">                                                       Just like past OAuth drafts derived from Connect drafts have been fully compatible<o:p></o:p></p>
<p class="MsoNormal">              #1451: [oidc4vci] Mandatory vs optional credential claims<o:p></o:p></p>
<p class="MsoNormal">                           Tobias stated that the claims included should be up to the issuer<o:p></o:p></p>
<p class="MsoNormal">                           Tobias sees three options:<o:p></o:p></p>
<p class="MsoNormal">                                         1. One option is that the requested claims are considered as a hint to the issuer<o:p></o:p></p>
<p class="MsoNormal">                                         2. The provider returns an error<o:p></o:p></p>
<p class="MsoNormal">                                         3. The claims that the requester can request are only the optional claims for that credential type<o:p></o:p></p>
<p class="MsoNormal">                           George said that a whole lot of errors can result from having various options<o:p></o:p></p>
<p class="MsoNormal">                           Given that selective disclosure is supported, even if a wallet has claims, they would not necessarily be released to RPs<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that in Connect, we request claims, the OP decides what claims to send, and ultimately the RP decides what to do<o:p></o:p></p>
<p class="MsoNormal">                                         That gives the RP the most actionable information<o:p></o:p></p>
<p class="MsoNormal">                                         For instance, then it can then give the best error messages possible, even when further processing isn't feasible<o:p></o:p></p>
<p class="MsoNormal">                           Tobias is concerned with over-disclosure<o:p></o:p></p>
<p class="MsoNormal">                                         Mike said that that can't be fixed in the protocol<o:p></o:p></p>
<p class="MsoNormal">                                         It is at a contract and trust framework level<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that returning errors is the least useful thing to do, from an ecosystem perspective<o:p></o:p></p>
<p class="MsoNormal">                                         Mike believes that not being able to return exactly what was requested is a normal case<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Redirection of .well-known URIs<o:p></o:p></p>
<p class="MsoNormal">              George has previously said that redirects are supported<o:p></o:p></p>
<p class="MsoNormal">              Andrii said that OpenID Connect Discovery says that the response should be 200 OK<o:p></o:p></p>
<p class="MsoNormal">              George thought that WebFinger allows redirects<o:p></o:p></p>
<p class="MsoNormal">                           WebFinger does support redirection, per
<a href="https://datatracker.ietf.org/doc/html/rfc7033#section-4.2">https://datatracker.ietf.org/doc/html/rfc7033#section-4.2</a><o:p></o:p></p>
<p class="MsoNormal">              Mike opined that the issuance document could choose to support redirection of its .well-known resource<o:p></o:p></p>
<p class="MsoNormal">                           But both Mike and Kristina want to seek John Bradley's viewpoint first ;-)<o:p></o:p></p>
<p class="MsoNormal">              We discussed possibly also signing the metadata<o:p></o:p></p>
<p class="MsoNormal">              After the call, DW located the issue that resulted in requiring the 200 OK responses:<o:p></o:p></p>
<p class="MsoNormal">                     <a href="https://bitbucket.org/openid/connect/issues/627/">
https://bitbucket.org/openid/connect/issues/627/</a><o:p></o:p></p>
<p class="MsoNormal">                           It's by Tatsuya Hayashi (Lef) and over a decade old!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal">              The next call is at 7am Pacific Time on Thursday, October 6, 2022, followed by the SIOP Special Topic call<o:p></o:p></p>
</div>
</body>
</html>