[Openid-specs-mobile-profile] Mobile Profile WG Call on May 31 2017 preliminary minutes

philippe.clement at orange.com philippe.clement at orange.com
Wed May 31 15:54:24 UTC 2017


Dear all,

Please find below the preliminary minutes on our MODRNA call on May 31 2017.
In case of any mistake or misunderstanding, please let me know.

Participants :

 Bjorn, Charles, Dave Tonge, Hubert, Philippe, Nicolas, John, Nat

Agenda :
*       Feedback on Workshop meeting minutes [all]
*       Polling vs Notification [Axel]
*       FAPI WG feedback on MODRNA Specifications [Bjorn/John]
*       Issue Tracker [All]
o       #52<https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text>
o       #53<https://bitbucket.org/openid/mobile/issues/53/ciba-terminology-consumption-device>
o       #54<https://bitbucket.org/openid/mobile/issues/54/ciba-client-notification-endpoint>
o       #55<https://bitbucket.org/openid/mobile/issues/55/ciba-signed-result-objects>
*       Discussion :
*       Feedback on Workshop meeting minutes [all]

   Some remarks/suggestions have been received, new minutes have been circulated to MODRNA list.
==>     Philippe to circulate to all Amsterdam meeting attendees.
*       Polling vs Notification [Axel]

   CPAS seems to have eliminated the polling mode. Orange mentions that using both of polling and notification makes sense, Poland people use them. Despite the fact polling is more difficult than push mode, more work has to be done on the specs and exchanges on this keep moving on on the list.
*       FAPI WG feedback on MODRNA Specifications [Bjorn/John]

   For Open Banking authentication, 3 different ways are addressed: Redirect, decoupled and embedded, and 2 factor authentications occur.
   First conclusion from FAPI is that CIBA spec could be used easily between Payment Processor (RP) and Bank (OP).The binding message could be used in payment cases at the condition that the user enters some information in a device.
   Regarding UQ, the spec seems not wide enough. However, We can imagine the use case where the Bank is the OP towards the Point of Payment (RP) and in this case no MNO interaction, and the bank can take the role of RP regarding questioning the user through the MNO network (OP) in a UQ use case.
   Nat mentions that in London, risk indicators will be exchanged in the back channel.
   global call flows are requested from FAPI, to understand the role of banks in different situations (OP, RP, ...) and the potential role of MNO.
   The bank will have its (out of band) authentication mean of the user.
   Questions regarding:
-        the notification mode: what happens if the client endpoint is down ? retries will have to occur. Some things could be optional in the general version of CIBA, and mandatory in the OB/FAPI world.
-       Binding message: comes from the main MODRNA spec. need more work for back channel. Nat: some ATMs show a QR code that is used to bind from different kinds of terminals

   These feedback is important and useful to make CIBA a more general document, an issue regarding FAPI feedback will be created in MODRNA WG on issue tracker.
==>     John will integrate FAPI members into the list for access to the issue tracker.
*       Issue Tracker [All]

   Not addressed, we will review the issue list on the next call

Best regards,
Philippe


_________________________________________________________________________________________________________________________

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/20170531/30e7d1e6/attachment.html>


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