Context - Service provider wants to influence message on the device

[Torsten Lodderstedt]

• Use case: bank uses Mobile Connect to access secure 2nd factor, bank wants to show to the user a message related to the actual transaction on the device
• Sounds like a useful extension to openid connect (or even OAuth in general)
• Key question: how to sanitize such a message in order to prevent injection attacks?

Proposed by Gonzalo

[Gonzalo Fernández]

First of all, I want to highlight that this problem mainly affects to the use cases where Mobile Connect is used as a second factor of authentication, what is probably closer to an authorization than an authentication.

Some banks are really concerned about the interlock between the authentication device, that is the mobile where the user receive the challenge to ask him for the credentials (e.g: PIN Code in SIM applet authenticator) and the consumption device, that is the provider's web site (in this case the bank website) where the user is doing some transactions.

We already have in Mobile Connect a solution to solve this interlock and be able to correlate the authentication and the consumption device, this solution is based on generate a One Time Code in the ID_GW (OpenID Connect Server) and show it in both devices. However the banks would like an step further and be able to have influence in the text that is showed to the users to ask for the authentication, in that way the can provide any data they want that is related just with the current transaction that user is asking for (e.g: four last digit of the destination account in a money transfer).

My proposal is to add a query parameter in the authentication request to allow the Service Provider to provide the final message to the user, of course the OIDC Server wouldn't check any information (like amounts in a transfer or whatever). The Service Provider would have the responsibility to generate the proper message and the OIDC Server should truncate the message in case of having a length over a maximum length defined. Regarding the security this message must be encrypted because it could have sensitive information and my proposal would be to use the client_secret if it is possible and encrypt an sign using AES.

The summary of the solutions for the interlock would be the next, from my point of view 1 should be applied in case 2 is not present.

Two solutions to solve the interlock problem

1. INTERNAL TRANSACTION_ID GENERATION Generate a number in the AuthServer that identifies the transaction. Show this number in both devices: authentication and consuption. Pros: SPs don't need to do additional developments. Cons: Not possible to add any semantic value that refers to a value of the transaction in the Service Provider web site (like an amoutn, etc)

2. ADDING QUERY PARAMETER Additional query parameter to allow the SP to customize the message. Pros: allow to the SP to set any message containing any value it wants, improving security and probably the UX. Cons: in order to allow a secure solution, this query parameter should be encrypted and sign.

[John Bradley]

The existing Connect request object can pass the parameter and be optionally encrypted if required.

The request object probably should be signed as well. That helps prevent this from turning into a spam channel.

[Gonzalo Fernández]

We also need to consider what happen in case of the authenticator has a limitation in the length of the message it can show the user (e.g: SMS maximum size)? - Return an Error - Show the default message - Truncate the message?

There may also be the possibility to set he maximum size of the text to display in each authenticator and retrieve it in the discovery.

[Torsten Lodderstedt]

Removing component: Core (automated comment)

[John Bradley]

test

[Torsten Lodderstedt]

assigned to Jörg as editor

[Matthieu Verdier]

The here under proposed wording of the "context" query parameters tries to describe two usage of the parameter : to make a "end user" readable pairing of the authorization request and the authentication request, and to enable to dynamically link authorization data to authentication data.

query parameter

context

OPTIONAL. string : Out Of Band Authorization Context Details. When the OpenID Connect request is going through a public User Agent the “context” query parameter should be protected from tampering and eavesdropping by third parties and be a JWT signed and encrypted by the RP. If the OP cannot display correctly the information on the authentication device he should return an error.

Helps mitigate a variety of phishing and pharming attacks and may enable to dynamically link authorization data to authentication data, in particular in the context of out of bound mobile authentication device. The string may contain an authorization request reference, a human readable 8 digit reference along with other authorization details may be displayed by the out of band authentication device to ensure Subscriber dynamic information and authorization request with authentication request interlocking. Details (acquirer name, amount) of sensitive actions to be authorized by the Subscriber may also be sent by the RP to the Subscriber’s out of band authentication device (i. the mobile) and displayed along with a confirmation code request or one-time password. The confirmation code may be cryptographically derived from the Subscriber’s token secret and the authorizations details. In order to complete the authorization, the Subscriber shall send the correct one-time password or confirmation code to the Verifier or RP.

[Matthieu Verdier]

It would be useful to describe an OPTIONAL data structure to ease the use of the parameter :

