Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 28 January 2016 09:41 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DCB1B2EBD for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 01:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=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 cJdWh7QJA9ea for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 42D941B2E9D for <oauth@ietf.org>; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id l66so17122377wml.0 for <oauth@ietf.org>; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=k83cTECkoku8hl4geJG6GT8HxRSivSt6w3cQ6s+u0ms=; b=zBKQr+yb47NDvVKfDTwWqFUO2jatKTW/9wXm7chgRf5QP3qMBV6aDDhLLEWndR155G SFJheOUabq6iklgozONYLIMdGYZCOW5Dih6hEvgwT9d9vZQXlyvL17cRkGLUMJKKKxiZ gA5iuWDjOqbEQVbdnVHQTo+IgjSK2c7ZVtXZtYzI+u+dek7/hx410kIh6bcVd2Gwbhgt DBVkIw0DVTxBQJm+eVp/V5DBGqjCWox11ckD9eR7/RgGbFwJiO+rdNGVfQTFyWDCo0J9 O2V8fuwsXovwiiEpKMdgCW8lPi/XVblY4ukfGLIGRgQjZxwKd/OLmJCzPMCLW2BqR/rw vNEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=k83cTECkoku8hl4geJG6GT8HxRSivSt6w3cQ6s+u0ms=; b=aCB9qDFHZIsQhETXOTOBG204zjxsA+F0Y8GXW3ubHt0+Tz1OfFdi6x0mJadPWhGwTO 3VYelCkb+1WlRIiB7NTt5yZ/vV4yTcE3O2AKusUCGibNTlvJ04WVA/+KUkpOp/9ygVKu hjA4jVpSxU2lW4jHMamwtuVtpwIj0PoycwAS89fb7tivmfkiJiUsm2GryZWAXwUDWunC kWfzFbi5XjYqO7iZZ9vRblbCPnpJLs6LIOrjuEHj5vUgLP80MstH3deo9jyZrELHnfdp qlLTJi0zeTdjBqpLB+CMGtSnc8mdy3rqNqwsYerQsBlGslOW8ZHm6ewIaNHEaeKXgyUH yG8g==
X-Gm-Message-State: AG10YOReM7AcxtZ3o7Gu5tiLRg/8Gm/sDvO0TBlPIAFu+mx8Tj5OFeEPPLdyyqNbFxx/EA==
X-Received: by 10.28.3.131 with SMTP id 125mr2163710wmd.14.1453974064738; Thu, 28 Jan 2016 01:41:04 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id kb5sm10190192wjc.22.2016.01.28.01.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 01:41:03 -0800 (PST)
To: William Denniss <wdenniss@google.com>
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com> <CAAP42hA_3EmJw7fAXSSfg=KynAMF26x6vgm1HyLX1RAS4OpKfQ@mail.gmail.com> <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com> <CAEayHEMrTjDQbdoX3C-2-oGUVVQTzCzDqbWU-hFeAtbSp-tCcg@mail.gmail.com> <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com> <CAEayHEPi7hsu=zkr_qxadp02D9zzLGVDU-AGVZXzm25vE2bJFw@mail.gmail.com> <56A8B542.5060208@gmail.com> <56A8BE1B.2080404@aol.com> <CAEayHEOtpUxMRKduitbe=D3UFHSazMmkf9UQoiPNjZFr0JATOA@mail.gmail.com> <56A8F3A5.8060002@aol.com> <56A8F612.7040208@aol.com> <56A8FA46.60807@gmail.com> <CAAP42hBFaCFBJwekjDZ+EO-A_U9Vc9FasaUFnerEzS7n1KYKRQ@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <56A9E223.90207@gmail.com>
Date: Thu, 28 Jan 2016 09:40:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAAP42hBFaCFBJwekjDZ+EO-A_U9Vc9FasaUFnerEzS7n1KYKRQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/_ICH2gXSBua00NXaNfY4x91wKOc>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Jan 2016 09:41:09 -0000

