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 > >
- [OAUTH-WG] Can the repeated authorization of scop… Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … Justin Richer
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … William Denniss
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … Thomas Broyer
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … John Bradley
- Re: [OAUTH-WG] Can the repeated authorization of … Thomas Broyer
- Re: [OAUTH-WG] Can the repeated authorization of … Justin Richer
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … George Fletcher
- Re: [OAUTH-WG] Can the repeated authorization of … Thomas Broyer
- Re: [OAUTH-WG] Can the repeated authorization of … George Fletcher
- Re: [OAUTH-WG] Can the repeated authorization of … George Fletcher
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … William Denniss
- Re: [OAUTH-WG] Can the repeated authorization of … Sergey Beryozkin
- Re: [OAUTH-WG] Can the repeated authorization of … John Bradley
- Re: [OAUTH-WG] Can the repeated authorization of … John Bradley