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

Omer Levi Hevroni <omerlh@gmail.com> Thu, 15 February 2018 14:48 UTC

Return-Path: <omerlh@gmail.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 BADBB12741D for <oauth@ietfa.amsl.com>; Thu, 15 Feb 2018 06:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P05tEFJl0n4z for <oauth@ietfa.amsl.com>; Thu, 15 Feb 2018 06:48:57 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33ABC1275F4 for <oauth@ietf.org>; Thu, 15 Feb 2018 06:48:57 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id a2so23599654otf.2 for <oauth@ietf.org>; Thu, 15 Feb 2018 06:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LbR3Hc8KyZUWXY2qurKjFD+DJs/SmE9TI8nSK204XkA=; b=Col2pk1SbF7+ydNbCprYO3stw1WAxtMEOkBWlwwM9rUD8GNtECwr81vBnbc8ia1vOY +K3dTfPUaj8gihqoZgIDaV9KYIt4ExnyXr9mOEte5rRWYANjjOj8WgBF5yvkhLAQcXcb zbYIrNdINppTGd4AJrjwlzYM2e+4FpC25a6oZymIcKKQEc2ZscS8S9osusX+V7oiuhy3 fPxKXmAuxt5tilksQ4kx1FSDiigzS42BbgRldkT/8pZq4bUjvi10D4ESPxQ0gkPDopG6 6NTYDj+dx6HHu1iNKUdfolS+ZkR7qVNZ9g8ggBeVB5+Rl37zEE5r0TABFeJEOTpxvmsN dhxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LbR3Hc8KyZUWXY2qurKjFD+DJs/SmE9TI8nSK204XkA=; b=oPMLsle32zWavwkj/Wx1yucrZwhs5JVXSIBhhVJBmhTYV+YWitWzS2Dmogm6EmA+nV LOoqZqlUAkcnEE10PswL7hvwbSHR7kASBsjbwl5S9FiZ608iuLp4HQCcIemV8EJOkIa1 xJPAMk57PLclMhSu272xY+3+A9nhMs3Z4cZHgyfkJLEbzJbB+DY3XdExGPhGDc3tiQRT bzfB7DpH2ALWbHXPwtGvVsMuLHzxsQOSV4APhQUYOFd4PP12jwlaBXxIA16Hfeo417O0 EpdvQD8i/GLIQ2XUke1e9MISTvjXqE2BaFGtQcGqQk+PAm6eEYsEabhjaYbZjoGTw+qp iVHw==
X-Gm-Message-State: APf1xPDetjpTyfflWh9GqGqHZPRxPk7zEXheI6Crv0F8KABXJalAAWFW KadwcFk880VIezxltv7EDReKOX8rAPd6MM2W9RECrg==
X-Google-Smtp-Source: AH8x2241CkW8xBgt7uNyoJIU3RthU/n4Q/PbnykmtLnX5ZaSAf2OilYvDznHADgz1LMPvbBJ5vMnfCu8Ah86ttqAh+U=
X-Received: by 10.157.38.164 with SMTP id l33mr2172937otb.196.1518706136582; Thu, 15 Feb 2018 06:48:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.89.150 with HTTP; Thu, 15 Feb 2018 06:48:36 -0800 (PST)
In-Reply-To: <d27003a5-0782-808e-b650-bbeaaee1a949@connect2id.com>
References: <CAHuoes4VmfNKetbCum+xMfA=fF4NoYU=9YDoEwC47QDeYRnCcQ@mail.gmail.com> <d27003a5-0782-808e-b650-bbeaaee1a949@connect2id.com>
From: Omer Levi Hevroni <omerlh@gmail.com>
Date: Thu, 15 Feb 2018 16:48:36 +0200
Message-ID: <CAHuoes6MBzpD9yf2YQrP2VBYiEgrajJLJM7j1FzkR5gqiCh6GQ@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a11396c10ca116e0565415328"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7r9jY2C7Za8UK9D8hD8y12vc14s>
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:49:00 -0000

Yes, this is my intent - adding a new client assertion (currently the name
I am thinking of is jwt-otp-assertion). The blog post was on how to do that
by using existing OAuth/Open id flows.

On Thu, Feb 15, 2018 at 4:37 PM, Vladimir Dzhuvinov <vladimir@connect2id.com
> wrote:

> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>