<div dir="ltr">FYI, I have an implementation that does more-or-less of the following: <div><br></div><div>(1) The app registers itself to the IdP, with self-generated key-pair's public key. </div><div>(2) The SP sends request_uri</div><div>(3) The app gets the request object from request_uri</div><div>(4) The app checks the signature, and displays it to the user: how much this transaction involves to whome etc. </div><div>(5) User taps accept button. </div><div>(6) The app counter signs the request object with the private key and sends the response back to the IdP. </div><div>(7) IdP verifies the signature of the response, and determines whether to go forward with the transaction. </div><div><br></div><div>FYI, this is basically what was once called Contract Exchange (CX), which is a dormant Working Group in OIDF that started in 2008. Artefact Binding/Connect WG started off from there -- we wanted to build CX but did not have suitable tools. So, in 2009, John, Breno, and I started a new working group that builds the tools that was needed for CX: The AB WG. There after, we have built: </div><div>- A signature mechanism: JWS -- was JSON Simple Sign. </div><div>- An encryption mechanism: JWE -- was JSON Simple Encryption. </div><div>- (and algorithms -- JWA, which was later further separted.) </div><div>- A Token format: JWT </div><div>- A basic communication protocol: OAuth 2.0</div><div>- An identity layer that is built on all the above: OpenID Connect 1.0 Suite</div><div><br></div><div>And finally, we are able to build CX, which should be a pretty small spec now. </div><div><br></div><div>I was talking with John last Thursday about this, whether we should revive CX, or do it in Mobile WG. </div><div>Our conclusion was that since Mobile WG has a similar scope in it, and it probably is a much hassle for MNOs to sign another agreement, it would be better to do it here. (but that's only one opinion.) </div><div><br></div><div>Cheers, </div><div><br></div><div>Nat Sakimura</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-25 23:31 GMT+09:00 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>No not all clients have a client secret. As an example almost no native apps have them. </div><div><br></div><div>Connect allows a asymmetrically signed assertion to be used to authenticate a client. </div><div><br></div><div>That is set up as part of registration and no client secret is returned. </div><div><br></div><div>One option might be that the software statement might contain the clients public key for authentication. That would allow a client to have one key pair in a HSM that could be used across all IDP as an example. <br><br>Sent from my iPhone</div><div><div class="h5"><div><br>On Mar 25, 2015, at 8:57 AM, GONZALO FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank">gonzalo.fernandezrodriguez@telefonica.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<div>Hi John,</div>
<div><br>
</div>
<div>I have been reviewing the Request Object and it sounds good. However I don’t understand why you says that not all the clients will have a symmetric key, everyone has a client_id, client_secret, hasn’t?</div>
<div><br>
</div>
<div>Regarding your proposal about extending the mechanism to digitally sign a text, how the digital signed would be returned to the Service Provider?</div>
<div><br>
</div>
<div>Best,</div>
<div>Gonza.</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday 25 March 2015 13:19<br>
<span style="font-weight:bold">To: </span>Gonzalo Fernández <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank">gonzalo.fernandezrodriguez@telefonica.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@lists.openid.net</a>" <<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-mobile-profile] Interlock Solutions<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap:break-word">
Connect has a way to send an encrypted/signed request.
<div><br>
</div>
<div>Using the request object we would just need to define an additional claim to carry the information.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>In any event I think we are better of sticking to the defined method of encrypting requests.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>John B.</div>
<div><br>
<div>
<blockquote type="cite">
<div>On Mar 12, 2015, at 6:47 AM, GONZALO FERNANDEZ RODRIGUEZ <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" target="_blank">gonzalo.fernandezrodriguez@telefonica.com</a>> wrote:</div>
<br>
<div>
<div style="word-wrap:break-word;font-family:Calibri,sans-serif">
<div style="font-size:14px">Hi Guys,</div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">As I promised yesterday, find below the concern raised in our call yesterday. As you know Torsten has opened a ticket here: <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" target="_blank">http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence</a>. </span></div>
<div style="font-size:14px"><span style="font-size:15px"><br>
</span></div>
<div style="font-size:14px"><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"><span style="font-size:15px"><br>
</span></div>
<div style="font-size:14px"><span style="font-size:15px"><br>
</span></div>
<div style="font-size:14px"><br>
</div>
<div style="font-size:14px">
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>Two solutions to solve the interlock problem</div>
<div><br>
</div>
<div>1. INTERNAL TRANSACTION_ID GENERATION</div>
<ul>
<li>Generate a number in the AuthServer that identifies the transaction. Show this number in both devices: authentication and consuption.</li><li>Pros: SPs don't need to do additional developments.</li><li>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><br>
</div>
<div>2. ADDING QUERY PARAMETER</div>
<ul>
<li>Additional query parameter to allow the SP to customize the message.</li><li>Pros: allow to the SP to set any message containing any value it wants, improving security and probably the UX.</li><li>Cons: in order to allow a secure solution, this query parameter should be encrypted and sign.</li></ul>
</div>
<div style="font-size:14px">Best,</div>
<div style="font-size:14px">Gonza.</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
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>
<br>
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>
<br>
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>
</font></div>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net" target="_blank">Openid-specs-mobile-profile@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span><br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
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>
<br>
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>
<br>
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>
</font>
</div></blockquote></div></div></div><br>_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>
</div>