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/ >
- [Txauth] Revisiting the photo sharing example (a … Denis
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Justin Richer
- Re: [Txauth] Revisiting the photo sharing example… Tom Jones
- Re: [Txauth] Revisiting the photo sharing example… Denis
- Re: [Txauth] Revisiting the photo sharing example… Denis
- Re: [Txauth] Revisiting the photo sharing example… Justin Richer
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Dick Hardt
- Re: [Txauth] Revisiting the photo sharing example… Benjamin Kaduk
- Re: [Txauth] Revisiting the photo sharing example… Warren Parad
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] Revisiting the photo sharing example (… Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Revisiting the photo sharing example (… Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- [GNAP] Terminology Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dave Tonge
- Re: [GNAP] Terminology Tom Jones
- Re: [GNAP] Terminology Mike Jones
- Re: [GNAP] Terminology Denis
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Francis Pouatcha
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] Terminology Dave Tonge
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] Terminology Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Tom Jones
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Tom Jones
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Denis
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Francis Pouatcha
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dick Hardt
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Dave Tonge
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] Terminology Denis
- [GNAP] User consent Denis
- [GNAP] User consent Denis
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] Terminology Justin Richer
- Re: [GNAP] Terminology - into Github Issues Francis Pouatcha
- Re: [GNAP] Terminology - into Github Issues Denis
- Re: [GNAP] User consent Francis Pouatcha
- Re: [GNAP] User consent Tom Jones
- Re: [GNAP] User consent Denis
- Re: [GNAP] User consent Denis
- Re: [GNAP] User consent Francis Pouatcha
- Re: [GNAP] Terminology Tom Jones
- Re: [GNAP] Terminology - into Github Issues Fabien Imbault
- Re: [GNAP] Terminology - into Github Issues Warren Parad
- Re: [GNAP] User consent Dick Hardt
- Re: [GNAP] Terminology Dick Hardt
- Re: [GNAP] Terminology Fabien Imbault
- Re: [GNAP] User consent Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Justin Richer
- Re: [GNAP] [Txauth] Revisiting the photo sharing … Fabien Imbault