[Openid-specs-mobile-profile] Interlock Solutions

Mon Mar 30 18:29:47 UTC 2015

FYI, I have an implementation that does more-or-less of the following:

(1) The app registers itself to the IdP, with self-generated key-pair's
public key.
(2) The SP sends request_uri
(3) The app gets the request object from request_uri
(4) The app checks the signature, and displays it to the user: how much
this transaction involves to whome etc.
(5) User taps accept button.
(6) The app counter signs the request object with the private key and sends
the response back to the IdP.
(7) IdP verifies the signature of the response, and determines whether to
go forward with the transaction.

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:
- A signature mechanism: JWS -- was JSON Simple Sign.
- An encryption mechanism: JWE -- was JSON Simple Encryption.
- (and algorithms -- JWA, which was later further separted.)
- A Token format: JWT
- A basic communication protocol: OAuth 2.0
- An identity layer that is built on all the above: OpenID Connect 1.0 Suite

And finally, we are able to build CX, which should be a pretty small spec
now.

I was talking with John last Thursday about this, whether we should revive
CX, or do it in Mobile WG.
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.)

Cheers,

Nat Sakimura

2015-03-25 23:31 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:

> No not all clients have a client secret.   As an example almost no native
> apps have them.
>
> Connect allows a asymmetrically signed assertion to be used to
> authenticate a client.
>
> That is set up as part of registration and no client secret is returned.
>
> 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.
>
> Sent from my iPhone
>
> On Mar 25, 2015, at 8:57 AM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
> Hi John,
>
>  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?
>
>  Regarding your proposal about extending the mechanism to digitally sign
> a text, how the digital signed would be returned to the Service Provider?
>
>  Best,
> Gonza.
>
>
>   From: John Bradley <ve7jtb at ve7jtb.com>
> Date: Wednesday 25 March 2015 13:19
> To: Gonzalo Fernández <gonzalo.fernandezrodriguez at telefonica.com>
> Cc: "openid-specs-mobile-profile at lists.openid.net" <
> openid-specs-mobile-profile at lists.openid.net>
> Subject: Re: [Openid-specs-mobile-profile] Interlock Solutions
>
>   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.
>
>  John B.
>
>  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.
>
>  @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.
>
>  Best,
> Gonza.
>
> ------------------------------
>
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
>
> ------------------------------
>
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150331/67503ded/attachment.html>