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

Wed Nov 30 22:43:15 UTC 2016

Hi Axel,

My comments on the difference Use Cases you evoked:
===========
"1)      the call center agents trigger the CIBA request using the 
MSISDN they see on their telephone. Their Backend is then using 
client_id/client_secret to authenticate to the OP and CIBA delivers the 
id_token to the RP with further user claims."

=> OK, I understand your point which can be extended to "get an 
accessToken" to access User Resources. But some question should be 
raised in this context, if a consent is needed (which is generally not 
described in OpenID Connect specifications) to share user infos, the 
user would probably be sollicited on his mobile Hanset already used for 
the current communication with the call center...
===========
"2)      The Bank clerk might know some account number of their costumer 
which the bank backend translates into a iss/sub data (whatever) because 
there is an account number to iss/sub relationship that the bank has 
learned from another interaction of the customer with the Bank’s system. 
There might be an access token from that earlier interaction that the RP 
(Bank) uses to authentication the CIBA request."

=> I don't understand the last part of your example "There might be an 
access token from that earlier interaction that the RP (Bank) uses to 
authentication the CIBA request.", What do you mean by this ? In my 
understanding CIBA does not describe a resource server protected by an 
access token.
===========
"-          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"

=> In my understanding, binding_message is not designed for that king of 
purpose. binding_message has been described to provide a way to 
interlock (pair) two screens (or 2 channels) the authentiation device 
and the consumption device or channel (binding_message could be revealed 
by an RP operator on phone for example).

The use case you proposed is a typical Use case for which User 
Questioning has been written :
     - One RP wants to ask a question to a user ("PP Szydło wants to 
check your driver’s license <do you agree ?>") and to get the user's 
answer in order to take a decision ("RP retrieves driver’s picture and 
validity data of licence from its DB" and "RP sends data to PP").

In my understanding, CIBA is not intented to be used :
- to question the user
- to get the user's answer to a specific question
===========

BR,

Charles.

Le 30/11/2016 à 14:53, Axel.Nennker at telekom.de a écrit :
>
> 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
> 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/20161130/a7a1415a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orange_logo.gif
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161130/a7a1415a/attachment-0001.gif>