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

John Bradley <ve7jtb@ve7jtb.com> Thu, 28 January 2016 12:17 UTC

Return-Path: <ve7jtb@ve7jtb.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 30BD21B3C95 for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 04:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 iCGs9bNGqHjq for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 3DC8C1A21C3 for <oauth@ietf.org>; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id 6so35087450qgy.1 for <oauth@ietf.org>; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ntgS1yPO3TrD0/0CYbKMpQitBhWbab5bq1U7DkmCHro=; b=tQU24C7jwMWwe0rYqofCiGciHULBCf0ylDtG63wCuFZ8PFwFhEhXg7yHeobjFnsD8o YsqoOz0IJjW13f42DQtv5li+8DYxzPuvpCQqkng/Buj52YCev4AOxmD8/rLqMsCoAkLu hJDmE9FPpnQXl94mXy6r2EM5hAVgFoGx3BDL9M3yMkZfaTEKBDEswMwPLhZWlqPKAhxq 1B1E2h08PFsSmxiXb7RfiiWvGyDu3+8gVc9YbWq6tXc+7VcjGyMl+SNIfL9V85PsdyS8 XxVy2lQHo0xMgKtxLG7LQjQnsbsa2uiWLqqEOg5KB41gCwYzZo3fZCfTiOK1yqd8y/iX 2x5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ntgS1yPO3TrD0/0CYbKMpQitBhWbab5bq1U7DkmCHro=; b=CxiYuuSHuIU9fb9HOIEZt8CTzFuehmvxNK7lJMRLc89+4wXD4eFpaHvPG162P9pm68 tPtNFoRnTk8fGb50HqMPyXF73i24ZXG6V7AeBp+wz51fNmZ/qtKjuVRbhtJ4NsEmrHRi 82Fvgg1ETlRLBgSzyPX5gMoT4/AcK0lJS6bPNGLKk6X1TZuCNKulaXfAqEgf7gBKIsqM FBwMBtqbxCMioIsBHBbLu/yN/aIB54FlAyR4JmyECH+8JNj5zxY7DFvfmgjv2rJ9EHFx 6Iy2Ll1wRr+mxbyJQuQhHzuQmR9HzGvqCvSXgKxi8wB5kpKhJ6X7gFUZ/irxmIi7Ezev 1uEg==
X-Gm-Message-State: AG10YOTtZuUs8bvYDmLPZgmOf7jqhD5Ypjiw3/ewGwZDY6gshGfYLWxcxXjTYEW7X7ScRA==
X-Received: by 10.140.98.53 with SMTP id n50mr3121003qge.9.1453983448298; Thu, 28 Jan 2016 04:17:28 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id m11sm3477930qkl.47.2016.01.28.04.17.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 04:17:27 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8FAEE555-2A74-4BEA-8D9E-E5320E8AD814"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <56A8FA46.60807@gmail.com>
Date: Thu, 28 Jan 2016 09:17:23 -0300
Message-Id: <68C4E8AC-7C1F-411D-83B9-7C8A0A82FB94@ve7jtb.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>
To: Sergey Beryozkin <sberyozkin@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/VtrfI9ZabMIiOI0yG1NMFqsRL3k>
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 12:17:31 -0000

Some people want exactly that behaviour.  If the user approves scope A on device a and scope B on device b, they want both to have scopes A & B.

Given that many AS are custom built for a specific service this can work for them.   It really depends on the API/Service what policy you want.  

When doing a generic library if it is not selectable someone will complain because they wanted it the other way.

Personally I don’t like that approach but perhaps people like twitter etc know better.

John B.

> On Jan 27, 2016, at 2:11 PM, Sergey Beryozkin <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>> 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
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth