[Openid-specs-mobile-profile] OP generated binding_message

GONZALO FERNANDEZ RODRIGUEZ gonzalo.fernandezrodriguez at telefonica.com
Thu Dec 1 13:03:36 UTC 2016


I don’t think it is an abuse of the binding message, I think that it is more flexible from the point of view of the Service Provider and it is a dynamic way to change or personalise the message. I understand the binding_message as a way to allow the Service Providers to show information in the Authentication Device.

In fact when we were in Paris we talked about the clash between CIBA and UQ in some scenarios, for instance when you want to confirm a transaction using an authentication and you show the amount in the authentication device. Shall I implement UQ for this use case?

Best,
Gonza.

From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: miércoles, 30 de noviembre de 2016, 22:45
To: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>
Cc: "Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>" <Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>>, Axel Nennker <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: Re: [Openid-specs-mobile-profile] OP generated binding_message

What sort of information related to the transaction?

That sounds like an abuse of the binding message and more of what you are describing context or user questioning for.

I agree with axel that the OP is in the best position to know what the binding message should be, and should be the one to display it on the consumption device in the front channel redirect case.

All in All it seems simpler fro the OP to define and display the binding message and something about who is asking for the authentication  “Banko Santander” etc.

The more you let the RP control on the authentication device the more you are open to confused user attacks from bad RP.

I think separating the binding, context and RP are important.

John B.


On Nov 30, 2016, at 4:09 PM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:

But…

The objective of the binding_message is to interlock both devices in other scenarios different from a simple authentication. In fact, as far as I know the original request came from the banks that wanted show information related with transactions, etc…

From: "Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>"
Date: Wednesday 30 November 2016 at 17:43
To: Gonzalo Fernández, "Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>", "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>"
Subject: AW: [Openid-specs-mobile-profile] OP generated binding_message

In the context of an authentication process, the OP definitely knows what to display on the authentication device, e.g. information about the service the user is supposed to login to.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von GONZALO FERNANDEZ RODRIGUEZ
Gesendet: Mittwoch, 30. November 2016 15:27
An: Nennker, Axel; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: Re: [Openid-specs-mobile-profile] OP generated binding_message

Sorry Axel,

I don’t agree with this approach, the OP knows better “HOW” to show the information in the Authentication device because it knows de limits of the authenticator, however I reckon that is the RP who knows better “WHAT”  should be displayed. What I mean is that if the OP takes a decision to optimise what should be displayed it can truncate it and exclude what is important.

Best,
Gonza.

From: Openid-specs-mobile-profile on behalf of "Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>"
Date: Wednesday 30 November 2016 at 14:53
To: "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>"
Subject: [Openid-specs-mobile-profile] OP generated binding_message

I an email to GSMA I suggested to discuss whether it is worthwhile reversing the direction of binding_message.

The reasoning is:

I think that the OP knows better what the AD can display.

After receiving the CIBA request the OP determines the channel and AD capabilities (like USSD and SIM Toolkit) and sends the binding_message to the AD and the RP in the CIBA Authentication Request Response.

The same suggestion was raised by Arne during a GSMA CPAS call this morning.

// Axel

Here some use case describing this
-          Polish policeman (PP) wants to check driver’s license which the driver has not present
-          PP logs into government website (RP) and enters drivers mobile number
-          RP sends CIBA to OP which sends request to AD binding_message=”PP Szydło wants to check your driver’s license”
OP sends binding_message to RP which is shown to PP too.
-          User sees message “PP Szydło wants to check your driver’s license”, checks Name PP’s device and consents
-          OP notifies RP of consent
-          RP retrieves driver’s picture and validity data of licence from its DB
-          RP sends data to PP who compares the picture and now knows the validity of the driver’s license without giving away too much data


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

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


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