[Openid-specs-mobile-profile] CIBA context client_name

charles.marais at orange.com charles.marais at orange.com
Fri Mar 3 10:14:35 UTC 2017


Hi,

@Nat : In your last response, I'm not sure to well understand what you 
have in mind. You are talking about a "consent", is this, as I 
understand your sentence, related to the "scope" parameter ? With this 
hypothesis, when you say "If it can be shown on the mobile handset to 
collect the consent", I think that the collection of consent by the OP 
for the requested scopes is not detailed in OpenID Connect 
specifications, right ? Not sure to understand what does "content of the 
transaction" mean and how it may be manipulated by the OP.

Do you have in mind an authentication use case (ie a "login into" 
functionality) or something different ?

Br,

Charles.

Le 02/03/2017 à 19:51, Nat Sakimura a écrit :
> So, Financial Institutions has a use case to display the content of 
> the transaction to be committed in the mobile handset while the 
> transaction itself is done on a PC. The handset acts as the more 
> secure second channel. This is to cope with the Man-in-the-browser 
> attack that rewrites pretty much everything on the PC screen, i.e., a 
> consent collected on a PC is moot. Typically, the authorization 
> request is done through a signed request object. If it can be shown on 
> the mobile handset to collect the consent, it would be really great.
>
> Nat
>
> On Fri, Mar 3, 2017 at 1:25 AM GONZALO FERNANDEZ RODRIGUEZ 
> <gonzalo.fernandezrodriguez at telefonica.com 
> <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>
>     Hi guys,
>
>     My thoughts on this are that for an authentication there is no
>     other context than the client where you are being authenticated,
>     when you need supply a context with additional information is
>     because you need the user to authorize something, unless this is
>     the conclusion I have got in a nutshell.
>
>     As far as I remember the context parameter is something that was
>     asked to be introduced in CIBA to address some use cases where the
>     Service Provider wanted to use an Authentication Flow to do an
>     action different from "login into". That is what leads to not
>     introduce the context parameter in CIBA as these uses cases should
>     be considered Authorization use cases and thus would be needed to
>     be resolved using UQ.
>
>     Something similar to the current use cases where the SMS is used
>     to authorize a transaction in a bank where the bank sends an
>     opaque string in the SMS was under discussion because in spite the
>     fact that they are an authorization, is something that could be
>     perfectly undertaken using the binding message because you can
>     consider that this opaque string is somehow to interlock both
>     devices, however this is something impossible to do in case of the
>     OP is in charge to generate the binding_message as I think was the
>     decision of the majority in this WG.
>
>     Best,
>     Gonza.
>
>     From: Openid-specs-mobile-profile
>     <openid-specs-mobile-profile-bounces at lists.openid.net
>     <mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on
>     behalf of "Axel.Nennker at telekom.de
>     <mailto:Axel.Nennker at telekom.de>" <Axel.Nennker at telekom.de
>     <mailto:Axel.Nennker at telekom.de>>
>     Date: jueves, 2 de marzo de 2017, 12:54
>     To: "charles.marais at orange.com <mailto:charles.marais at orange.com>"
>     <charles.marais at orange.com <mailto:charles.marais at orange.com>>,
>     John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>,
>     "Joerg.Connotte at telekom.de <mailto:Joerg.Connotte at telekom.de>"
>     <Joerg.Connotte at telekom.de <mailto:Joerg.Connotte at telekom.de>>,
>     "openid-specs-mobile-profile at lists.openid.net
>     <mailto:openid-specs-mobile-profile at lists.openid.net>"
>     <openid-specs-mobile-profile at lists.openid.net
>     <mailto:openid-specs-mobile-profile at lists.openid.net>>
>
>     Subject: Re: [Openid-specs-mobile-profile] CIBA context client_name
>
>     Hi Charles,
>
>     The GSMA’s document “OpenID Connect Mobile Connect Profile 2.1”
>     specifies “context” parameter.
>
>     When I remember correctly we decided in MODRNA to not have that in
>     CIBA.
>
>     Now a DT Natco asked for this feature in backchannel requests.
>
>     I did not have a use case at hand. I guess the prerequisites are:
>     use back channel to get access token with SP provided text and a
>     variable client_name.
>
>     Probably some Mobile Connect use cases could be envisioned to have
>     an SP provided text during authentication and consent collection.
>
>     The WG felt that in CIBA the OP is ultimately responsible for
>     those “pages” and we should not step into this unchartered land now.
>
>     But I wanted to raise this again to see whether this is still the
>     opinion.
>
>     Cheers
>
>     Axel
>
>     acr_values
>
>     	
>
>     Mandatory
>
>     	
>
>     Mandatory
>
>     	
>
>     Authentication Context Class Reference. Space separated string
>     that specifies the Authentication Context Reference used during
>     authentication processing. The RP/Client can use LoA for a
>     particular use case. The values appear in order of preference. The
>     acr satisfied by the authentication is returned as the acr claim
>     value. ID GW MUST consider only the first value in the list, and
>     ignores remaining LoA values while processing the request.
>
>     The recommended values are the LoAs as specified in ISO/IEC 29115
>     Clause 6 – 1, 2, 3, 4 – representing the LoAs of LOW, MEDIUM, HIGH
>     and VERY HIGH.
>
>     The acr_values are an indication of what authentication method to
>     use by the ID GW. The usage of authentication methods depends on
>     the LoA value passed in the parameter acr_values. The ID GW
>     configures the authentication method selection logic based on the
>     acr_values.
>
>     ID GW/Authorization server MUST return the achieved level of
>     assurance in the acr parameter.
>
>     binding_message
>
>     	
>
>     Optional
>
>     	
>
>     Optional
>
>     [Mandatory if scope = “openid mc_authz”]
>
>     	
>
>     Client provided plain text, "reference or ID" to interlock
>     consumption device and authorization device for a better user
>     experience. The message will be displayed on consumption device
>     and mobile device. Empty values are allowed. (zero length)
>
>     client_name
>
>     	
>
>     Optional
>
>     	
>
>     Optional [Mandatory if scope = “openid mc_authz”]
>
>     	
>
>     A short name to identify RP/Client application and must be
>     displayed on authentication/ authorisation device.
>
>     context
>
>     	
>
>     Optional
>
>     	
>
>     Optional
>
>     [Mandatory if scope = “openid mc_authz”]
>
>     	
>
>     A Transaction/action based message displayed on authorization
>     device and must provide by RP/client. If scope = "openid mc_authz”.
>
>     response_mode
>
>     	
>
>     Optional
>
>     	
>
>     Optional
>
>     	
>
>     Informs the Authorization Server of the mechanism to be used for
>     returning parameters from the Authorization Endpoint
>
>     Can be used when there is no user agent /browser.
>
>     *From:*charles.marais at orange.com
>     <mailto:charles.marais at orange.com> [mailto:charles.marais at orange.com]
>     *Sent:* Wednesday, March 01, 2017 3:19 PM
>     *To:* Nennker, Axel; ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>;
>     Connotte, Jörg; openid-specs-mobile-profile at lists.openid.net
>     <mailto:openid-specs-mobile-profile at lists.openid.net>
>     *Cc:* AILLERY Nicolas IMT-OLPS; CLEMENT Philippe IMT TECHNO
>     *Subject:* Re: [Openid-specs-mobile-profile] CIBA context client_name
>
>     Hi Axel,
>
>     Could you share the detailed uses cases in which the "context"
>     parameter would be used ? Are they mentioned in the attached file
>     (GSMA's uses cases list) ? Do these uses cases have some adherence
>     with the GSMA authorization product ?
>
>     Could we have some examples of what the "context" would contain ?
>     Is it clearly different from a question or a validation ?
>
>     As a reminder, User Questioning should be the OIDF specification
>     to address the GSMA Authorization product.
>
>     I think that the relevance of the "context" parameter should only
>     be discussed, both in CPAS and in Modrna, depending of the uses
>     cases for which it would be relevant.
>
>     Br,
>
>     Charles.
>
>     Le 28/02/2017 à 22:31, Axel.Nennker at telekom.de
>     <mailto:Axel.Nennker at telekom.de> a écrit :
>
>         Hi,
>
>         some telcos would like to offer to service providers the
>         option to display text during authentication and consent
>         collection.
>
>         The OP does still control what is displayed.
>
>         Should we add what CPAS calls context and client_name or
>         should that be an extension by CPAS?
>
>         Cheers
>
>         Axel
>
>
>
>
>         _______________________________________________
>
>         Openid-specs-mobile-profile mailing list
>
>         Openid-specs-mobile-profile at lists.openid.net
>         <mailto:Openid-specs-mobile-profile at lists.openid.net>
>
>         http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>     -- 
>
>
>     *MARAIS Charles *
>     *Orange Labs Lannion*
>     Tel : +33 (0)2 96 07 24 18 <tel:+33%202%2096%2007%2024%2018>
>     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.
>
>     _______________________________________________
>     Openid-specs-mobile-profile mailing list
>     Openid-specs-mobile-profile at lists.openid.net
>     <mailto:Openid-specs-mobile-profile at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
> -- 
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>

-- 

*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/20170303/352a482c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orange_logo.gif
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170303/352a482c/attachment-0001.gif>


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