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

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 27 January 2016 17:11 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 41C751A903F for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 09:11:39 -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 yPXtoNe77gD4 for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 09:11:38 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 108FD1AC3E4 for <oauth@ietf.org>; Wed, 27 Jan 2016 09:11:37 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id l65so153362468wmf.1 for <oauth@ietf.org>; Wed, 27 Jan 2016 09:11:36 -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=A0aboqr8/ULpGYJF2qjdcxxTz7ZtdcSXyh71OPokxwE=; b=0mspp7W0gFfDuMRBGRAdwWwCQRb4Fu98Voi06j5GuG2ifaTLyLVj4rMGyGay8PDfNN AIylcB/E47MM68XmM/PYr1PYtc8PbypsuS8Mckg4XdpBbFKU99rq1E1+aezyJTdmYGoj 9c4v0i5wOkNIGJiprBXlJ3tUe/OqBT2fvXwgmQpNjW8REo1FUGZdXmD5hUXaySwraQmZ c2+0hN7k++JgkP15ZFcHfBioUAiFi8rjMstoFOw0mcjex53c9sSplgWG+iJR017Buu05 e3VXEDSqYygR+bkcc7CyPWylBBwLOYAgM4lhKap8svs+RBr7nKTQ6ps5WEteHXyRgjIK P5oA==
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=A0aboqr8/ULpGYJF2qjdcxxTz7ZtdcSXyh71OPokxwE=; b=KqaaJFaxJYUBnUs4zmzYK5kFfkK0VqqTqXnaFkAlfMUPLjNNUkfwq1xBi80Q9YV/Qh t0vPTDYvv4cKs+jbGO4O73Sc0aV3AY40Oq28RdltcNWaS/T/by0kCYBqO0OMY3OR1lPU iyUZD5lheEZz21u+OZnVj4fuQZNE49GLoRa3+Tkf27EjHfgDhyWNsbDyPQ2aLbjpcFwd 868fCbJnmN2XMOBaP67XNbAI2eAiDvA934tkkS64ophtytcxfcFODUgTo0swya4ArCV4 cGuJlPVj6EhKn8+I9+8JqlIpJ0FECGxK/ZbKnJyPcQRKYOjnT4bQQwPlQgHkZXVvtBnV 7o9g==
X-Gm-Message-State: AG10YORIPXyV1GgdqpsHbnkbF4svIU2SFSx5lraTf/3WKEn7Ueg2soLybSLPa78CHmQJJw==
X-Received: by 10.28.47.11 with SMTP id v11mr33864873wmv.27.1453914695600; Wed, 27 Jan 2016 09:11:35 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id e198sm8622191wmd.0.2016.01.27.09.11.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 09:11:34 -0800 (PST)
To: George Fletcher <gffletch@aol.com>, Thomas Broyer <t.broyer@gmail.com>, Justin Richer <jricher@mit.edu>
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>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <56A8FA46.60807@gmail.com>
Date: Wed, 27 Jan 2016 17:11:34 +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: <56A8F612.7040208@aol.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SmNA-HPw3kqf2fR9rOFysaaNChc>
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: Wed, 27 Jan 2016 17:11:39 -0000

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/