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

Nat Sakimura sakimura at gmail.com
Thu Mar 2 18:51:33 UTC 2017


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> 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> on behalf of "
> Axel.Nennker at telekom.de" <Axel.Nennker at telekom.de>
> Date: jueves, 2 de marzo de 2017, 12:54
> To: "charles.marais at orange.com" <charles.marais at orange.com>, John Bradley
> <ve7jtb at ve7jtb.com>, "Joerg.Connotte at telekom.de" <
> Joerg.Connotte at telekom.de>, "openid-specs-mobile-profile at lists.openid.net"
> <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
> <charles.marais at orange.com>]
> *Sent:* Wednesday, March 01, 2017 3:19 PM
> *To:* Nennker, Axel; ve7jtb at ve7jtb.com; Connotte, Jörg;
> 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 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
>
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
>
> --
>
>
> *MARAIS Charles *
> *Orange Labs Lannion*
> Tel : +33 (0)2 96 07 24 18 <+33%202%2096%2007%2024%2018>
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170302/d193d337/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170302/d193d337/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170302/d193d337/attachment-0003.gif>


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