[Openid-specs-mobile-profile] MODRNA WG Issue #197

Wed Feb 3 02:45:59 UTC 2021

Hi,
Apologies for not attending today’s call, I was stuck in other calls today. Got free time now :
%%Brian%%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.
@Siva: Yes, agree with Brian. It is also possible—
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.
for Internationalization agrees with Brian’s comments.
%%Joseph%% 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.
@Siva: There are two concepts when consumption device exists, and the second one consumption device does not exist.
Consumption device: 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.
Authentication device: 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.
Now, my query is 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.
Regarding space: 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 ).
some publicly available information: https://1ot.mobi/resources/blog/iot-hacking-series-6-what-is-a-sim-applet-and-why-is-it-important-for-iot-m2m
This feature will give more flexibility to RP ( clients) to personalize the user experience.
Pardon me, and I am not good with web page character display concepts. Following is an imaginary scenario :
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”……. depending on the capabilities of consumption and authentication devices……” 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.
‌
Consumption device does not exist: 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 ..”……depending on the capabilities of the consumption and authentication devices
%%Joseph%% The new user_authn_instructions should probably be mutually exclusive with binding_message, as it doesn’t seem to make sense to use both of them.
@Siva: 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 :
consumption device: <binding_message>+” Look your mobile for instructions.”
authentication device : <binding_message> + <client_message(s)> ( always ) , so THEY ARE NOT MUTUALLY EXCLUSIVE parameters.
%%Dave Tonge%% Siva client_name is not to do with CIBA, and it can already be provided as part of dynamic registration
@Siva: 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.
%%Dave Tonge%% I agree with Brian, I’m not keen to change the protocol to support a single binding message implementation.
@Siva: 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.
So, coming back to my iews :

  1.  binding_message: MANDATORY, as defined in the profile, is a short entropy to display on both consumption and authentication devices.
  2.  client_messages(s): an OPTIONAL message given by the client ( RP ) to display it on the authentication device.
  3.  client_message_verifiication_required : OPTIONAL true/false : if true then _client_message is mandatory. if false, client_message is a non-mandatory item.
‌
Thanks for reading long mail and for your patience.
‌
best regards,
/Siva

From: Hjelm, Bjorn <bjorn.hjelm at verizonwireless.com>
Date: Tuesday, 2 February 2021 at 17:05
To: Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
Cc: Dave Tonge <dave.tonge at moneyhub.com>, Brian Campbell <bcampbell at pingidentity.com>, Joseph Heenan <joseph.heenan at fintechlabs.io>, Siva Boyalakuntla <siva at bruhaspathi.co.uk>
Subject: MODRNA WG Issue #197

All,
This is a call to the WG to please review and comment on issue #197<https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification> (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.

BR,
Bjorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20210203/96532ba6/attachment-0001.html>