Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Denis <denis.ietf@free.fr> Thu, 13 August 2020 13:49 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 B6E0B3A0C45 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 06:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level:
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 nXOb2jHHE5Kd for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 06:49:22 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B873A0C43 for <txauth@ietf.org>; Thu, 13 Aug 2020 06:49:21 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id F1pK230042bcEcA031pKAT; Thu, 13 Aug 2020 15:49:19 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 13 Aug 2020 15:49:19 +0200
X-ME-IP: 90.79.51.120
To: Justin Richer <jricher@mit.edu>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr> <ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu> <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <CAJot-L2hykst2vFxcwLn_auDMMaw7psVwsKFHKhQp9DA49ydWg@mail.gmail.com> <A4DC7B4E-FD34-454F-9396-B971CF5D57A4@mit.edu> <CAD9ie-tKEp+PV3F4p84Zbu7Kd1dQutawnzHybt8cmg-XniLYLQ@mail.gmail.com> <CAOW4vyN4ifCXmk1XAyGK4cEfY1jTp6+AWOL-uNjEpVcp0Ku0UQ@mail.gmail.com> <CAD9ie-ugjNevqKAPWFjKqGMMpCvX6yyC=M4bs9naenJf-k9uqg@mail.gmail.com> <CAOW4vyOrXstAvc3eKbsUh+gOPT-79nevR8nT5FyKTe+aAQ1pSw@mail.gmail.com> <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> <e485b7e5-2524-af43-f0af-81ae1d1ea745@free.fr> <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <4432c842-ee1c-40bc-1337-0db4cc96dd83@free.fr>
Date: Thu, 13 Aug 2020 15:49:19 +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: <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu>
Content-Type: multipart/alternative; boundary="------------278383E0687200691EF3EB4C"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9oJYSTM7toQB9TtUCd4yEvY0e2k>
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
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: Thu, 13 Aug 2020 13:49:27 -0000

Justin,

> Denis,
>
> This isn’t mandated, this is one optional flow for the cases where the 
> RS :wants: to talk to the AS.

It is good to know. But what will be the rational(s) for it ? Token 
introspection ?
If this is the single case, since token transparency is needed for 
privacy reasons, it is doubtful that it would still be needed.

If flows can be made simpler, let us make them simpler.

Denis

