[Openid-specs-mobile-profile] evidence of consent

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Tue Jan 17 15:21:05 UTC 2017


Hi,

The question was raised outside of MODRNA whether the user consent must always be collected by the OP associated with the resource server.
The consent could be collected by a trusted service provider.

It is evident that the resource server must be able to validate the access token and that it should not care how it was created.
The RS does not care about how the consent was collected.

We have several options how to achieve this.

1a)  The TSP operates its own OP and collects the user consent and creates an access token
2a)          The resource, operated by the MNO, receives this access token, validates it and returns a response containing the results of whatever the resource server does (e.g. KYC)
2b) The TSP presents the access token to the MNO OP and trades it in for a new access token valid at the resource endpoint.
                The TSP presents the new access token at the resource and gets a response.
1b)
I)             The TSP requests an access token from the MNO OP using CIBA (clientid and clientsecret) and adds the "evidence of consent" parameter to that request so that the OP refrains from contacting the user.

The TSP generated access token should be a JWT utilizing https://tools.ietf.org/html/rfc7523
"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants"

Did I capture the discussion and alternatives or did I miss something?
This email is intended to move the discussion to MODRNA.

Cheers
Axel


o    The significance of eoc for TSPs providing an evidence for the consent capture was discussed

o    The eoc is an optional protocol element

o    The eoc is a signed JWT - signed by the TSP and format is to be discussed

o    The claims structure of the eoc is suggested to include scopes as well, for which consent has been captured by the TSP
It was noted that whilst an SP may be Trusted and eoc may be provided, it is ultimately an MNO business decision as to whether to accept that consent or to override this and capture user consent itself independently or use a business process to exchange the evidence of consent



From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of nicolas.aillery at orange.com
Sent: Thursday, December 01, 2016 10:17 AM
To: Lodderstedt, Torsten
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] [UQ API] SMS OTP requirement

Torsten,

    I see 2 advantages in supporting mechnanisms like SMS OTP in the UQ API:

-          Offering a unique API to Client

-          Addressing any user (even those with a very basic phone)

Regards,

Nicolas

De : Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de> [mailto:Torsten.Lodderstedt at telekom.de]
Envoyé : jeudi 1 décembre 2016 09:43
À : AILLERY Nicolas IMT/OLPS
Cc : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; MARAIS Charles IMT/OLPS; VASSELET Mickaël IMT/OLN; CLEMENT Philippe IMT TECHNO
Objet : RE: [UQ API] SMS OTP requirement


Hi Nicolas,

why do you want to reimplement SMS-OTP as it works today? The only difference to SMS-URL is the fact the user needs to transfer the code from the authentication device to the consumption device. Is this seen as security advantage? I see it as a UX burden.

best regards,

Torsten.

-------- Originale Nachricht --------

Betreff: RE: [UQ API] SMS OTP requirement

Von: nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>

An: 1. Dez. 2016, 09:24

CC: "Lodderstedt, Torsten" <Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>>
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> [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<mailto: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.

_________________________________________________________________________________________________________________________



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/20170117/77bb65e8/attachment-0001.html>


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