[Openid-specs-mobile-profile] Openid-specs-mobile-profile Digest, Vol 269, Issue 1

Siva siva at bruhaspathi.co.uk
Sat Jan 2 22:42:27 UTC 2021


Hello All,
Happy New year.  After long time I am coming back to the game -😊.  Just replying with more queris on Riyo Ito’s email.  My reply is marked @Siva
#####START##

%%Ryo Ito%%******START*******
The current specification does not define how much the OP will do the validation when the Client specifies the binding\_message.
The requirements will change depending on the use case, such as user-verified or system-verified.
I also think that user selection of Binding Message, which is used by MicroSoft and Google, is worth including in the CIBA specification.

I propose a few parameters to make binding message validation mandatory.

* **binding\_message\_verification\_required**

    * 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.

* **candidate\_binding\_messages**

    * 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.

%%Ryo Ito%%*******END********

@Siva : #######START########
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….@@”.
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.

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)

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)  ,

\ I am not assuming the user will get a list of the message during runtime ( wasting time) through the existing profile parameters.

So the parameters will be  OR binding_message altogether will be removed only two Ryo's mentioned parameters will be there in the profile.

Binding_message = “DEFAULT”
**binding\_message_verification_required ** TRUE/FALSE  - if true, then take the binding message mentioned in the binding_message list otherwise manage its own.

* **candidate_binding_messages** -- “ARRAY OF REGISTERED BINDING MESSAGES”.


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.

@Siva:@@@However I feel this isn't very easy and workaround, instead we can have a clean implementation like the following::

1.            Binding_message = “provide something with limited length” ( ex. Short entropy) always provided by the client.
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.
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.
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”.
•
`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.

@Siva#######END##############


---------------------------------------------------------
From my identity platform design
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.

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.

2.            Client_messages = client selected message. It is a customized list for the user/ per transaction. ( can also be configured at the user-portal).

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.

These will apply to both client-initiated front/backchannel flows.  ( currently, binding_message exist only on backchannel profile.


Best Regards,
Siva
Bruhaspathi Ltd.






From: Shiva <shiva at e2e4tech.com>
Date: Saturday, 2 January 2021 at 20:15
To: Siva <siva at bruhaspathi.co.uk>
Subject: FW: Openid-specs-mobile-profile Digest, Vol 269, Issue 1
Forwarding openid specs bitbucket mailing list.

From: Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces at lists.openid.net>
Date: Monday, 28 December 2020 at 12:00
To: openid-specs-mobile-profile at lists.openid.net <openid-specs-mobile-profile at lists.openid.net>
Subject: Openid-specs-mobile-profile Digest, Vol 269, Issue 1
Send Openid-specs-mobile-profile mailing list submissions to
        openid-specs-mobile-profile at lists.openid.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
or, via email, send a message with subject or body 'help' to
        openid-specs-mobile-profile-request at lists.openid.net

You can reach the person managing the list at
        openid-specs-mobile-profile-owner at lists.openid.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openid-specs-mobile-profile digest..."


Today's Topics:

   1. Issue #197: Clearer Binding Message Verification
      (openid/mobile) (ritou)


----------------------------------------------------------------------

Message: 1
Date: Mon, 28 Dec 2020 03:26:21 +0000 (UTC)
From: "ritou" <issues-reply at bitbucket.org>
To: openid-specs-mobile-profile at lists.openid.net
Subject: [Openid-specs-mobile-profile] Issue #197: Clearer Binding
        Message Verification (openid/mobile)
Message-ID:
        <20201228032621.6825.63491 at celery-worker-315.ash2.bb-inf.net>
Content-Type: text/plain; charset="utf-8"

New issue 197: Clearer Binding Message Verification
https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification

Ryo Ito:

The current specification does not define how much the OP will do the validation when the Client specifies the binding\_message.
The requirements will change depending on the use case, such as user-verified or system-verified.
I also think that user selection of Binding Message, which is used by MicroSoft and Google, is worth including in the CIBA specification.

I propose a few parameters to make binding message validation mandatory.

* **binding\_message\_verification\_required**

    * 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.

* **candidate\_binding\_messages**

    * 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.


Details : [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%5d(https:/ritou.medium.com/binding-message-verification-and-candidate-list-parameter-in-oidc-ciba-90ffcefa6665>)

?




------------------------------

Subject: Digest Footer

_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


------------------------------

End of Openid-specs-mobile-profile Digest, Vol 269, Issue 1
***********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20210102/5f9f1e29/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list