<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;
font-weight:normal;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma",sans-serif;
mso-fareast-language:EN-US;}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Times New Roman",serif;
mso-fareast-language:DE;
font-weight:bold;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-US;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Segoe UI",sans-serif;
mso-fareast-language:EN-US;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.Titre3Car
{mso-style-name:"Titre 3 Car";
mso-style-priority:9;
mso-style-link:"Titre 3";
font-family:"Cambria",serif;
color:#4F81BD;
mso-fareast-language:EN-US;
font-weight:bold;}
p.Titre3, li.Titre3, div.Titre3
{mso-style-name:"Titre 3";
mso-style-link:"Titre 3 Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.TextebrutCar
{mso-style-name:"Texte brut Car";
mso-style-priority:99;
mso-style-link:"Texte brut";
font-family:Consolas;
mso-fareast-language:EN-US;}
p.Textebrut, li.Textebrut, div.Textebrut
{mso-style-name:"Texte brut";
mso-style-link:"Texte brut Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.TextedebullesCar
{mso-style-name:"Texte de bulles Car";
mso-style-priority:99;
mso-style-link:"Texte de bulles";
font-family:"Tahoma",sans-serif;
mso-fareast-language:EN-US;}
p.Textedebulles, li.Textedebulles, div.Textedebulles
{mso-style-name:"Texte de bulles";
mso-style-link:"Texte de bulles Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.EmailStyle32
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle33
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle34
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle35
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle36
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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-AU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> only applicaple to RPs who did not register a sector_identifier_uri and NEVER intend to do so.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">We should assume that an RP that hasn’t registered a sector_id just hasn’t had enough experience yet (with app versions, company reorgs, re-branding, i18n etc) to know that they will need it eventually.
We should expect the RP to need a sector_id at some point in the future. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Registering one later would break the sub of all customers which is certainly bad
</span><span lang="EN-US" style="font-family:Wingdings;color:#1F497D">J<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">But it doesn’t have to break all subs if only the host part of the jwks_uri or notification_uri is used. That host can subsequently server a sector_identifier_uri.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> That thought led to demanding a sector_identifier_uri to be mandatory for all CIBA SPs.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">Still worthwhile to make RPs consider the importance of a stable long-term domain for their sector_id.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> What the contents of the document at the siu is is still unclear to me.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Registration describes siu in
<a href="https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation">
https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</a> as
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">“</span><span lang="EN-US">The value of the
</span><tt><span lang="EN-US" style="font-size:10.0pt">sector_identifier_uri</span></tt><span lang="EN-US"> MUST be a URL using the
</span><tt><span lang="EN-US" style="font-size:10.0pt">https</span></tt><span lang="EN-US"> scheme that references a JSON file containing an array of
</span><tt><span lang="EN-US" style="font-size:10.0pt">redirect_uri</span></tt><span lang="EN-US"> values. The values registered in
</span><tt><span lang="EN-US" style="font-size:10.0pt">redirect_uris</span></tt><span lang="EN-US"> MUST be included in the elements of the array, or registration MUST fail. This MUST be validated at registration time; there is no requirement for the OP to
retain the contents of this JSON file or to retrieve or revalidate its contents in the future.<span style="color:#1F497D">”<o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">So we extend that from “an array of redirect_uri values” to “an array of redirect_uri, jwks_uri, and notification_uri values”.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">It is backwards compatible (an old systems just ignores jwks_uri and notification_uri values as if they were redirect_uri values for some other related apps).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Where do you see new rules regarding siu in CIBA?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">“</span><span style="color:#1F497D">It must be in-scope because CIBA is adding new rules that jwks_uri and/or notification_uri needs to be listed in the content at sector_identifier_uri.</span><span lang="EN-US" style="color:#1F497D">”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">CIBA currently does not say anything about the file which means that an RP using both CIBA and front-channel would have redirect_uri values in it.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I read CIBA in such a way that an RP who does not use front-channel would have an empty array as the contents of the siu document.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">There are currently no rules about notification_uri which needs to be registered for the Client separately.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> I am not sure whether CIBA needs the siu document contents to be changed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<pre><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D">> Let’s say we have two RPs: With <o:p></o:p></span></pre>
<pre><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D">iss “</span><span lang="EN-US"><a href="https://client.example.org/">https://client.example.org/</a></span><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D">” and iss </span><span lang="EN-US"><a href="https://client.other_company.example.net/">https://client.other_company.example.net/</a></span><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></pre>
<pre><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D">and <o:p></o:p></span></pre>
<pre><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:#1F497D">the siu is <a href="https://other.example.net/file_of_redirect_uris.json">https://<span style="font-family:"Courier New"">other.example.net/file_of_redirect_uris.json</span></a></span><span lang="EN-US">”<o:p></o:p></span></pre>
<pre><span lang="EN-US">and there is a new back-channel-only RP with the same siu with iss and notification_uri<o:p></o:p></span></pre>
<pre><span lang="EN-US">iss “<a href="https://petrol-pumps.exmaple.net/">https://petrol-pumps.exmaple.net/</a>” and notification_uri “<a href="https://petrol-pumps.exmaple.net/cb">https://petrol-pumps.exmaple.net/cb</a>”<o:p></o:p></span></pre>
<pre><span lang="EN-US"><o:p> </o:p></span></pre>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Would you change the siu json to include the notification_uri<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">Yes<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> or is it enough to register the notification_uri for the client separately?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">No<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> How would the validation of the to-be registered notification_uri look like?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">Just like redirect_uri validation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">“The value registered in notification_uri MUST be included in the items of the array at the sector_identifier_uri, or registration MUST fail.”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Registration does not put much constraint on validation
<a href="https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation">
https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Should CIBA be more strict and why?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">CIBA (and Registration) should be stricter.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">Having an app’s URI in the array at the sector_identifier_uri gives the app the authority to receive the ‘sub’s of the sector_id (domain). Instead of allowing every URI in a domain to convey that
authority, it is much safer if only 1 specific address in that domain (eg </span>
<span style="color:#C00000"><a href="https://%3csector_id%3e/.well-known/openid/apps.json"><span style="color:#C00000">https://<sector_id>/.well-known/openid/apps.json</span></a>) can convey that authority.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">> Axel<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">--<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#C00000">James Manger<o:p></o:p></span></p>
</div>
</body>
</html>