context

    reference : OPTIONAL human readable 8 digit string
    requester : OPTIONAL Relying party name
    string : OPTIONAL description
    tan : OPTIONAL Temporary access code
    amount : OPTIONAL numerical
    currency : OPTIONAL currency code

[Torsten Lodderstedt]

Results of the discussion in the WG call: * request object is used to protect context data from being modified/eavesdropped * use cases are: (1) give a context for a authentication transaction and (2) authorize a certain transaction * need to discuss whether we use the same parameter to enable both use cases or different parameters

[Torsten Lodderstedt]

discussion in the call: focus on context and authentication first. Thoughts must be put into the expectation regarding behavior of the OP if the user refuses the authentication. Basically, if the user refuses the authentication process, the OP also does not establish a session/terminates the existing session. What happens if this is s setp up authentication? What happens if the RP would accept different ARCs?

[Gonzalo Fernández]

I don't see the need to create any structure to provide the authorization context information. if Mobile Connect is not going to validate this information (I hope), should be better to allow the Service Providers to provide the information as they want in a simple string parameter (within the Request Object) in the authentication request and then the OIDC server progress this information in a transparent way to the properly authenticator (SMS, SIM Applet, USSD, etc.).

Within Mobile Connect initiative there are several use cases related with the "Authorization Product" that are under discussion, there are use cases related with payments like "Authorisation of bank transfer to new payee", "Enabling parental control of in-app purchases" or "Boss approving expense of employee" for example, but there also others use cases non payment related like: "Consent for doctor to move a health record", "Confirming change of account password", etc. As you can see the variety of information in such uses cases could be quite big, from my point of view there isn't a large profit structuring the information if Mobile Connect doesn't validate such information.

[John Bradley]

In Connect there is a scope for logging in called "opened" the default prompt should be attached to that scope. If the user declines to login e.g. no openID grant then the client gets a authentication failed.

I think that is different from wanting to authorize a action e.g. transfer money after the user is logged in.

I think it would be useful to have another scope for transactions that would leave the user logged in but not grant the scope.

A prompt for consent to loggin is different from a prompt for a additional scope/consent.

Overloading the consent into the login will cause ambiguities in that RP will get a response that there is not authenticated but still need to maintain a session based on a local state. I think it is better for overall security to be able to differentiate declining a transaction from logging out.

[Gonzalo Fernández]

Hi John, I understand your point and I think that you are right, is important to differentiate the log in action and the authorization to access to an scope. Additionally I believe that the specific information tied to the authorization (in the service provider side), I mean the transaction information should be sent in a transparent way without needing any kind of structure.

[John Bradley]

It might be that a string is OK for basic authorization of a scope as well.
Structure if needed is going to be more useful for authorization.

I think the important thing is what goes back to the SP: 1) error access_denied 2) success with the scopes granted on top of opened, as long as the user hasn't actually logged out.

The other possibility is that for things that the client wants consent collected for we do something besides overloading scope. They are similar but not quite the same.

[Torsten Lodderstedt]

I propose to split this ticket into two different requirements: (1) provide context to authentication / collate transaction between consumption and authentication device (2) advanced authorization/user consent

Thoughts?

[Gonzalo Fernández]

I agree, if I understand well the (1) is to resolve the interlock problem and the (2) to resolve the authorisation of a transaction rigth? I think that is perfect to address the different use cases that the GSMA WG are dealing with.

[Torsten Lodderstedt]

That's correct.

[Jörg Connotte]

Did wie resolve this issue with 'binding_message'?

[Gonzalo Fernández]

Hi Jörg,

As far as I understand we decided to address this kind of scenarios using the User Questioning and use the binding_message only to resolve the interlock problem, because this second factor with the context about the transaction is seen as an authorization transaction in the SP side, so I think that is UQ the spec that fits best here.

Best, Gonza.

[Jörg Connotte]

Hi Gonza,

your right. So should we reassign this issue to the user questioning api? Or close it here and open as a new one?

cheers Jörg

[Gonzalo Fernández]

I reckon that maybe is better to reassing it, but I don’t mine, whatever floats your boat! :-)

[Nicolas Aillery]

User Questioning is a solution for this requirement.

The User Questioning API enables: - to authenticate the Client first (access_token is required), preventing injections - to display a personalized message to the end-user (the question)

In the "second factor authentication for Bank" use case, the question could be something like "Do you validate your authentication on Bank.com from this browser: Windows7/Firefox/IP@192.167.164.13? (I confirm)(I refuse)"

[Nicolas Aillery]

Closed, as discussed in last MODRNA call.