Re: [GNAP] User consent

Denis <denis.ietf@free.fr> Fri, 14 August 2020 16:39 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 BAB4F3A0E33 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 09:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 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, 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 j_kd37HZdWnF for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 09:39:52 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDF43A0E1E for <txauth@ietf.org>; Fri, 14 Aug 2020 09:39:51 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d19 with ME id FUfn230012bcEcA03Ufnmb; Fri, 14 Aug 2020 18:39:50 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 14 Aug 2020 18:39:50 +0200
X-ME-IP: 90.79.51.120
To: Francis Pouatcha <fpo@adorsys.de>
Cc: "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> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <CAK2Cwb5ZVpTzOtQBGcw5zgteGe5EGR9sMBxWVrQ2mZP7-tc-kg@mail.gmail.com> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <CAD9ie-vrFmSMY6bC4BqtpVn9i6MeFnghOXaHfdhXvOr59u1rzg@mail.gmail.com> <a3e44960-3e2f-03cf-08e7-412525443ff5@free.fr> <CAD9ie-v_YFufNmgfHSx0sr9kmMTjrOa--acic2UAg9LfpLNssQ@mail.gmail.com> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> <CAOW4vyNu=BLC_fKSAU8Nk-oLHXfaU6pNCAc7nbAXXKiUZ=Fnvg@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <e9246035-81ad-e30b-e43a-2145b32684a4@free.fr>
Date: Fri, 14 Aug 2020 18:39:45 +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: <CAOW4vyNu=BLC_fKSAU8Nk-oLHXfaU6pNCAc7nbAXXKiUZ=Fnvg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------EA071D507A1873194207BB77"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/329SBc9jbCA6dYTDbMRY7e9Hgis>
Subject: Re: [GNAP] User consent
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, 14 Aug 2020 16:39:57 -0000

Hi Francis,

In the proposed flow, between (2) and (3), there should be a flow for 
the User Consent. That flow is missing.

In addition, keep in mind that the Resource Controller (RC) can be an 
application with no end-user involved.
Hence, there is no "consent" from such an application, but only the 
enforcement of some rules.

I do not see the relationship with the topic raised in that thread which 
is about User Consent based on information
provided to the User by the RS. If you want to discuss something else, 
please open a new thread.

Denis

