[Openid-specs-mobile-profile] [Bitbucket] Issue #197: Clearer Binding Message Verification (openid/mobile)

Fri Jan 22 18:00:24 UTC 2021

Dear all,
Some opinions are posted on Brian’s inputs on 197 issue.   Bitbucket is already updated.  Seding to wider audience to participate in the discussion.  This is also applicable to CIBA core profile once WG decides to go ahead.
-------Here is my reply in bitbucket------------------------  and below brian’s comment on bitbucket---------
Note: bitbucket by default will not send any reply to all working group members, hence sending to the e-mail list, If you have already received it's my mistake to resend it again. Apologies I am a rookie with bitbucket -😊.

Hi,
the Microsoft example usage is a little bit different compared to the binding_message and client_messages that are proposed to incorporate in the profile. ]
In Microsoft Example: Two different messages are being displayed in the consumption device and authentication device. To convert this example directly to the binding message might have difficulties. However, to retain existing implementations and binding_message concept intact, I would propose the following::

  1.  client_name: MANDATORY, a registered client name by the client with the server.
  2.  binding_message: MANDATORY, as defined in the profile, is a short entropy to display on both consumption and authentication devices.
  3.  client_messages(s): an OPTIONAL message given by the client ( RP ) to display it on the authentication device.
  4.  client_message_verifiication_required : OPTIONAL true/false : if true then _client_messag_e is mandatory. if false, client_message is a non-mandatory item.
Existing implementations: no need to change anything.
Any new implementations: they are free to use or not to use client_message(s) and client_message_verified parameter which are any way OPTIONAL. AS suggested by Ryo Ito, there is no harm to introduce OPTIONAL parameters that can go into MODRNA, CORE CIBA profiles.
PS: If WG had decided to bar any future changes, on NOT a finalized specs is not a good idea or recommendation. Members are now requesting some extensions that should be respected and considered on not finalized specifications from a global standards working group point of view.
In My humble opinion, if Microsoft and Google are implementing this functionality in a certain way, why OIDF is barring it from implementing it in a generalized way ?? is there any specific reason ?? do we have security issue ?? or technical issue ??
With the above optional extensions how existing implementations will become VOID ?? or complicated ??
PS: The Protocol specifications should be general, and business use cases will decide how to use the protocol with extensions. Please see CIBA is being used in Finance and Mobile operators world. So, the proposed extensions apply to multiple domains. Instead of a specific use-case, wherever applicable WG should allow broader and domain-independent extensions that are OPTIONAL that do not impact any existing implementations. From a standards body like OIDF these are good practices to follow does not discourage the majority of the OIDF members.
I think these are good extension OPTIONAL proposals and will be useful to many use cases in different domains.
Thank you in advance for considering this concept.
‌
Best Regards,
Siva Boyalakuntla
BRUHASPATHI LTD.

From: Brian Campbell <issues-reply at bitbucket.org>
Date: Friday, 22 January 2021 at 17:18
To: Siva Boyalakuntla <siva at bruhaspathi.co.uk>
Subject: Re: [Bitbucket] Issue #197: Clearer Binding Message Verification (openid/mobile)
[Brian Campbell]
Brian Campbell commented on issue #197:
Clearer Binding Message Verification<https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification>

Some thoughts:

Although CIBA is still a draft there are implementations, deployments, profiles, conformance tests, etc. of it now. Because of this, the WG had previously agreed that the bar for making changes would be high.

Anyway, CIBA is a tricky one. It attempts to define an abstract interface between the consumption device / client and the AS/OP without imposing too many assumptions on the capabilities and nature of the authentication or consumption device themselves. I believe the proposal here places too much knowledge and expectation about the authentication device onto the client.

This kind of select from list behavior at the authentication device could potentially be accommodated without changes to CIBA by sending a binding_message and having the AS side include that value in the list of choices. It’s not ideal but similar to the proposal in terms of leaky abstraction and fragility. And without a change to spec.

If we were to make a change to CIBA to better support this kind of authentication device interaction, I’d like to consider a somewhat different approach of introducing a new parameter to the Authentication Request Acknowledgement<https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html#rfc.section.7.3> that could convey some info about how to complete the authentication process to the user. Call it user_authn_instructions for lack of a better name at the moment. Using the Microsoft example, a response to an authentication request might look like this:

‌

    HTTP/1.1 200 OK

    Content-Type: application/json

    Cache-Control: no-store

    {

      "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",

      "expires_in": 3600,

      "interval": 2,

      "user_authn_instructions" : "Tap the number you see below in your Microsoft Authenticator app to sign in. 84"

    }

Which would allow the client / consumption device to show something like:

‌

[https://bitbucket.org/repo/8Xd9d5E/images/495955824-microsoft-auth-app-sign-in.png]‌

while the authentication device prompts with:

[https://bitbucket.org/repo/8Xd9d5E/images/2006995070-microsoft-auth-app-sign-in-numbers.png]‌

‌

‌

‌
View this issue<https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification> or add a comment by replying to this email.
Unwatch this issue<https://bitbucket.org/api/internal/repositories/openid/mobile/issue/197/unwatch/siva-boyalakuntla/a677a7d85042f93566eb955abbeab8c535d351382a2bb6b35bac6351aad233cc/> to stop receiving email updates.
[Bitbucket]<https://bitbucket.org/>
Are you making the most of Bitbucket? Learn more about our premium plans.<https://bitbucket.org/account/admin/plans?utm_source=bbctrns&utm_medium=email&utm_campaign=fv2&utm_content=t1>
Blog<https://bitbucket.org/blog?utm_source=bbctrns&utm_medium=email&utm_campaign=fv1&utm_content=t1>  |  Git Tutorials<https://www.atlassian.com/git/tutorials?utm_source=bbctrns&utm_medium=email&utm_campaign=fv1&utm_content=t1>  |  Bitbucket Community<https://community.atlassian.com/t5/Bitbucket/ct-p/bitbucket?utm_source=bbctrns&utm_medium=email&utm_campaign=fv1&utm_content=t1>  |  Privacy Policy<https://www.atlassian.com/legal/privacy-policy?utm_source=bbctrns&utm_medium=email&utm_campaign=fv1&utm_content=t1>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20210122/000db561/attachment-0001.html>