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

Denis <denis.ietf@free.fr> Wed, 12 August 2020 16:02 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 6AF503A1386 for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 09:02:35 -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 raucCWHV4PXf for <txauth@ietfa.amsl.com>; Wed, 12 Aug 2020 09:02:32 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212193A1383 for <txauth@ietf.org>; Wed, 12 Aug 2020 09:02:30 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d09 with ME id Eg2T230062bcEcA03g2TXG; Wed, 12 Aug 2020 18:02:29 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 12 Aug 2020 18:02:29 +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>
From: Denis <denis.ietf@free.fr>
Message-ID: <e485b7e5-2524-af43-f0af-81ae1d1ea745@free.fr>
Date: Wed, 12 Aug 2020 18:02:24 +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: <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu>
Content-Type: multipart/alternative; boundary="------------08F78B7D4CB9C11530E22F91"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/wvNXYuIqDw9Vul27kd7GVhw2GsM>
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: Wed, 12 Aug 2020 16:02:36 -0000

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/
>