> Small digest of the consent discussion into the suggested abstract 
> flow. Please do not nail on the words used (just working assumptions).
> - GS is used to refer to the token manager (what Justin calls 
> Delegation Server (DS) - handles the back-channel stuff)
> - AS is used to refer to the authorization server (what Justin calls 
> Interaction Server (IS) - handles the front-channel stuff)
> - (End User), (Client) are sample entities materializing the 
> corresponding roles (in oAuth2 for example)
>
> Added Separation between GS and AS (resp. DS and IS sse above)
> - 3a: GS forwards request for the RC consent to an AS, that knows how 
> to interact with the RC
> - 3b: AS returns RC consent to GS.
> This separation might help draw a line between token management and 
> user authorization. This is essential for forward thinking into the 
> world of Fido, SSI, DID.
>
> Display front channel and back channel (At the Abstraction Level-0 
> -GNAP, this shall not matter.)
> Steps (1, 4, 7) are good candidates for a front channel, as we are 
> interacting with a potential (End User).
> Steps (2, 3, 5 , 6) are good candidates for back channel.
> Steps (3a, 3b) are candidates for both, as AS might be running on a 
> user device.
>
> Here is the new diagram.
>
> +-----------+  +--------------+  +----+ 
>  +----+   +----+  +---------------------+
> | Requestor |      | Orchestrator |  |    |  |    |   |    |  | 
> Resource Controller |
> |           |      | |  | RS |  | GS |   | AS |  |                     |
> |(End User) |      |   (Client) |  |    |  |    |   |    |  |      
> (End User)     |
> +-----------+  +--------------+  +----+ 
>  +----+   +----+  +---------------------+
>   |(1) ServiceRequest     |      |       |        |                |
>   |---------------------->|            |       |   |                |
>   |                       |(2) ServiceIntent:AuthZChallenge              |
>   |                       |<---------->|       |     |                |
>   |                       |            |       |        |               |
>   |                       |(3) AuthZRequest(AuthZChallenge)              |
>   |                       |------------------->|   |                |
>   |                       |            | 
>  |(3a)ConsentRequest(AuthZChallenge)
>   |                       |      |       |------->|                |
>   |                       |      |       |        |(4) 
> ConsentRequest:Consent
>   |                       |            |       | |<-------------->|
>   |                       |            |  |(3b)UserConsent          |
>   |                       |            |  |<-------|                |
>   |                       |(5) GrantAccess(AuthZ).      |               |
>   |                       |<-------------------| |                |
>   |                       |            |       |        |               |
>   |                       |(6) ServiceRequest(AuthZ):ServiceResponse.    |
>   |                       |<---------->|       |     |                |
>   |(7) ServiceResponse    |            |       |        |               |
>   |<----------------------|            |       |   |                |
>   +                       +            +       +        +               +
>
> Best regards.
> /Francis
>
>
> On Fri, Aug 14, 2020 at 6:14 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     This is a new thread built from "Revisiting the photo sharing
>     example (a driving use case for the creation of OAuth)"
>
>     Hi Dick,
>
>>     I don't see how we can technically standardize a user experience,
>>     and it is not clear why a standard would be needed for
>>     interoperability.
>
>     I already wrote a proposal and made it available to the mailing list.
>
>     An access will be granted by a RS based on an mathematical
>     expression which is formed using some combination of ANDand OR
>     conditions.
>
>     Examples of combinations:
>
>         /condition 1/AND/condition 2
>         condition 1/OR /condition 2/
>         (/condition 1/AND/condition 2)/OR/condition 3
>         (condition 1/OR /condition 2)/AND/condition 3/
>
>     The following notation is being used for the /conditions/:
>
>     /condition x/= { AS identifier + set of attributes types }
>
>     Each RS internally constructs an /authorization table/ with the
>     following content:
>
>     1°For the "authentication" operation: either FIDO U2For a
>     mathematical expression using conditions;
>
>     2°For any other operation: a mathematical expression using conditions.
>
>     Given the operation selected by the client, the RS returns the
>     appropriate mathematical expression and only the associated
>     conditions
>     used in that mathematical expression. The User may then decide
>     whether they are appropriate to him or not.
>
>>      In many jurisdictions there are regulations regarding what
>>     information needs to be conveyed to a user, and potentially a
>>     consent requirement,
>>     for example a site explaining its use of cookies -- but I don't
>>     see how IETF would play a role in that.
>>
>>     On a related note, the browsers attempted to standardize the
>>     username / password prompt, and that has been rejected by pretty
>>     much every site.
>>     The only site I've visited in the last decade that has used the
>>     browsers' built in username / password prompt was the W3C site --
>>     and it was a frustrating
>>     experience since there was no button for account recovery -- it
>>     would just keep popping up.
>
>     What I am proposing is unrelated to the two above cases you mention.
>
>     Denis
>
>>
>>
>>     ᐧ
>>
>>     On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr
>>     <mailto:denis.ietf@free.fr>> wrote:
>>
>>         Dick,
>>
>>>         I think Tom's objection, and I agree with it, is that humans
>>>         don't interact in bits and bytes.
>>>
>>>         I think it is useful to separate human interactions with
>>>         software from software interactions with software.
>>>         The latter we can standardize, the former we can call out as
>>>         part of the overall process, but it is not something
>>>         that is testable or required for interop, so I would argue
>>>         human to software interactions are NOT part of the protocol.
>>
>>         I disagree.  A set of a choices should be presented by the RS
>>         to the Client in a standardized way. The choices made by the
>>         user
>>         should be locally recorded by the Client, hence the RS does
>>         not need to be informed of these choices. The RS will only know
>>         the end result of these choices when/if it gets back one or
>>         more access tokens.
>>
>>         Human to software interactions should be part of the protocol.
>>
>>             RS to Client: a set of choices
>>
>>             Client to RS: Done (choices have been done by the user).
>>
>>         Denis
>>
>>
>>>
>>>         ᐧ
>>>
>>>         On Thu, Aug 13, 2020 at 8:11 AM Justin Richer
>>>         <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>
>>>             It’s a role fulfilled by a person, so I’m not sure where
>>>             the objection you’re raising comes from.
>>>
>>>             Also, whatever roles we define here, whether software or
>>>             human-ware, they need to be related to the protocol.
>>>
>>>              — Justin
>>>
>>>>             On Aug 13, 2020, at 10:59 AM, Tom Jones
>>>>             <thomasclinganjones@gmail.com
>>>>             <mailto:thomasclinganjones@gmail.com>> wrote:
>>>>
>>>>             I strong object to the objectification of human users.
>>>>             It is way past time that the IETF becaume user oriented
>>>>             instead of web service oriented.
>>>>             users are human in my language.
>>>>             Peace ..tom
>>>>
>>>>
>>>>             On Tue, Aug 11, 2020 at 4:38 PM Justin Richer
>>>>             <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>>
>>>>                 If defined as the party operating the client
>>>>                 software, then the user is a role. I believe this
>>>>                 is more accurate and inclusive than the definition
>>>>                 you have proposed with the user as an entity.
>>>>
>>>>                  - Justin
>>>>                 ________________________________________
>>>>                 From: Dick Hardt [dick.hardt@gmail.com
>>>>                 <mailto:dick.hardt@gmail.com>]
>>>>                 Sent: Tuesday, August 11, 2020 6:21 PM
>>>>                 To: Francis Pouatcha
>>>>                 Cc: Justin Richer; Denis; Benjamin James Kaduk;
>>>>                 txauth@ietf.org <mailto:txauth@ietf.org>
>>>>                 Subject: Re: [GNAP] [Txauth] Revisiting the photo
>>>>                 sharing example (a driving use case for the
>>>>                 creation of OAuth)
>>>>
>>>>                 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.
>>>>
>>>>                 I also think that (2) could be an extension to
>>>>                 GNAP, rather than part of the core protocol.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                 On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha
>>>>                 <fpo@adorsys.de
>>>>                 <mailto:fpo@adorsys.de><mailto: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><mailto: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
>>>>                 [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ
>>>>                 <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]%E1%90%A7>
>>>>
>>>>                 On Wed, Aug 5, 2020 at 8:20 AM Justin Richer
>>>>                 <jricher@mit..edu
>>>>                 <mailto:jricher@mit..edu><mailto: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><mailto: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
>>>>
>>>>                 [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
>>>>
>>>>                 Warren Parad
>>>>                 Founder, CTO
>>>>
>>>>                 Secure your user data and complete your
>>>>                 authorization architecture. Implement
>>>>                 Authress<https://bit. <https://bit./>.ly/37SSO1p>.
>>>>
>>>>
>>>>                 On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk
>>>>                 <kaduk@mit.edu
>>>>                 <mailto:kaduk@mit.edu><mailto: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><mailto:Txauth@ietf.org
>>>>                 <mailto:Txauth@ietf.org>>
>>>>                 https://www.ietf.org/mailman/listinfo/txauth
>>>>                 --
>>>>                 Txauth mailing list
>>>>                 Txauth@ietf.org
>>>>                 <mailto:Txauth@ietf.org><mailto:Txauth@ietf.org
>>>>                 <mailto:Txauth@ietf.org>>
>>>>                 https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>                 --
>>>>                 TXAuth mailing list
>>>>                 TXAuth@ietf.org
>>>>                 <mailto:TXAuth@ietf.org><mailto:TXAuth@ietf.org
>>>>                 <mailto:TXAuth@ietf.org>>
>>>>                 https://www.ietf.org/mailman/listinfo/txauth
>>>>                 --
>>>>                 TXAuth mailing list
>>>>                 TXAuth@ietf.org
>>>>                 <mailto:TXAuth@ietf.org><mailto: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/
>>>>                 -- 
>>>>                 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/