<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;}
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;}
@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">SIOP Special Call Notes 10-Feb-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">Kristina Yasuda<o:p></o:p></p>
<p class="MsoNormal">Torsten Lodderstedt<o:p></o:p></p>
<p class="MsoNormal">Joseph Heenan<o:p></o:p></p>
<p class="MsoNormal">Petteri Stenius<o:p></o:p></p>
<p class="MsoNormal">Bjorn Hjelm<o:p></o:p></p>
<p class="MsoNormal">David Chadwick<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal">Kenichi Nakamura<o:p></o:p></p>
<p class="MsoNormal">Daniel Fett<o:p></o:p></p>
<p class="MsoNormal">Jo Vercammen<o:p></o:p></p>
<p class="MsoNormal">David Waite<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Approved Implementer's Drafts<o:p></o:p></p>
<p class="MsoNormal">              The two approved SIOP-related Implementer's Drafts are:<o:p></o:p></p>
<p class="MsoNormal">              <a href="https://openid.net/specs/openid-connect-self-issued-v2-1_0-ID1.html">
https://openid.net/specs/openid-connect-self-issued-v2-1_0-ID1.html</a><o:p></o:p></p>
<p class="MsoNormal">              <a href="https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-ID1.html">
https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-ID1.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Open 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 #120: Issuer Handling SIOP<o:p></o:p></p>
<p class="MsoNormal">                           This was also discussed on the preceding Connect call<o:p></o:p></p>
<p class="MsoNormal">                           Vittorio had asked on a previous call why use cases where "sub" and "iss" are different aren't interesting<o:p></o:p></p>
<p class="MsoNormal">                           Torsten is interest in having an attestation about the software producing the ID Token<o:p></o:p></p>
<p class="MsoNormal">                                         This would be different issue<o:p></o:p></p>
<p class="MsoNormal">                                         The IETF RATS and EAT working groups are doing attestation-related work<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that having "iss" == "sub" would enable an ID Token to be a Verifiable Presentation<o:p></o:p></p>
<p class="MsoNormal">                           George said that in the third-party case, the "iss" is used to validate the metadata and keys of the issuer<o:p></o:p></p>
<p class="MsoNormal">                           George said that we should have a non-normative note clarifying the motivations<o:p></o:p></p>
<p class="MsoNormal">                           Mike observed that if "iss" doesn't point to .well-known/openid-configuration, we lose the ability to retrieve metadata from the issuer<o:p></o:p></p>
<p class="MsoNormal">                                         Torsten said that in SIOP v1, we already couldn't do this<o:p></o:p></p>
<p class="MsoNormal">                                         Mike agreed to file a comment on issue #1400 about this<o:p></o:p></p>
<p class="MsoNormal">              PR #101: Fetching presentation definitions from a remote repository<o:p></o:p></p>
<p class="MsoNormal">                           Torsten filed a comment on the organization of the PR<o:p></o:p></p>
<p class="MsoNormal">                                         David agreed to reorder the text as suggested by Torsten<o:p></o:p></p>
<p class="MsoNormal">                           Torsten also filed a comment on the metadata values<o:p></o:p></p>
<p class="MsoNormal">                                         David disagreed with him<o:p></o:p></p>
<p class="MsoNormal">                           We agreed that request by value should be the default<o:p></o:p></p>
<p class="MsoNormal">                           People are requested to comment in the PR on the metadata syntax<o:p></o:p></p>
<p class="MsoNormal">              PR #124: [oidc4vci] clarify sub value in the ID Token Issue #1426<o:p></o:p></p>
<p class="MsoNormal">                           We discussed this with issue #1426, as recorded below<o:p></o:p></p>
<p class="MsoNormal">              PR #107: Support for federations using the termsOfUse property<o:p></o:p></p>
<p class="MsoNormal">                           David asked about using "anyof"<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that there are numerous issues with parsing and the specification of it<o:p></o:p></p>
<p class="MsoNormal">                           Kristina said that PE v2 is still being actively worked on<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that PE doesn't mention "anyof"<o:p></o:p></p>
<p class="MsoNormal">                           Torsten suggested simplifying the example to have a single value<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that PE doesn't support what David wants and that would have to be addressed in the PE spec<o:p></o:p></p>
<p class="MsoNormal">                           Kristina asked for David to provide an assessment of how stable PE v2 is<o:p></o:p></p>
<p class="MsoNormal">                                         David agreed that v1 is more stable<o:p></o:p></p>
<p class="MsoNormal">                                         He said that v2 will be vastly superior, as it defines an MTI core and optional features<o:p></o:p></p>
<p class="MsoNormal">                                         Torsten said that v2 format functionality is better and needed<o:p></o:p></p>
<p class="MsoNormal">                                         Torsten doesn't want to have to define an OpenID profile of PE v1<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Open 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">              #1426: Clarification of "sub" value<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that everything about "sub" in OpenID Connect Core still applies<o:p></o:p></p>
<p class="MsoNormal">                           George is worried about ephemeral identifiers<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that this the "sub" in the issuance draft - not the "sub" in the SIOP ID Token<o:p></o:p></p>
<p class="MsoNormal">                           Implementers want to know what to put in the "sub" value<o:p></o:p></p>
<p class="MsoNormal">                           Daniel said that whatever is in the "sub" should be about the End-User<o:p></o:p></p>
<p class="MsoNormal">                           Kristina suggested clarifying that everything about the Connect ID Token applies<o:p></o:p></p>
<p class="MsoNormal">                           She also said that there may be cases in which an ID Token isn't needed<o:p></o:p></p>
<p class="MsoNormal">                                         Daniel said that the ID Token is needed to contain the "nonce" in the reply<o:p></o:p></p>
<p class="MsoNormal">                           Torsten said that the alternative is to turn this into a pure OAuth flow<o:p></o:p></p>
<p class="MsoNormal">                           Kristina will update the PR<o:p></o:p></p>
<p class="MsoNormal">                           She will file a separate issue about whether to turn this into a pure OAuth flow<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">              #1429: Replace JWK Thumbprint URI with JWK URI<o:p></o:p></p>
<p class="MsoNormal">                           David prefers to send the entire key as a URI<o:p></o:p></p>
<p class="MsoNormal">                           He said that RPs that want a stable identifier could create one by applying the JWK Thumbprint rules<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that having the "sub" be a stable identifier of limited size is important<o:p></o:p></p>
<p class="MsoNormal">                           Mike said that having RPs compute the stable identifier from the "sub" would be an unnecessary departure from Connect Core semantics<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 Connect call will be on Monday, February 14, 2022 at 3pm Pacific Time<o:p></o:p></p>
</div>
</body>
</html>