[Openid-specs-mobile-profile] minutes of MODRNA WG Call on Nov 30th 2016

Thu Dec 1 18:20:36 UTC 2016

???
Context is NOT in the current version of the CIBA spec:
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication-01.xml?at=default

Sorry I couldn't attend the call due to another meeting.
Cheers
Axel

Were you looking at the html file in bitbucket? That is manually updated and I would like to remove it because the link above always works

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of philippe.clement at orange.com
Sent: Thursday, December 01, 2016 5:09 PM
To: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net
Subject: [Openid-specs-mobile-profile] minutes of MODRNA WG Call on Nov 30th 2016

Dear all,
Please find below the preliminary minutes of our call. In case of error or misunderstanding due to the huge density of discussions, please let me know

Participants :
Torsten, Charles, Nicolas, Philippe, Petteri, Joerg, Gonzalo, John, Siva, Bjorn, Celestin

Agenda :
1.     UQ update
SIBA update

Discussion

1.     Siba update
context parameter still present in the specs, last call had recommended to remove it.
Torsten states that we haven't had any discussion about the context parameter, and we already have the binding message. Specs seem not complete enough to describe the needs. Use Cases are lacking to explain what is supposed to be done with SIBA.
Siva explains that for Customer care, CRM people can ask a person physically present at a desk or by phone, to answer directly the content of a message sent to the mobile of the people. CRM justifies the binding, even if no consumption device, replaced by a direct communication OOB.
Discussions occur regarding binding message and long message, and needed justifications to differentiate them.
Difficulties to understand if we are speaking of message length limitations or something else, and if some existing implementations in Mobile Connect would impact the discussions led in OIF MODRNA.
Gonzalo mentions that the SP has to know what the message displayed on the user device is. He also mentions that the binding message must have the same definition/usage in MODRNA profile and in Mobile Connect specs.
Torsten and John mention the legitimate role of the OP to display on the authentication device during the authentication phase.

Gonzalo proposes to update the SIBA specs at the end of the next week, before the next call.
Torsten ask the question whether someone objects to incorporate MODRNA specs into mobile connect specs, no one objects.
Discussion on the consistency between front and back channel, regarding the usage of parameters.
Decision: let's talk of the Use Cases first to filter what depends upon the RP and the OP. John and Joerg volunteer to work on it.

2.     UQ status
Put on bitbucket version n°8.
2 evolutions are discussed during the call:
1.     static polling URL (registration) : static polling endpoint will be retrieved in discovery. To be added in draft v9 (due on dec 2nd)
2.     new request for flow terminated by client: There is currently no need to add this in the UQ API. If any contributor has a specific need, he can express it on the mailing list

Discussed: security considerations and mecanisms used by UQ, and threats. This topic to be added in each section.
Nicolas will provide a stable draft of UQ before end of this week

Kind 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/20161201/00cd230c/attachment-0001.html>