Binding Message Verification and candidate list parameter in OIDC CIBA

CIBA is a standardized specification that is being developed to realize Decoupled Authentication. This document is a proposal for validating a Binding Message by user selection or input.

CIBA’s Overview

An end user is trying to log into a web application (Client) using an account for another service (OP).

1. [Consumption Device] The end user enters an identifier on the Client and clicks “Sign-In with (OP)”. At that time, the Client will request the OP to authenticate the user in the back channel.
2. [Authentication Device] The OP sends a notification to the end-user’s mobile device, asking for permission to authenticate from the Client.
3. When the end-user gives permission, the OP sends the result of the authentication event to the Client (achieved by polling from the Client or pushing from the OP).

CIBA’s flow

CIBA’s Sequence

Binding Message

CIBA has a parameter named “binding_message”.

A human readable identifier or message intended to be displayed on both the consumption device and the authentication device to interlock them together for the transaction by way of a visual cue for the end-user. This interlocking message enables the end-user to ensure that the action taken on the authentication device is related to the request initiated by the consumption device.

This parameter is sent from the client to the OP, and the end user checks that the values displayed in both environments match.

However, this UI does not allow the OP to strictly verify that the end user is checking for a match. In order to validate this, the OP needs to request the following actions of the end user.

• User input : Have the end user enter the Binding Message displayed on the Consumption Device, and the OP will validate the value.()
• User selection : From the list presented by the OP, the end user is asked to select the one that matches the Binding Message displayed on the Consumption Device, and the OP verifies the value.

For User Input, the current specification (binding_message parameter) allows for this validation, but it is up to the OP to decide whether to do so.

For User selection, although it is not CIBA, such an action has been adopted in the already existing Decoupled Authentication flow.

• Sign in using the Microsoft Authenticator app — Azure AD | Microsoft Docs
• Sign in with your phone instead of a password — Android — Google Account Help

In the current specification, the Client generates the values of binding_message according to its own display capabilities.
In order to implement such a User Selection, it would be necessary for the Client to generate a list of binding_message values and pass them to the OP.

Proposal

The above mentioned validation could be added to the specification by adding the following parameters.

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

w/ User Selection

I have sent this issue and article to the community.
https://bitbucket.org/openid/mobile/issues/197/clearer-binding-message-verification