Hi

On 27/01/16 17:47, William Denniss wrote:
> In our implementation we mostly record grants as per-user,
> per-client_id. However, we treat public clients whose identity we can't
> verify as ineligible for incremental auth. The reason is if a client is
> counterfeiting another client, we don't want to return previous
> authorizations (the user should at least have to grant permissions in
> the context of this other counterfeiting application).  For a public
> client where the return path can be guaranteed by the OS (e.g. Universal
> Links on iOS), this rule can be relaxed, so it's more about public
> clients whose identity cannot be verified (e.g. custom URI scheme, or
> localhost redirect).
>
> I have an idea for how to solve those unverifiable clients too, where
> the client would prove its previous authorization grant by providing the
> current access token on the new "incremental" authorization request.
>
> For verifiable clients, we have an option to "snowball" tokens and
> include previous grants (with the exception of some scopes that need
> per-device approval), using the non-standard param
> include_granted_scopes
> <https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>;.
> Such a request results in a new token being issued with potentially
> increased scope, we don't automatically increase the scope of previously
> issued tokens.
>
> Perhaps this group could consider standardizing Incremental OAuth. There
> are valuable lessons & techniques that several people here have learnt
> and implemented over the years, as shown by this thread. I might be
> willing to put together a draft.

IMHO it would be very useful, +1

Thanks, Sergey

>
>
>
> On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> wrote:
>
>     Hi George
>
>     Thanks. I think I'll need to spend more time on thinking about the
>     way it has to be implemented, but I guess one thing I realize is
>     that using only access tokens as records for this purpose is not
>     ideal/generic.
>
>     That said, it is not clear to me that a per-instance level consent
>     makes sense only when the dynamic registration is used.
>
>     Suppose we have a statically registered client, with the client id
>     shared between 100 devices or even confidential clients. I'm
>     actually not sure how realistic it is that the same user works with
>     more than one device sharing the same id, but assuming it is
>     possible sometimes, and further, with incremental authentication in
>     place,
>
>     we can have a situation where while working on device1 a user has
>     approved 'a' while on device2 - scope "b", with both devices sharing
>     the same client id.
>
>     May be I'm making it too complex :-)
>
>     Thanks, Sergey
>
>     On 27/01/16 16:53, George Fletcher wrote:
>
>         My recommendation, like the others, is to store consent by
>         client_id:user and then try and leverage dynamic client
>         registration if
>         instance level consent is needed.
>
>         On 1/27/16 11:43 AM, George Fletcher wrote:
>
>             Yes, I was thinking mostly of "native apps"... though you
>             bring up a
>             good point. It would be great if "installable" web apps could do
>             dynamic client registration:)  I suppose for a "public"
>             client that is
>             loaded onto a device, the "installation" process could
>             obtain a new
>             client_id for that instance. Cookies might work, or have the app
>             generate a unique identifier and use that in conjunction
>             with the
>             client_id?
>
>             Thanks,
>             George
>
>             On 1/27/16 11:07 AM, Thomas Broyer wrote:
>
>
>
>                 On Wed, Jan 27, 2016 at 1:54 PM George Fletcher
>                 <gffletch@aol.com <mailto:gffletch@aol.com>
>                 <mailto:gffletch@aol.com <mailto:gffletch@aol.com>>> wrote:
>
>                      The difference might be whether you want to store
>                 the scope
>                      consent by client "instance" vs client_id
>                 application "class".
>
>
>                 Correct me if I'm wrong but this only makes sense for
>                 "native apps",
>                 not for web apps, right?
>                 (of course, now with "installable web apps" –e.g.
>                 progressive web
>                 apps–, lines get blurry; any suggestion how you'd do it
>                 then? cookies?)
>
>
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     --
>     Sergey Beryozkin
>
>     Talend Community Coders
>     http://coders.talend.com/
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>