[Openid-specs-mobile-profile] FW: Question on proposals to pass user_id/user_id_type

Hjelm, Bjorn Bjorn.Hjelm at VerizonWireless.com
Wed Nov 27 16:08:55 UTC 2019


All,
Please see below additional clarifications from Orange on their request for feedback from the MODRNA WG.

BR,
Bjorn

From: MARAIS IMT/OLPS <charles.marais at orange.com>
Date: Wednesday, November 27, 2019 at 5:44 AM
To: "Openid-specs-mobile-profile net>" <openid-specs-mobile-profile-bounces at lists.openid.net>
Cc: "hubert.mariotte at orange.com" <hubert.mariotte at orange.com>
Subject: Re: TR: Question on proposals to pass user_id/user_id_type

Hi all,

As evoked during the MODRNA meeting this week, I add some details concerning the use case (or type of use cases).
First of all, we do know that the best way to call a resource server which deals with some resource owner's data (or rights, claims, properties...) is to use an access token linked to this user (authorization code flow, jwt assertion, CIBA...).
In some specific cases and some specific rationales (trusted partners, latency constraints, usage...) there is a need for such resources (with a link with a specific user) to be called using a generic access token ( client credentials for example).
 In these kind of scenarii, the service provider, when it calls the resource, will embed the (generic) access token and must also embed the concerned user identifier.
The goal of this email is to get your opinions, advices, recommendations, arguments... concerning the best way to transmit this user identifier on the resource call

-          in the body of the call (json ? x-www-form-urlencoded ?)

-          in the query string (json ? simple parameters ?)

-          in HTTP headers...
 The ambition is to find the most generic approach which could fit for every resource servers in such a situation.
 Thanks for your feedback,
Br,
Charles.




De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de hubert.mariotte at orange.com<mailto:hubert.mariotte at orange.com>
Envoyé : vendredi 22 novembre 2019 18:09
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Objet : [Openid-specs-mobile-profile] Question on proposals to pass user_id/user_id_type

Dear all

There are currently discussions regarding the use of a non-tied-to-a-user access token to access an API called ATP (Account Take over Protection) in the Mobile Connect context. That API was specified time ago as a GET request to be used just with tied-to-a-user access tokens and has already been implemented and deployed by some.
Today User Questioning allows the use of non-tied-to-a-user access tokens. In this case, the user_id and user_id_type are passed in the body request (embedded in a json) using a POST command. For ATP, in case of non-tied-to-a-user access token, the proposal is to pass the user_id (and also probably user_id_type) in a HTTP header respecting the command of the current API (GET in this case).
We would like to get your opinion on the two options from a general point of view (security, performances, complexity, usage, usability, …). Also, if you would consider both options acceptable, despite the differences and the drawbacks they might have :
·         user_id passed in a json in the body
·         user_id passed in a HTTP header
Our next call on this subject is during the week 49 and we would appreciate an answer before.

Rgds
Hubert


_________________________________________________________________________________________________________________________



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.

--
[cid:part1.85CF6F01.848B5233 at orange.com]

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/20191127/db9de560/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1265 bytes
Desc: image001.gif
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20191127/db9de560/attachment-0001.gif>


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