<html 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:"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:Verdana;
panose-1:2 11 6 4 3 5 4 4 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;}
.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;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hello All, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Happy New year. After long time I am coming back to the game -</span><span style="font-family:"Apple Color Emoji";mso-fareast-language:EN-US">😊</span><span style="mso-fareast-language:EN-US">.
Just replying with more queris on Riyo Ito’s email. My reply is marked @Siva <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">#####START##<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">%%</span>Ryo Ito%%******START*******<br>
The current specification does not define how much the OP will do the validation when the Client specifies the binding\_message.
<br>
The requirements will change depending on the use case, such as user-verified or system-verified.
<br>
I also think that user selection of Binding Message, which is used by MicroSoft and Google, is worth including in the CIBA specification.<br>
<br>
I propose a few parameters to make binding message validation mandatory.<br>
<br>
* **binding\_message\_verification\_required**<br>
<br>
* OPTIONAL. Specify true if the Client requires the OP to validate the binding\_message. If it is not, it is up to the OP to validate the binding\_message or not.<br>
<br>
* **candidate\_binding\_messages**<br>
<br>
* OPTIONAL. A list of ?binding\_message? to be used for User Selection. This list must contain the value specified in ?binding\_message?. ?binding\_message\_verification\_required? is true and the OP must perform User Selection if this value is specified.<br>
<br>
%%Ryo Ito%%*******END********</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">@Siva : #######START########<o:p></o:p></p>
<p class="MsoNormal">I believe, the text mentioned in the specification clearly says it must be as an example LIKE from specs …. “value of reasonable entropy (e.g. a transactional approval code….@@”.
<o:p></o:p></p>
<p class="MsoNormal">If my transaction is log in, some entropy I might be using “786786” on both consumption and authentication devices to bind them together. As per Ryo’s email binding_message can be created by the client (RP) or SERVER(AS) with additional
verification. With the existing parameters achieve use case level granularity might be confusing, although possible.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. If the server creates binding_message, there will not be any ambiguity for that transaction, the server can choose anything to display, and it is responsible for communicating, the server can display the verified binding
message ( entropy) on both the devices. ( No Problem)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. if a client provides a list of bindig_messages to display on the authentication device and use supposed to select, this is also possible. As per Ryo’s email, “USER SELECTED MESSAGE”, I assume the flow will be during registration
user must have already selected required personalized binding message(s) for that transaction. So, in the client's request, it sends a possible list of client messages to the server. The server will select “configured” personalized binding message from the
list. If it doesn’t have it, then will display its own. ( fall back mechanism on failure) ,
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">\ I am not assuming the user will get a list of the message during runtime ( wasting time) through the existing profile parameters.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So the parameters will be OR binding_message altogether will be removed only two Ryo's mentioned parameters will be there in the profile.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Binding_message = “DEFAULT” <o:p></o:p></p>
<p class="MsoNormal">**binding\_message_verification_required ** TRUE/FALSE - if true, then take the binding message mentioned in the binding_message list otherwise manage its own.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">* **candidate_binding_messages** -- “ARRAY OF REGISTERED BINDING MESSAGES”.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If the verification required is true, the server will match the configured user binding message on the system and display it. Again it also depends on authentication device space limitation.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">@Siva:@@@However I feel this isn't very easy and workaround, instead we can have a clean implementation like the following::
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Binding_message = “provide something with limited length” ( ex. Short entropy) always provided by the client.
<o:p></o:p></p>
<p class="MsoNormal">2. Client_transaction_messages = “xxxxxxxx” ( a list of transaction display messages”) - based on the use case, not the binding message, but a separate transaction messages.
<o:p></o:p></p>
<p class="MsoNormal">3. Client_verification_required: true/false; if true, along with client provided transaction message, binding_message will be displayed... False, it is up to the server to decide.
<o:p></o:p></p>
<p class="MsoNormal">The ultimate display will be binding_message+client_transaciton_message on authentication device, on consumption device will be binding_message+ “verify your mobile to access the system”.
<o:p></o:p></p>
<p class="MsoNormal">• <o:p></o:p></p>
<p class="MsoNormal">`in this way, end-user/ client/server will have full control over prior registration content, and the user will have control of what to display. Visually every end-user can inspect, what the user has registered. If verification required
is true, binding_message must be used to display on both the devices, client_transaction _messages will be displayed on the authentication device. FEATURE Phones usage for online transactions is minimal in the current generation, so space is not a problem,
I believe. </p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">@Siva#######END##############<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">---------------------------------------------------------<o:p></o:p></p>
<p class="MsoNormal">From my identity platform design<o:p></o:p></p>
<p class="MsoNormal">I am designing an identity system with the following three parameters to cater to several business use cases, although OpenID connects core does not support all parameters by default.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Binding_message – bind both consumptions on authentication devices, (always provided by the client). ( RP). Ultimately the client is the provider of the service to the end-user. Server/Client must be responsible for maintaining
transaction reference for future; The displayed messages will be echoed back to the client with server signature as a proof of what exactly revealed to the user, for future audit and regulatory purposes.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Client_messages = client selected message. It is a customized list for the user/ per transaction. ( can also be configured at the user-portal).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3. Client_verification_required = true/false, by default it is true, i.e. always server verifies, false, then it uses its own binding messages, it could be a <registered client name> + < some entropy> etc. and transaction bsaed
messages. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">These will apply to both client-initiated front/backchannel flows. ( currently, binding_message exist only on backchannel profile.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best Regards, <o:p></o:p></p>
<p class="MsoNormal">Siva <o:p></o:p></p>
<p class="MsoNormal">Bruhaspathi Ltd. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><br>
<br>
<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" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Shiva <shiva@e2e4tech.com><br>
<b>Date: </b>Saturday, 2 January 2021 at 20:15<br>
<b>To: </b>Siva <siva@bruhaspathi.co.uk><br>
<b>Subject: </b>FW: Openid-specs-mobile-profile Digest, Vol 269, Issue 1<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Forwarding openid specs bitbucket mailing list.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces@lists.openid.net><br>
<b>Date: </b>Monday, 28 December 2020 at 12:00<br>
<b>To: </b>openid-specs-mobile-profile@lists.openid.net <openid-specs-mobile-profile@lists.openid.net><br>
<b>Subject: </b>Openid-specs-mobile-profile Digest, Vol 269, Issue 1</span></p>
</div>
<div>
<p class="MsoNormal">Send Openid-specs-mobile-profile mailing list submissions to<br>
openid-specs-mobile-profile@lists.openid.net<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
or, via email, send a message with subject or body 'help' to<br>
openid-specs-mobile-profile-request@lists.openid.net<br>
<br>
You can reach the person managing the list at<br>
openid-specs-mobile-profile-owner@lists.openid.net<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openid-specs-mobile-profile digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Issue #197: Clearer Binding Message Verification<br>
(openid/mobile) (ritou)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 28 Dec 2020 03:26:21 +0000 (UTC)<br>
From: "ritou" <issues-reply@bitbucket.org><br>
To: openid-specs-mobile-profile@lists.openid.net<br>
Subject: [Openid-specs-mobile-profile] Issue #197: Clearer Binding<br>
Message Verification (openid/mobile)<br>
Message-ID:<br>
<20201228032621.6825.63491@celery-worker-315.ash2.bb-inf.net><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
New issue 197: Clearer Binding Message Verification<br>
<a href="https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification">https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification</a><br>
<br>
Ryo Ito:<br>
<br>
The current specification does not define how much the OP will do the validation when the Client specifies the binding\_message.
<br>
The requirements will change depending on the use case, such as user-verified or system-verified.
<br>
I also think that user selection of Binding Message, which is used by MicroSoft and Google, is worth including in the CIBA specification.<br>
<br>
I propose a few parameters to make binding message validation mandatory.<br>
<br>
* **binding\_message\_verification\_required**<br>
<br>
* OPTIONAL. Specify true if the Client requires the OP to validate the binding\_message. If it is not, it is up to the OP to validate the binding\_message or not.<br>
<br>
* **candidate\_binding\_messages**<br>
<br>
* OPTIONAL. A list of ?binding\_message? to be used for User Selection. This list must contain the value specified in ?binding\_message?. ?binding\_message\_verification\_required? is true and the OP must perform User Selection if this value is specified.<br>
<br>
<br>
Details : [<a href="https://ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665%5d(https:/ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665">https://ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665](https://ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665</a>)<br>
<br>
?<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
Openid-specs-mobile-profile@lists.openid.net<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-mobile-profile Digest, Vol 269, Issue 1<br>
***********************************************************</p>
</div>
</div>
</body>
</html>