<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
samp
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{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;}
/* List Definitions */
@list l0
{mso-list-id:730470698;
mso-list-type:hybrid;
mso-list-template-ids:-2042567816 856176552 67567619 67567621 67567617 67567619 67567621 67567617 67567619 67567621;}
@list l0:level1
{mso-level-start-at:6;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:53.4pt;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:89.4pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:125.4pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:161.4pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:197.4pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:233.4pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:269.4pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:305.4pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:341.4pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1147746351;
mso-list-type:hybrid;
mso-list-template-ids:-1394942914 67567633 67567641 67567643 67567631 67567641 67567643 67567631 67567641 67567643;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1593388932;
mso-list-type:hybrid;
mso-list-template-ids:1888768736 -190284928 67567619 67567621 67567617 67567619 67567621 67567617 67567619 67567621;}
@list l2:level1
{mso-level-start-at:3;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3
{mso-list-id:1800344778;
mso-list-type:hybrid;
mso-list-template-ids:-621610346 -299992322 67567641 67567643 67567631 67567641 67567643 67567631 67567641 67567643;}
@list l3:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:53.4pt;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:89.4pt;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:125.4pt;
text-indent:-9.0pt;}
@list l3:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:161.4pt;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:197.4pt;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:233.4pt;
text-indent:-9.0pt;}
@list l3:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:269.4pt;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:305.4pt;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:341.4pt;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I committed text that makes it clear that Polling or Notification Mode is determined at registration time.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#getting_transaction_result">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#getting_transaction_result</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><a href="https://bitbucket.org/openid/mobile/commits/fd4ff3056624b5a3c881d23001caa0669b83e414">https://bitbucket.org/openid/mobile/commits/fd4ff3056624b5a3c881d23001caa0669b83e414</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">And the corresponding error:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.2">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.3.3.2</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The notification_endpoint_uri MUST be validated at registration time. This validation is not different to the validation
of redirect_uris in front channel mode, right?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The problem you see seems to be with clients using polling mode.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">So let’s assume a polling client (GoodPollingClient)is back channel only that is it has an empty redirect_uris array registered.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">As a CIBA client it must have a sector_identifier_uri if the OP uses pairwise identifiers.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">No jwks_uri is registered for this client.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Now the client sends an CIBA Authentication Request to the OP’s CIBA Authentication Endpoint (which might or
might not be the same as a front channel Authentication Endpoint) and authenticates itself using one authentication method which is predefined at registration time – let’s say client_id and client_secret.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The OP validates the Authentication Request as per
<a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#auth_request_validation">
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#auth_request_validation</a>
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The OP acknowledges the Authentication Request and returns an auth_req_id.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">4)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The OP does authenticates the user at the authentication device.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">5)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Meanwhile the client is polling. The client is authenticated in each polling request and each polling request
contains the auth_req_id.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">6)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">After the user authenticated, the OP answers the polling requests and returns the tokens.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">What are the threats if all client metadata is validated at registration time and all CIBA requests are authenticated?<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l0 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">BadClient is not able to register for the same sector_identifier_uri as GoodPollingClient (regardless of CIBA
or OIDC) This is nothing bad introduced by CIBA.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l0 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">BadClient can register whatever jwks_uri for itself but it cannot change the jwks_uri for GoodPollingClient
nor change the value of that document.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l0 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">BadClient cannot impersonate GoodPollingClient because all CIBA requests are authenticated.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:53.4pt;text-indent:-18.0pt;mso-list:l0 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">???<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">The only CIBA specific metadata is the notification_endpoint_url and that must be validated like any other client metadata.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Why do you insist that jwks_uri is in sector_identifier_uri? Maybe there is no jwks_uri at all. Maybe the jwks_uri is
<a href="https://example.org/jwks_uri.json">https://example.org/jwks_uri.json</a> and the sector_identifier_uri is
<a href="https://example.com/">https://example.com/</a> . The Open<br>
The client metadata needs to be validated at registration time but this is nothing introduced by CIBA.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Yes, in CIBA there is no redirect_uri but the front channel distinction through redirect_uri is replaced in CIBA by the
client authentication. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">In OIDC the OP has no authenticated client at the authorization endpoint:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint">https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">while in CIBA the OP has an authenticated client at all endpoints.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">//Axel<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Sent:</b> Montag, 12. Juni 2017 20:50<br>
<b>To:</b> Nennker, Axel <Axel.Nennker@telekom.de><br>
<b>Cc:</b> James.H.Manger@team.telstra.com; openid-specs-mobile-profile@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The problem is that the jwks_uri is not unique to CIBA. People can and do register it for other sorts of signed requests or encrypted responses.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Remember this is to stop correlation, and that can happen between legitimate clients with legitimate credentials. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yes, this is inherently the purpose of all sector identifiers. Its whole purpose is to allow correlation for legitimate
parties.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The OP has to decide what is legitimate and whether correlation is allowed for those SPs who share the sector identifier.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So legitimate client A and legitimate client B can apply at the OP to be considered a group that is allowed to correlate
users.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If good.org and well.org have registered the sector_identifier_uri “https://welldone.net/” to let the OP generate the
same sub form them then this is OK for front channel and back channel. If later malware.com tries to register its client for the same SIU then the OP must validate that registration request and most likely reject it. This is not special to back channel. The
OP grants an exception to pairwise identifiers and all clients and their metadata must be validated at registration time.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">My concern is a client can register a jwks_uri and someone else's redirect URI and AIU during registration and then do CIBA polling if registration and response are decoupled.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Doesn’t this example contradict itself because nobody can register someone else’s redirect_uri?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">The issue is that SIU currently assumes the client gets the response via a redirect that must exactly match one of the ones registered.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">CIBA breaks that logic.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So we added the post back URI and a rule to check it as you cant do postback without a registered URI that exactly matches.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">You could register bogus redirect or postback URI and never use them in CIBA polling.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">No, CIBA specifies that if there is a notification_endpoint_url registered for the authenticated client then the OP uses
notification for that client. The client cannot switch between notification and polling on a per-request basis.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Please see the commit to the repository.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">Assuming that we don’t allow http basic or any form of symmetric key with CIBA polling.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The polling client can use any authentication method it has agreed upon with the OP.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">We have two options I can think of:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. Always have registration require that the JWKS URI is in the SIU. (This would be a breaking change to existing deployments.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Have the client also register that it wants to do CIBA polling and only check for those clients.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Both are CIBA specific changes to registration. The second CIBA would also need to mention to prevent people who haven't registered for polling from doing it if pairwise identifiers are used.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 12, 2017, at 4:26 AM, <a href="mailto:Axel.Nennker@telekom.de">
Axel.Nennker@telekom.de</a> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Inline – long – sorry.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">John
Bradley [<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">mailto:ve7jtb@ve7jtb.com</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Freitag, 9. Juni 2017 15:11<br>
<b>To:</b><span class="apple-converted-space"> </span>Nennker, Axel <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span><a href="mailto:James.H.Manger@team.telstra.com"><span style="color:purple">James.H.Manger@team.telstra.com</span></a>;<span class="apple-converted-space"> </span><a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">You could leave CIBA to say use the sector identifier URI.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">CIBA mandates that a sector_identifier_uri is registered at registration time and that the OP MUST validate that siu.</span><o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4</span></a></span><o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">“</span><span lang="EN-US">If the OpenId Provider uses Pairwise Identifiers then a<span class="apple-converted-space"> </span></span><samp><span lang="EN-US">sector_identifier_uri</span></samp><span class="apple-converted-space"><span lang="EN-US"> </span></span><span lang="EN-US">MUST
be specified for all Clients using CIBA.</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">”</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I am guessing that you agree CIBA should say that the post back URI MUST be registered to use post back.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">You are guessing correctly:</span><o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#client_notification_endpoint"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#client_notification_endpoint</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The question is where do we say that registration needs to error if the postback URI registered is not in the SIU.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Why? The notification_endpoint_uri might be<span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://neu.example.org/"><span lang="EN-US" style="color:purple">https://neu.example.org/</span></a><span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">and
the siu might be<span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://siu.example.com/"><span lang="EN-US" style="color:purple">https://siu.example.com/</span></a><span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">while
another client of the same group might register a notification_endpoint_uri<a href="https://foo.example.org/"><span style="color:purple">https://foo.example.org/</span></a><span class="apple-converted-space"> </span>and the same siu. The OP MUST check that
the person registering one client and then the other has the authority to use the same siu. Using James’ example: At registration time it MUST be impossible<a href="http://malware.org/"><span style="color:purple">malware.org</span></a><span class="apple-converted-space"> </span>to
register itself for the same siu as<span class="apple-converted-space"> </span><a href="http://good.com/"><span style="color:purple">good.com</span></a>. This is true for front-channel and back-channel. CIBA does not introduce a new threat. If a bad client
can register for an existing siu then then OIDC and CIBA have a problem.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The more complicated question is for polling you don't want to allow someone to register with a redirect URI in someone else's SIU.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Right. But there is no redirect_uri in polling. There is no redirect_uri in CIBA at all.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Normally all the flows use the redirect URI but in the CIBA case it is not used so it provides no che</span>ck. <o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Right but all CIBA requests are authenticated and that is the check and all metadata for the client is fixed. W</span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">While in front-channel the request to the authentication endpoint is not authenticated because here the user authenticates NOT the client.<span class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In CIBA the Client is authenticated at the authentications endpoint and at the token endpoint.</span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">All metadata for the authenticated client is registered at registration time.</span><o:p></o:p></p>
</div>
<div style="margin-left:54.0pt">
<p class="MsoNormal" style="text-indent:-18.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-</span><span lang="EN-US" style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If
notification is used then the OP uses the registered notification_endpoint_url.</span><o:p></o:p></p>
</div>
<div style="margin-left:36.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#issuing_successful_token"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#issuing_successful_token</span></a></span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If polling is used then the client is authenticated and the auth_req_id is the correlation to the authentication request.</span><o:p></o:p></p>
</div>
<div style="margin-left:18.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#token_request"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#token_request</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">We don’t want someone pretending to register for code but doing CIB</span>A to bypass SIU verification.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">SIU validation is done at registration time. It is not possible to bypass it by using CIBA. There is no siu parameter which could be used in CIBA
to do that.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Since post back requires registration the check can be done in registration.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">CIBA requires a siu if pairwise identifiers are used at this OP and that Sector Identifier Validation is at registration time.</span><o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4"><span style="color:purple">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">We probably need some other registration element required to use CIBA polling so that the registration can be rejected if the JWKS URI is not in the SIU, and stop clients from doing polling if they have not registered the new element.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> <span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The
OpenID.Registration spec leave all of this open. There is no relationship between the siu and the content of the redirect_uri array.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> OIDC and the registration spec require that the metadata is validated but does not talk about how this is done. This could all be
paper and lawyers.<span class="apple-converted-space"> </span></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">That is the only way we could isolate the SIU spoofing issue to Registration.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">A example would be to register a CIBA_response_type polling/postback. and do the appropriate check at registration.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">That way if you are using postback you don't need to worry about registering a JWKS_uri in your SIU.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">That is what CIBA is saying: if the Client wants notification then you must register a notification_endpoint_url. If the Client wants to sign something
then it must register a jwks_uri.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The client would need to register separate client_id for the different response methods, so that may be a downside unless you allow them to register multiple values.<o:p></o:p></p>
</div>
<div style="margin-left:35.4pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If the OP supports front-channel and back-channel for one client_id and the client has registered a redirect_uri and a notification and the OP uses
the same endpoint for front-channel and back-channel authentication requests then the OP can still distinguish between the two modes because if the authentication request has a redirect_uri parameter then the request is a front-channel request and has to follow
all requirements of OIDC or MODRNA authentication or if it does not have a redirect_url in the authentication request then it must be a CIBA request and follow all requirement of CIBA.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">We need something like that to keep the logic in registration.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">It seems like a lot of quite specific CIBA stuff to have in registration so some of it should at-least be referenced from CIBA.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> <span class="apple-converted-space"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">There
is nothing CIBA specific to siu validation at registration time. The OP must validate siu at registration regardless of front-channel or backchannel.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Jun 9, 2017, at 4:53 AM, <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>> <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>>
wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Using the example from<span class="apple-converted-space"> </span><a href="http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation"><span style="color:purple">http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The siu is<span class="apple-converted-space"> </span><a href="https://other.example.net/file_of_redirect_uris.json"><span style="color:purple">https://other.example.net/file_of_redirect_uris.json</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">And in the context of pairwise identifier algorithms the content of that file is irrelevant because what feeds into that algorithm for all clients
in that group is exactly “<a href="http://other.example.net/"><span style="color:purple">other.example.net</span></a>” and nothing else.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">That is</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> sector_identifier === “<a href="http://other.example.net/"><span style="color:purple">other.example.net</span></a>”</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">in<span class="apple-converted-space"> </span><a href="https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg"><span style="color:purple">https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg</span></a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">This value of sector_identifier does not change whether the Client uses Polling or Notification or needs a jwks or not.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think that these are separate topics.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">CIBA demands a sector_identifier_uri to enable pairwise subs and I still don’t see why this topic is related to whether the Client polls or uses
notification or signed somethings.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If the CIBA Client wants to be notified then it _<i>additionally</i>_ needs to specify a notification_endpoint_url at registration time.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If the CIBA Client wants to sign something then it _<i>additionally</i>_ needs to specify a jwks_url.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If CIBA would not have sector_identifier_uri being mandatory at registration time then CIBA would need to talk about _<i>default</i>_ values for
sector_identifier_uri.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">// Axel</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Manger,
James [<a href="mailto:James.H.Manger@team.telstra.com"><span style="color:purple">mailto:James.H.Manger@team.telstra.com</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Freitag, 9. Juni 2017 02:02<br>
<b>To:</b><span class="apple-converted-space"> </span>Nennker, Axel <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>>;<span class="apple-converted-space"> </span><a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">ve7jtb@ve7jtb.com</span></a>;<span class="apple-converted-space"> </span><a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">> My hope was that by making sector_identifier_uri mandatory we would get rid of all the special cases with jwks_uri and whatnot.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">> Isn’t that true?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">No.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">> So if someuses CIBA then there MUST be a siu at registration time and CIBA does not care how that is validated.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">> Making my life too easy?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Wishful thinking, Axel ;)</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">An OP needs proof that an app is<span class="apple-converted-space"> </span><i>entitled</i><span class="apple-converted-space"> </span>to use a sector_id
before revealing the subs associated with that sector_id.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">A new app merely quoting a sector_id in its registration is not proof. It shows the app wants that sector_id, but it doesn’t show that the other
apps using that sector_id want to share subs with this new app. It doesn’t prevent a malicious app quoting another group’s sector_id.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So the content at a sector_identifier_uri needs to identity each app that is entitled to use that sector_id (host part of siu). It does so by listing
a URI that each app needs to control to operate. For “normal” OIDC an app’s redirect_uri is sufficient; for CIBA with notifications an app’s client_notification_endpoint is sufficient; for CIBA with polling and asymmetric signatures an app’s jwks_uri is sufficient;
for other cases the tuple {iss, client_id} could work.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hence CIBA needs to add that, at registration, the OP needs to confirm that siu lists client_notification_endpoint (to enabling notifications) or
jwks_uri (to enabling polling with asym sigs).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">--</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">James Manger</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">John
Bradley [<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">mailto:ve7jtb@ve7jtb.com</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Donnerstag, 8. Juni 2017 18:56<br>
<b>To:</b><span class="apple-converted-space"> </span>Nennker, Axel <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span><a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Validation of the sector identifier is part of registration.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">The client registers its client_notification_endpoint as a new element. (Shouldn't that be an array vs a single URI if the request allows notification_uri to be specified? otherwise why send it in the request?)<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">The registration process needs to check those URI against the URI in the JSON file returned from the sector_identifier_uri.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">I dont think registration is going to get updated anytime soon so it probably needs to be explained in this spec for those IDP that allow notifiction_uri to be specified.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">All AS should always use the sector_identifier_uri as the key for generating ppid. Nothing in that changes.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">I think for the polling we need to specify the client JWKS endpoint in the sector_identifier_uri as well.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">It is just a URI so that should not be an issue. <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">If the registered jwks uri is not in the file then don’t allow polling. <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">I know this precludes the use of symmetric keys but I think that may be a reasonable trade off if someone wants to use this with polling.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">On Jun 8, 2017, at 3:38 AM, <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>> <<a href="mailto:Axel.Nennker@telekom.de"><span style="color:purple">Axel.Nennker@telekom.de</span></a>>
wrote:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Hi all,</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">can this issue be closed?</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><a href="https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text"><span style="color:#954F72">https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text</span></a></span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">The sector_identifier_url is now mandatory to be specified at Client registration time.</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Validation of the sector_identifier is out-of-scope for CIBA and should be in Discovery.</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Please comment on the issue in bitbucket or here.</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Kind regards</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Axel</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:8.0pt;font-family:"Arial",sans-serif">DEUTSCHE TELEKOM AG</span></b><span style="font-size:8.0pt;font-family:"Arial",sans-serif"><br>
T-Labs (Research & Innovation)<br>
Axel Nennker<br>
Winterfeldtstr. 21, 10781 Berlin<br>
+491702275312 (Tel.)</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial",sans-serif">E-Mail:<span class="apple-converted-space"> </span><a href="mailto:axel.nennker@telekom.de"><span style="color:#954F72">axel.nennker@telekom.de</span></a></span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
</span><a href="mailto:Openid-specs-mobile-profile@lists.openid.net"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">Openid-specs-mobile-profile@lists.openid.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</span></a><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>