<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Connect has a way to send an encrypted/signed request. <div class=""><br class=""></div><div class="">Using the request object we would just need to define an additional claim to carry the information.</div><div class=""><br class=""></div><div class="">I don’t think that we need to have anything else special, there is all-ready a way in connect to establish encryption keys.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">In any event I think we are better of sticking to the defined method of encrypting requests.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 12, 2015, at 6:47 AM, GONZALO FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" class="">gonzalo.fernandezrodriguez@telefonica.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; " class="">
<div style="font-size: 14px;" class="">Hi Guys,</div>
<div style="font-size: 14px;" class=""><br class="">
</div>
<div style="font-size: 14px;" class="">As I promised yesterday, find below the concern raised in our call yesterday. As you know Torsten has opened a ticket here: <span class="Apple-style-span" style="font-size: 15px; "><a href="http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence" style="color: blue; text-decoration: underline; " class="">http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence</a>. </span></div>
<div style="font-size: 14px;" class=""><span class="Apple-style-span" style="font-size: 15px; "><br class="">
</span></div>
<div style="font-size: 14px;" class=""><span class="Apple-style-span" style="font-size: 15px; ">@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 :-)</span></div>
<div style="font-size: 14px;" class=""><span class="Apple-style-span" style="font-size: 15px; "><br class="">
</span></div>
<div style="font-size: 14px;" class=""><span class="Apple-style-span" style="font-size: 15px; "><br class="">
</span></div>
<div style="font-size: 14px;" class=""><br class="">
</div>
<div style="font-size: 14px;" class="">
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Two solutions to solve the interlock problem</div>
<div class=""><br class="">
</div>
<div class="">1. INTERNAL TRANSACTION_ID GENERATION</div>
<ul class="">
<li class="">Generate a number in the AuthServer that identifies the transaction. Show this number in both devices: authentication and consuption.</li><li class="">Pros: SPs don't need to do additional developments.</li><li class="">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)</li></ul>
<div class=""><br class="">
</div>
<div class="">2. ADDING QUERY PARAMETER</div>
<ul class="">
<li class="">Additional query parameter to allow the SP to customize the message.</li><li class="">Pros: allow to the SP to set any message containing any value it wants, improving security and probably the UX.</li><li class="">Cons: in order to allow a secure solution, this query parameter should be encrypted and sign.</li></ul>
</div>
<div style="font-size: 14px;" class="">Best,</div>
<div style="font-size: 14px;" class="">Gonza.</div>
<br class="">
<hr class="">
<font face="Arial" color="Gray" size="1" class=""><br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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<br class="">
</font>
</div>
_______________________________________________<br class="">Openid-specs-mobile-profile mailing list<br class=""><a href="mailto:Openid-specs-mobile-profile@lists.openid.net" class="">Openid-specs-mobile-profile@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br class=""></div></blockquote></div><br class=""></div></body></html>