>
>  — Justin
>
>> On Aug 12, 2020, at 12:02 PM, Denis <denis.ietf@free.fr 
>> <mailto:denis.ietf@free.fr>> wrote:
>>
>> Justin,
>>
>> A soon as the RS needs to talk to the GS (step 2a) , it is a "Big 
>> Brother by Design" architecture.
>> Do you want to mandate it ?
>>
>> Denis
>>
>>> +1 to this. I think that the core protocol needs to be designed to 
>>> allow this kind of action, but I also think it is possible that the 
>>> details of this could end up in an extension to the main document. 
>>> I’ve put a flag in the ground for this in XYZ in sections 10.3 and 
>>> 10.4, which is adapted from UMA2’s distributed authorization protocol:
>>>
>>> https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3
>>>
>>> The important detail here, in XYZ’s design, is that the RS has a 
>>> clear way to communicate to the client what will be needed to 
>>> fulfill the request, and the client/orchestrator/whatever has a 
>>> clear way to incorporate that into the main protocol. The details of 
>>> (2) using the XYZ pattern are:
>>>
>>> +-----------+     +--------------+  +----+  +----+ 
>>>  +---------------------+
>>> | Requestor |      | Orchestrator |  |    |  | GS |  | Resource 
>>> Controller |
>>> |  was     |      |     was      |  | RS |  | or |  |         was    
>>>      |
>>> | User     |      |   Client     |  |    |  | AS |  |    Resource 
>>> Owner   |
>>> +-----------+      +--------------+  +----+  +----+ 
>>>  +---------------------+
>>>   |(1) ServiceRequest     |            |  |                |
>>>   |---------------------->|            |  |                |
>>>   |                       |(2) ServiceIntent:AuthZChallenge     |
>>>   |                       |----------->|  |                |
>>>   |                     |            |       |          |
>>>   |                     |            |(2a) Register resource set
>>>   |                       | |------>|                |
>>> |                       |            |       |               |
>>> |                       |            |(2b) Return resource reference 
>>> handle
>>> |                       | |<------|                |
>>> |                       |            |       |               |
>>> |                       |(2c) Return AS URL and resource reference 
>>> handle
>>> |                       |<-----------|  |                |
>>> |                       |            |       |               |
>>>   |        |(3) AuthZRequest(AuthZChallenge, include resource handle)
>>>   |  |------------------->|                |
>>>
>>>
>>> Note that the client can ALSO request additional resources on top of 
>>> what the RS returned in (2b), since this is passed simply as one 
>>> element of the array.
>>>
>>>  — Justin
>>>
>>>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <fpo@adorsys.de 
>>>> <mailto:fpo@adorsys.de>> wrote:
>>>>
>>>> Hello Dick,
>>>>
>>>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com 
>>>> <mailto:dick.hardt@gmail.com>> wrote:
>>>>
>>>>     Hi Francis
>>>>
>>>>     The user is an entity, not a role in the protocol in how I am
>>>>     defining roles, so steps (1) and (7) are confusing to me on
>>>>     what is happening.
>>>>
>>>> "Requestor" is the role (*was* User). So the UML participant 
>>>> refers to the role "Requestor"
>>>>
>>>>
>>>>     I also think that (2) could be an extension to GNAP, rather
>>>>     than part of the core protocol.
>>>>
>>>> If you make it an extension, you hide. It shall rather be an 
>>>> optional, integral part of the protocol. If the 
>>>> "Orchestrator/Negotiator/Client" can translate the service request 
>>>> into a resource request, then there will be no need to invoke (2).
>>>>
>>>> When we move beyond identity management, cases become complex and 
>>>> it makes sense to explicitly display this possibility in the 
>>>> protocol flow.
>>>>
>>>> In some open banking designs,
>>>> - the "Orchestrator/Negotiator/Client" will not know the AS to talk 
>>>> to unless the call (2).
>>>> - the request (2) might result in an exemption, meaning no need for 
>>>> further authorization, allowing to skip (3, 4, 5) and even (6).
>>>>
>>>> /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha
>>>>     <fpo@adorsys.de <mailto:fpo@adorsys.de>> wrote:
>>>>
>>>>         In this context, I suggest we pick some words to work with,
>>>>         and sharpen them as we move on, discover and map new use
>>>>         cases to the protocol.
>>>>
>>>>         In this diagram from the original thread
>>>>         (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/),
>>>>         I replaced the words:
>>>>
>>>>         +-----------+     +--------------+  +----+  +----+
>>>>          +---------------------+
>>>>         | Requestor |      | Orchestrator |  |    |  | GS |  |
>>>>         Resource Controller |
>>>>         |   was  |      |     was      | | RS |  | or |  |       
>>>>          was        |
>>>>         |  User  |      |   Client     |  | |  | AS |  |   
>>>>         Resource Owner   |
>>>>         +-----------+ +--------------+  +----+  +----+
>>>>          +---------------------+
>>>>           |(1) ServiceRequest     |         |       |   |
>>>>         |---------------------->|           |       |     |
>>>>           |                       |(2) ServiceIntent:AuthZChallenge
>>>>            |
>>>>           |  |<---------->|       |               |
>>>>           |                       |         |       |   |
>>>>           |                       |(3) AuthZRequest(AuthZChallenge)
>>>>            |
>>>>           |  |------------------->|             |
>>>>           |                       |         |       |(4)
>>>>         ConsentRequest:Grant
>>>>           |                       |         |  |<-------------->|
>>>>           |                       |(5) GrantAccess(AuthZ)    |
>>>>           |  |<-------------------|             |
>>>>           |                       |         |       |   |
>>>>           |                       |(6)
>>>>         ServiceRequest(AuthZ):ServiceResponse
>>>>           |  |<---------->|       |               |
>>>>           |(7) ServiceResponse    |         |       |   |
>>>>         |<----------------------|           |       |     |
>>>>           +                       +         +       +   +
>>>>
>>>>         The purpose of the GNAP protocol is to help negotiate
>>>>         access to a protected resource. It starts with a requestor
>>>>         delegating activity to an orchestrator. These are all
>>>>         roles, no entities. Let focus on mapping the use cases to
>>>>         the protocol roles and interactions so wwe can discover
>>>>         what is missing.
>>>>
>>>>         It seems cumbersome to use it in discussions as it is
>>>>         impossible to give the word "Client" a clear definition.
>>>>
>>>>         We can mention in the final document, that the
>>>>         "Orchestrator" (or whatever word we finally use) plays the
>>>>         same role as the "Client" in oAuth2.
>>>>
>>>>         Best regards.
>>>>         /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt
>>>>         <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote:
>>>>
>>>>             I agree with Justin. Redefining well used terms will
>>>>             lead to significant confusion. If we have a different
>>>>             role than what we have had in the past, then that role
>>>>             should have a name not being used already in OAuth or
>>>>             OIDC.
>>>>
>>>>             Given what we have learned, and my own experience
>>>>             explaining what a Client is, and is not, improving the
>>>>             definition for Client could prove useful. I am not
>>>>             suggesting the term be redefined, but clarified.
>>>>
>>>>             For example, clarifying that a Client is a role an
>>>>             entity plays in the protocol, and that the same entity
>>>>             may play other roles at other times, or some other
>>>>             language to help differentiate between "role" and "entity".
>>>>
>>>>             /Dick
>>>>             ᐧ
>>>>
>>>>             On Wed, Aug 5, 2020 at 8:20 AM Justin Richer
>>>>             <jricher@mit..edu <mailto:jricher@mit.edu>> wrote:
>>>>
>>>>                 I’m in favor of coming up with a new term that’s a
>>>>                 better fit, but I’m not really in favor of taking
>>>>                 an existing term and applying a completely new
>>>>                 definition to it. In other words, I would sooner
>>>>                 stop using “client” and come up with a new, more
>>>>                 specific and accurate term for the role than to
>>>>                 define “client” as meaning something completely
>>>>                 different. We did this in going from OAuth 1 to
>>>>                 OAuth 2 already, moving from the
>>>>                 even-more-confusing “consumer” to “client”, but
>>>>                 OAuth 2 doesn’t use the term “consumer” at all, nor
>>>>                 does it use “server” on its own but instead always
>>>>                 qualifies it with “Authorization Server” and
>>>>                 “Resource Server”.
>>>>
>>>>                 GNAP can do something similar, in my opinion. But
>>>>                 what we can’t do is ignore the fact that GNAP is
>>>>                 going to be coming up in a world that is already
>>>>                 permeated  by OAuth 2 and its terminology. We don’t
>>>>                 have a blank slate to work with, but neither are we
>>>>                 bound to use the same terms and constructs as
>>>>                 before. It’s going to be a delicate balance!
>>>>
>>>>                  — Justin
>>>>
>>>>>                 On Aug 4, 2020, at 3:32 PM, Warren Parad
>>>>>                 <wparad@rhosys.ch <mailto:wparad@rhosys.ch>> wrote:
>>>>>
>>>>>                 I think that is fundamentally part of the question:
>>>>>
>>>>>                     We are clear that we are producing a protocol
>>>>>                     that is
>>>>>                     conceptually (if not more strongly) related to
>>>>>                     OAuth 2.0, and reusing terms
>>>>>                     from OAuth 2.0 but with different definitions
>>>>>                     may lead to unnecessary
>>>>>                     confusion
>>>>>
>>>>>
>>>>>                 If we say that this document assumes OAuth2.0
>>>>>                 terminology, then we should not change the
>>>>>                 meanings of any definition. If we are saying this
>>>>>                 supersedes or replaces what OAuth 2.0 creates,
>>>>>                 then we should pick the best word for the job and
>>>>>                 ignore conflicting meanings from OAuth 2.0. I have
>>>>>                 a lot of first hand experience of industries
>>>>>                 "ruining words", and attempting to side-step the
>>>>>                 problem rather than redefining the word just
>>>>>                 confuses everyone as everyone forgets the original
>>>>>                 meaning as new documents come out, but the
>>>>>                 confusion with the use of a non-obvious word
>>>>>                 continues.
>>>>>
>>>>>                 Food for thought.
>>>>>                 - Warren
>>>>>
>>>>>                 	
>>>>>                 Warren Parad
>>>>>                 Founder, CTO
>>>>>
>>>>>                 Secure your user data and complete your
>>>>>                 authorization architecture. Implement Authress
>>>>>                 <https://bit..ly/37SSO1p>.
>>>>>
>>>>>
>>>>>                 On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk
>>>>>                 <kaduk@mit.edu <mailto:kaduk@mit.edu>> wrote:
>>>>>
>>>>>                     Hi Denis,
>>>>>
>>>>>                     On Tue, Aug 04, 2020 at 11:31:34AM +0200,
>>>>>                     Denis wrote:
>>>>>                     > Hi Justin,
>>>>>                     >
>>>>>                     > Since you replied in parallel, I will make a
>>>>>                     response similar to the one
>>>>>                     > I sent to Dick.
>>>>>                     >
>>>>>                     > > Hi Denis,
>>>>>                     > >
>>>>>                     > > I think there’s still a problem with the
>>>>>                     terminology in use here. What
>>>>>                     > > you describe as RS2, which might in fact
>>>>>                     be an RS unto itself, is a
>>>>>                     > > “Client” in OAuth parlance because it is
>>>>>                     /a client of RS1/. What you
>>>>>                     > > call a “client” has no analogue in the
>>>>>                     OAuth world, but it is not at
>>>>>                     > > all the same as an OAuth client. I
>>>>>                     appreciate your mapping of the
>>>>>                     > > entities below, but it makes it difficult
>>>>>                     to hold a discussion if we
>>>>>                     > > aren’t using the same terms.
>>>>>                     > >
>>>>>                     > > The good news is that this isn’t OAuth,
>>>>>                     and as a new WG we can define
>>>>>                     > > our own terms. The bad news is that this
>>>>>                     is really hard to do.
>>>>>                     > >
>>>>>                     > > In GNAP, we shouldn’t just re-use existing
>>>>>                     terms with new definitions,
>>>>>                     > > but we’ve got a chance to be more precise
>>>>>                     with how we define things.
>>>>>                     >
>>>>>                     > In the ISO context, each document must
>>>>>                     define its own terminology. The
>>>>>                     > boiler plate for RFCs does not mandate a
>>>>>                     terminology or definitions section
>>>>>                     > but does not prevent it either. The
>>>>>                     vocabulary is limited and as long as
>>>>>                     > we clearly define what our terms are
>>>>>                     meaning, we can re-use a term already
>>>>>                     > used in another RFC. This is also the ISO
>>>>>                     approach.
>>>>>
>>>>>                     Just because we can do something does not
>>>>>                     necessarily mean that it is a
>>>>>                     good idea to do so.  We are clear that we are
>>>>>                     producing a protocol that is
>>>>>                     conceptually (if not more strongly) related to
>>>>>                     OAuth 2.0, and reusing terms
>>>>>                     from OAuth 2.0 but with different definitions
>>>>>                     may lead to unnecessary
>>>>>                     confusion.  If I understand correctly, a
>>>>>                     similar reasoning prompted Dick to
>>>>>                     use the term "GS" in XAuth, picking a name
>>>>>                     that was not already used in
>>>>>                     OAuth 2.0.
>>>>>
>>>>>                     -Ben
>>>>>
>>>>>                     -- 
>>>>>                     Txauth mailing list
>>>>>                     Txauth@ietf.org <mailto:Txauth@ietf.org>
>>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>>                 -- 
>>>>>                 Txauth mailing list
>>>>>                 Txauth@ietf.org <mailto:Txauth@ietf.org>
>>>>>                 https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>                 -- 
>>>>                 TXAuth mailing list
>>>>                 TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>>>>                 https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>             -- 
>>>>             TXAuth mailing list
>>>>             TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>>>>             https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>>
>>>>         -- 
>>>>         Francis Pouatcha
>>>>         Co-Founder and Technical Lead
>>>>         adorsys GmbH & Co. KG
>>>>         https://adorsys-platform.de/solutions/
>>>>
>>>>
>>>>
>>>> -- 
>>>> Francis Pouatcha
>>>> Co-Founder and Technical Lead
>>>> adorsys GmbH & Co. KG
>>>> https://adorsys-platform.de/solutions/
>>>
>>
>