[CIBA] Include an optional "auth_req_hint" in the successful authentication request acknowledgement

[Vivek Shankar]

The enhancement here is proposed in: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.3

Given the means to perform user authentication is left to the authorization server, it is proposed that there be a means to inform the client of how that authentication is to be performed to provide appropriate instructions/feedback to the user.

‌

For example: A user chooses to print photos from a kiosk and has initiated payment through his bank.

1. Authorization server (that implements client-initiated backchannel authentication) chooses the method of authentication. Let’s assume this is a push notification to an app installed on the user’s smart phone, if the user has the authenticator registered. Otherwise, it uses a different means, say an SMS with a URL link to complete authentication through a mobile browser.
2. Proposal: Include auth_req_hint in the response to indicate that a push notification (or an SMS) has been sent along with a correlation ID that is included in the message. This can then be shown to the user to indicate what they should expect to do next.

‌

While this could be implemented as a proprietary extension to the specification, in order to ensure RPs are able to support this parameter, it should be included in the spec.

[Bjorn Hjelm]

Given that the CIBA Core specification is in Final Publication, making changes to the specification is challenging. Enhancements or modifications based on specific use cases, can be done in the profile of CIBA (such as FAPI CIBA Profile, MODRNA CIBA Profile, etc.).

[Vivek Shankar]

Could this be considered as an extension to the spec? I don’t believe that this is something specific to a particular industry. The CIBA spec does not mandate the authentication mechanism. The OpenID Connect provider makes this choice based on some configuration that is proprietary to it. There needs to be a way for the client to tell the user what to expect. In my example, say a push notification is sent to the authenticator app, the user would see a message -

‌

“A notification has been sent to your registered mobile authenticator. Please approve to authorize the transaction. Ref: #1231234”

‌

This would be distinct from the case where the user receives a URL via SMS.

“An SMS message has been sent to your registered phone. Please follow the instructions to authorize the transaction. Ref: #1231234”

‌

I chose payment as an example but this applies to any CIBA flow.

[Bjorn Hjelm]

Would this be something different from the “binding_message” (Section 7.1)?

[Vivek Shankar]

Yes. binding_message is sent to the authenticator app. It is usually generated by the authenticator client that the authorization server interfaces with. auth_req_hint is to show feedback on the kiosk or user agent that the user is interfacing with where they initiated the flow. binding_message and auth_req_hint could be complimentary but it may not be.

For example -

binding_message: Photobooth is asking to approve a transaction of $50.00. REF: #12341234 => This shows on your mobile phone authenticator app

auth_req_hint: A push notification has been sent to your MyFav authenticator app on your phone. Please tap “approve” to complete the transaction. REF: #12341234 => This shows on the user agent (Photobooth kiosk screen?) where the user initiated the CIBA flow. The information that a push notification was sent (as opposed to, say, a text message) is only known to the authorization server, given the choice of authentication mechanism is left to the authorization server.

‌

This is merely an example. auth_req_hint could also provide instructions to perform authentication through alternative means if, say, the user’s preferred authenticator is not available.