Re: [Txauth] Use Case: Directed Tokens

Denis <denis.ietf@free.fr> Fri, 03 July 2020 09:19 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3B3A0B6F for <txauth@ietfa.amsl.com>; Fri, 3 Jul 2020 02:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 q3UZjF56GfXs for <txauth@ietfa.amsl.com>; Fri, 3 Jul 2020 02:19:29 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC793A0B84 for <txauth@ietf.org>; Fri, 3 Jul 2020 02:19:28 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id yZKR2200K4FMSmm03ZKS2W; Fri, 03 Jul 2020 11:19:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 11:19:26 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt <dick.hardt@gmail.com>, Tom Jones <thomasclinganjones@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth@ietf.org, Tobias Looker <tobias.looker@mattr.global>
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <dd8ef917-c63a-0070-810a-aecfd9aac0a0@free.fr> <CAJmmfSRMWRMQbfZ2ktaRRq1oVeZtXSRf0TGiCJmcLi1FJF6N+w@mail.gmail.com> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <CAK2Cwb4RMRT-_AJerg6DbGJ08naO1=aHOD3r-RKaU0N5BVvDjw@mail.gmail.com> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> <CAD9ie-sSA8EHXA_y4KErvbhWw243EM17C2kEm_T3hCZGqxNqjA@mail.gmail.com> <CAK2Cwb6Kadvv97D+yH4oD9qPwOwdpG72DjiApSFa4gzH5LyLyw@mail.gmail.com> <CAD9ie-scXK9HX4f0gfcSMbVinvwArrUpqPA0p+icymOxc5n2-w@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <88ca4d3c-4605-5220-279e-d1665cbc076d@free.fr>
Date: Fri, 03 Jul 2020 11:19:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAD9ie-scXK9HX4f0gfcSMbVinvwArrUpqPA0p+icymOxc5n2-w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6BAC74B084CDCC4CEC48E7AF"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/TGhFohOTGcTuTlAk3C6u341zT_Y>
Subject: Re: [Txauth] Use Case: Directed Tokens
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 09:19:38 -0000

Hello  Dick,
> I agree it is not always true, sorry I did not make that clear.
>
> My statement is that OAuth 2.0 does not require the AS to have 
> knowledge of the RS.

As soon as the scope parameter is being used, then the AS has a prior 
knowledge of the RS.
When the scope parameter is not used, then the client has no ability to 
modulate the attributes.

Even when the AS has a no prior knowledge of the RS, when the access 
token is targeted to a given RS,
then the AS has the knowledge of which RS is likely to be accessed by 
the client.

While it may be interesting to list some of the limitations of OAuth 
2.0, it is much more important
to focus on the characteristics we would like to support with GNAP ...  
and to mention them in the charter.

Denis

>
> On Thu, Jul 2, 2020 at 10:56 AM Tom Jones 
> <thomasclinganjones@gmail.com <mailto:thomasclinganjones@gmail.com>> 
> wrote:
>
>     Dick, the statement about the AS and RS is not always true. In
>     federations we are always concerned that information is not leaked
>     outside the approved parties and the AS messages will likely be
>     encrypted for the sole use of the RS.
>     Peace ..tom
>
>
>     On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt <dick.hardt@gmail.com
>     <mailto:dick.hardt@gmail.com>> wrote:
>
>         Apologies for the delayed response:
>
>         On Fri, Jun 26, 2020 at 9:04 AM Denis <denis.ietf@free.fr
>         <mailto:denis.ietf@free.fr>> wrote:
>
>             The principle where a RS would only have relationships
>             with one AS would make the model non scalable.
>             It would prevent to get attributes from two different
>             ASs,  for example:
>             identity attributes from a bank and a master degree
>             diploma from a university.
>
>
>         Where do you see that the RS can have a relationship with only
>         one AS?
>
>
>             For privacy reasons, every AS should know as little as
>             possible about the interactions between a client and
>             multiple RSs.
>             It is even possible that this goes as little as knowing
>             /nothing at all/.
>
>
>         OAuth 2.0 works this way now.
>
>
>             The OAuth 2.0 assumption where the AS is in a position to
>             know all the interactions of a given user has with all the
>             RSs
>             that an AS server has a relationship with should not be
>             re-iterated.
>
>
>         I am still confused why you think the AS knows anything abou
>         the interactions a given use has with all the RSs. The AS
>         knows which clients the user is using, but does not need to
>         have any knowledge of which RSs a client is accessing.
>         The AS does not need to know anything about the RS. The RS
>         clearly needs to trust the AS, as it is trusting the access
>         granted by the AS to the client, but it is unidirectional
>         trust between the RS and the AS.
>
>         /Dick
>