<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=windows-1256">
<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;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Menlo;
panose-1:2 11 6 9 3 8 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1539975933;
mso-list-template-ids:-303775432;}
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="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal" style="background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Apologies for not attending today’s call, I was stuck in other calls today. Got free time now :<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">%%Brian%%</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">The approach
I mentioned would also allow for things like “select the picture of a dog” or “choose all the images with a stoplight” or “tap on the triangle” or “enter the answer to 4+3” etc.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">@Siva:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> Yes, agree with
Brian. It is also possible—<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">some other thoughts. As per Ryo’s post, I can see that the business case requirement gives flexibility to client provided
messages through client_message(s) and verified flags. Btw, the proposal will also work with the browser-based protocol and CIBA based protocols. The concept applies to both scenarios.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">for Internationalization agrees with Brian’s comments.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">%%Joseph%%</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> Some consumption
devices might not be capable of displaying the message or some types of messages. In some scenarios, there might not be a consumption device.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">@Siva:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> There are two concepts
when consumption device exists, and the second one consumption device does not exist.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Consumption device:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> what
are the capabilities of the consumption device to display simple text is. The main concern is who will display the message on consumption device? If consumption device exists, AS will display the consumption device page. So, the control will be with AS feven
for internationalization. Agree that all types of messages may not be possible to display, but that is applicable to all specifications written by OIDF, wherever consumption device is involved. Sending simple text through client_messages is not a problem to
display on consumption device.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Authentication device</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">:
again, the question who will display this message? Of course AS. Whether it is a mobile APP or feature phone text messages, OP ( AS ) can display client messages. Again this applies to all OIDF mobile specs. If we do not have a problem with other specifications
displaying the TEXT, it should not be a problem for Browser-based OR CIBA specifications.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Now, my query is</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> do we
need to display client_message ALWAYS on consumption device OR ALWAYS on authentication device ?? I assume the client_message(s) is a personalized text by RP for that user or use case displayed on the authentication device ALWAYS. But, it is not necessary
to display on consumption device. It can simply say on consumption device “<binding_messsage>+Look your mobile for the message”. etc. On Authentication device it will be “<binding_message> + client_message”, SO why to worry ??and that too optional. So I do
not see any problems regarding this.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Regarding space</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">: if consumption
device space is a concern, there will be more space on consumption than an authentication device. If language / or special types of messages are possible to display an authentication device, it can also be displayed on the consumption device. I believe mobile
operators SIM APPLET implementations will have less space on authentication devices ( minimum available space globally ).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">some publicly available information: <a href="https://1ot.mobi/resources/blog/iot-hacking-series-6-what-is-a-sim-applet-and-why-is-it-important-for-iot-m2m"><span style="color:#0052CC">https://1ot.mobi/resources/blog/iot-hacking-series-6-what-is-a-sim-applet-and-why-is-it-important-for-iot-m2m</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">This feature will give more flexibility to RP ( clients) to personalize the user experience.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Pardon me, and I am not good with web page character display concepts. Following is an imaginary scenario :<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">If I am using Japanese windows laptop and client (RP) is sending a Japanese character. Then there will not be any problem,
since locale will support these characters however if I am using Chinese windows laptop and receiving Japanese characters if the page that is being displayed on a consumption device might not support all characters—similarly English windows laptop and receiving
Chinese characters, until and unless multi-language support is enabled. ….”, . So in the specifications if we add the TEXT<b>”……. <i>depending on the capabilities of consumption and authentication devices……” </i></b>which will be future proof and RP/client
and OP/server can understand the limitations of the specifications. For mobile profile we can capture implementation guidelines.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">¯<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Consumption device does not exist:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> If
consumption device does not exist, there will not be any problem at all. if we include these parameters, then we need to say in the specs .<b>.”……depending on the capabilities of the consumption and authentication devices</b><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">%%Joseph%%</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> The new </span><span style="font-size:9.0pt;font-family:Menlo;color:#172B4D;border:none windowtext 1.0pt;padding:0cm;background:#F4F5F7">user_authn_instructions</span><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> should
probably be mutually exclusive with binding_message, as it doesn’t seem to make sense to use both of them.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">@Siva:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> No, this is not
true. The concept of binding message and client messages with the verified flag is different. Joseph has misunderstood it. please see below example :<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">consumption device: <binding_message>+” Look your mobile for instructions.”</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">authentication device : <binding_message> + <client_message(s)> ( always ) ,</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> so
T<b>HEY ARE NOT MUTUALLY EXCLUSIVE</b> parameters.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">%%Dave Tonge%%</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> Siva </span><span style="font-size:9.0pt;font-family:Menlo;color:#172B4D;border:none windowtext 1.0pt;padding:0cm;background:#F4F5F7">client_name</span><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> is
not to do with CIBA, and it can already be provided as part of dynamic registration<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">@Siva:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> Thank you. I am
still going through all specs, still studying. Then there will not be any problem since from metadata AS can take the client_name.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">%%Dave Tonge%%</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> I agree
with Brian, I’m not keen to change the protocol to support a single binding message implementation.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">@Siva:</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D"> I think no need
to change the protocol flows OR they are not mandatory parameters. I think PROTOCOL is not changed at all. If we include these OPTIONAL parameters in both browser-based and CIBA based, then there will not be any problem to the protocol flows or existing implementations.
Probably my guess is dynamic client registration for client messages metadata might change ?? not sure.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">So, coming back to my iews :<o:p></o:p></span></p>
<ol start="1" type="1">
<li class="MsoNormal" style="color:#172B4D;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;background:white">
<b><i><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif">binding_messag</span></i></b><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif">e: MANDATORY, as defined in the profile, is a short entropy to display on both consumption
and authentication devices.</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li><li class="MsoNormal" style="color:#172B4D;mso-list:l0 level1 lfo1;background:white">
<b><i><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif">client_messages(s)</span></i></b><b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif">: an OPTIONAL message given by the client ( RP ) to display it on the authentication
device.</span></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li><li class="MsoNormal" style="color:#172B4D;mso-list:l0 level1 lfo1;background:white">
<b><i><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif">client_message_verifiication_required</span></i></b><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif"> <b>: OPTIONAL true/false : if true then _client_message is mandatory.
if false, client_message is a non-mandatory item.</b><o:p></o:p></span></li></ol>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">¯<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">Thanks for reading long mail and for your patience.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">¯<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">best regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:9.0pt;background:white"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#172B4D">/Siva<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Hjelm, Bjorn <bjorn.hjelm@verizonwireless.com><br>
<b>Date: </b>Tuesday, 2 February 2021 at 17:05<br>
<b>To: </b>Openid-specs-mobile-profile <openid-specs-mobile-profile@lists.openid.net><br>
<b>Cc: </b>Dave Tonge <dave.tonge@moneyhub.com>, Brian Campbell <bcampbell@pingidentity.com>, Joseph Heenan <joseph.heenan@fintechlabs.io>, Siva Boyalakuntla <siva@bruhaspathi.co.uk><br>
<b>Subject: </b>MODRNA WG Issue #197<br>
<br>
<br>
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">All,<o:p></o:p></p>
<div>
<p class="MsoNormal">This is a call to the WG to please review and comment on issue #<a href="https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification">197</a> (CIBA Binding Message Verification). We discussed the issue on today's
call and would like additional feedback to help take an action on the issue.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">BR,<o:p></o:p></p>
<div>
<p class="MsoNormal">Bjorn<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>