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

GONZALO FERNANDEZ RODRIGUEZ gonzalo.fernandezrodriguez at telefonica.com
Thu Mar 2 16:25:04 UTC 2017


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

--
[cid:image001.gif at 01D2934C.C92553F0]

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


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