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

charles.marais at orange.com charles.marais at orange.com
Thu Dec 1 14:19:34 UTC 2016


In my understanding, UQ has been designed for this kind of Use Cases, 
please refer to §1.5, the first Use Case is the following :

"/The Client can be a bank and the User Questioning API can be used to 
challenge the End-User when he wants to pay on Internet in order to 
secure the transaction. This is similar to 3D-Secure. The question could 
be: "Do you allow a payment of x euros to party y? (Yes) (No)". /"

Is this what you had in mind ?

Don't forget that in UQ, the user is authenticated just before answering 
the question on the authentication device (in the same process).

In your Use Case, I think that we have to keep in mind that the user's 
answer is important for the SP : the SP wants a confirmation of 
something form the user and it is important that the legitimate user 
(authenticated) can answer negatively to the question/confirmation 
requested by the SP.

Furthermore, and beyond the 'context issue', in the case you mention, 
the RP is in charge to take a decision (validate or not the payment) 
depending of the user's answer. We agreed, in Paris, that when a RP is 
in charge to enforce a policy (take a decision), UQ is relevant. On the 
other hand, when the OP is in charge to enforce a policy, CIBA is 
relevant (in a server to server mode).



Le 01/12/2016 à 14:03, GONZALO FERNANDEZ RODRIGUEZ a écrit :
> 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 
>> *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
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


*MARAIS Charles *
*Orange Labs Lannion*
Tel : +33 (0)2 96 07 24 18
charles.marais at orange.com <mailto:charles.marais at orange.com>
Orange Labs Lannion
2, avenue Pierre Marzin
22307 LANNION Cedex - France


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161201/999fbae0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161201/999fbae0/attachment-0001.gif>

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