[Openid-specs-mobile-profile] [UQ API] SMS OTP requirement

nicolas.aillery at orange.com nicolas.aillery at orange.com
Thu Dec 1 08:22:52 UTC 2016


Hello Torsten,

   It will work for sure (it's implemented in Orange's prototype) but it's not a universal mechanim like SMS OTP.

   As UQ API is a server-to-server API, if we use SMS OTP, the User has to enter the OTP on the Client side. But, in order to sign the UserStatementToken, the OP must check the code. So, there is a need to convey the OTP from the Client to the OP.

   In the Pulled-by-Client flow, the OTP could be conveyed in a polling request. It would be a minor modification.
   In the Pushed-to-Client flow, there is no such simple way.
   Therefore, allowing the Client to add an OTP in the polling request (new query param), could be a way to easily handle the SMS OTP use case,

Regards,

Nicolas

De : Torsten.Lodderstedt at telekom.de [mailto:Torsten.Lodderstedt at telekom.de]
Envoyé : jeudi 1 décembre 2016 09:09
À : AILLERY Nicolas IMT/OLPS; openid-specs-mobile-profile at lists.openid.net
Objet : AW: [UQ API] SMS OTP requirement

Hi Nicolas,

one question: I think one could implement SMS-based authorization without the need to extend the protocol by sending a SMS containing a URL instead of a TAN code. The user either accepts by clicking on the link or the link opens a web page, where the question is presented to the user along with the different options to answer it.

What do you think?

Best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>
Gesendet: Mittwoch, 30. November 2016 18:15
An: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: [Openid-specs-mobile-profile] [UQ API] SMS OTP requirement

Hello everybody,

   In User Questioning API draft 3, we removed the Terminated-by-Client flow that handled user interactions like SMS OTP.
   In this flow, the User receives a code to enter on the Client GUI, the client then transmit the code to the OP and the OP check if the code is correct. Note that if the code is checked by the Client, the current draft handles it.

   Within Orange, the requirement for a SMS OTP (verified by the OP) has been mentioned again.

   Have other OIF contributors been challenged for such a requirement?

Regards,

Nicolas

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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/3cbba0a6/attachment.html>


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