Re: [OAUTH-WG] Potential new OAuth client assertion flow

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 15 February 2018 14:37 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE78912DA12 for <oauth@ietfa.amsl.com>; Thu, 15 Feb 2018 06:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quNCjKn7cCRc for <oauth@ietfa.amsl.com>; Thu, 15 Feb 2018 06:37:21 -0800 (PST)
Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F53F1270A7 for <oauth@ietf.org>; Thu, 15 Feb 2018 06:37:21 -0800 (PST)
Received: from [192.168.0.107] ([78.130.190.73]) by :SMTPAUTH: with SMTP id mKf1eHZ8DGENQmKf2eeAt6; Thu, 15 Feb 2018 07:37:20 -0700
To: oauth@ietf.org
References: <CAHuoes4VmfNKetbCum+xMfA=fF4NoYU=9YDoEwC47QDeYRnCcQ@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <d27003a5-0782-808e-b650-bbeaaee1a949@connect2id.com>
Date: Thu, 15 Feb 2018 16:37:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAHuoes4VmfNKetbCum+xMfA=fF4NoYU=9YDoEwC47QDeYRnCcQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030007090203050600040802"
X-CMAE-Envelope: MS4wfJqBijTfl3tQrTKvN9KdpKbEETRy1VStoQJcAsPfVQoGNCN4V62IiyMJOPhnLUT7Ma5Fx4m1uI5Q5pbiVZuS7Mt5WrwBoh7nYZOSapu0GAtlIEe6AAF+ 7XhneI6yCXQojtqvhylYl9hATWQXRzzRTLSlmx7XZe/sLvQvyTIHMtUv
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Az8LPlf_0Lkr99QriuVuOFx-mk4>
Subject: Re: [OAUTH-WG] Potential new OAuth client assertion flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Feb 2018 14:37:23 -0000

Hi Omer and welcome to the Oauth WG,

On 14/02/18 22:48, Omer Levi Hevroni wrote:
> Hello
> My name is Omer, and I am working at Soluto. We wanted to find a way to
> authenticate our mobile application, without any user interaction - as this
> will affect the user experience. We developed a new authentication flow,
> similar to JWT client assertion. I've gave a talk about this flow in a few
> conferences, and the main feedback was that it is interesting enough to
> consider writing a RFC about it.
> Currently I'm looking to hear more opinions before starting to write RFC -
> so any feedback will be appreciated. I'm also looking for someone to help
> me getting started and reviewing the RFC - if you're interested let me know.
> To find more about this solution:
>  - This is a blog post describing it: https://blog.solutotlv.com
> /userless-mobile-authentication/
>  - This is a link to the slides (recording should be available soon):
> https://www.slideshare.net/SolutoTLV/authentication-w
> ithout-authentication-appsec-california
Looks like a neat protocol to maintain a continuous auth session between
client and AS.

Did you take a look at https://tools.ietf.org/html/rfc7523#section-2.1 ?

This may be more suitable to pass the JWT, rather than tunneling it via
the password grant.

Vladimir