[Openid-specs-mobile-profile] Interlock Solutions
ve7jtb at ve7jtb.com
Wed Mar 25 12:19:04 UTC 2015
Connect has a way to send an encrypted/signed request.
Using the request object we would just need to define an additional claim to carry the information.
I don’t think that we need to have anything else special, there is all-ready a way in connect to establish encryption keys.
Not all clients will have a symmetric key is the other point. I think we are still debating making the client authentication asymmetric to reduce key management overhead in the clients and servers.
In any event I think we are better of sticking to the defined method of encrypting requests.
We would do the same sort of extension to allow a client to pass in text to be digitally signed. I know that is an extesion some peole will also want in cases where the MNO can proxy a qualified digital signature.
> On Mar 12, 2015, at 6:47 AM, GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com> wrote:
> Hi Guys,
> As I promised yesterday, find below the concern raised in our call yesterday. As you know Torsten has opened a ticket here: http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence <http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence>.
> @Torsten, the idea is discuss it using the tool or by email?, anyway as I don't have access as a writer, by the moment I use the email :-)
> 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.
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4326 bytes
Desc: not available
More information about the Openid-specs-mobile-profile