Re: [GNAP] User consent

Francis Pouatcha <fpo@adorsys.de> Fri, 14 August 2020 17:03 UTC

Return-Path: <fpo@adorsys.de>
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 4EF403A0E3F for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 10:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
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 9kmeBH72S60n for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 10:03:46 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB6D3A0B31 for <txauth@ietf.org>; Fri, 14 Aug 2020 10:03:45 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id k8so8507010wma.2 for <txauth@ietf.org>; Fri, 14 Aug 2020 10:03:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YIg4MjxhV7V3MPZNEcD4bMPJVQA4o7v/w7fs2jA2iLs=; b=H8eO4usOIny2bVTWKhNlr61GGWXOthNr0CWYdj/cmt4TzfvAim3qa1qHT6S7/Jn5QN 928HDXH9PBMscDU56yr++pc+7+HIB+EJsDV5iyARL5tXgkX0AaR1jrnlYXVzAT7ZGmNH dLeZGf5fAuKW0kgJRJsO8DVCGfYsY0PVeDFRw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YIg4MjxhV7V3MPZNEcD4bMPJVQA4o7v/w7fs2jA2iLs=; b=ieoM0nCh9dpgvprsSSm+6dPCO/ysTbIMrp8sGh98lAUpWLx8wy+j7uI/XO35E8LUtp mBvYistdthntfCoN7YDcHMQqTgp/NiV+xYip/kIWPuaZoWD1KOGhB9D+pgEwrdgcVx3i vDzHZrhbVxlZuDpa0loZqvau/4r4GzcmzLSFl6+koUU8JDjPxxNKwODQtw6ABjl6Wozp MK2fPvgdBQ0dqfH6nzdLJQwZfC/yyFicWsmghELcfq5qRtp90U5I/QX70JJ5tmNXXIqn Xx9kRWtrUgpCXUmaoWAPhPzHIAUiKWy/9Y3D5eQEoEu1k/oFmY8O/0U9Zm1XZSYRr5Xe z5fA==
X-Gm-Message-State: AOAM532eX4dNIISKfPJfTTkqWy7SSIV6aOYrI2LAUnNq50BNcmtYvVK4 Nnug7mekiejFKCRnSQHq45UI8+uBq4C1+zBZSa7OYw==
X-Google-Smtp-Source: ABdhPJx1C0yP30pYpRk9uFxL/T1kIFi0qc5a8hTfZFL8F3q7O+URBMDJvFkl2p4/QZrXDRcJ1Gis/NbOlL9rPRKcGSM=
X-Received: by 2002:a1c:770c:: with SMTP id t12mr3552037wmi.65.1597424624074; Fri, 14 Aug 2020 10:03:44 -0700 (PDT)
MIME-Version: 1.0
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> <e9246035-81ad-e30b-e43a-2145b32684a4@free.fr>
In-Reply-To: <e9246035-81ad-e30b-e43a-2145b32684a4@free.fr>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Fri, 14 Aug 2020 13:03:31 -0400
Message-ID: <CAOW4vyM09xT1tArN0jSL-1gJ6dnM7m_=stAeERftp0xJ5m8_gQ@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046193205acd96706"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/NO_68oyF_CTO_ajNvpOiNDLxh8A>
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 17:03:49 -0000

Hi Denis,


On Fri, Aug 14, 2020 at 12:39 PM Denis <denis.ietf@free.fr> wrote:

> Hi Francis,
>
> In the proposed flow, between (2) and (3), there should be a flow for the
> User Consent. That flow is missing.
>
What User? (End User -> Requestor) or (End User -> Resource Controller)?
What if both are not the same party?

>
> 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.
>
Means you are obtaining the consent from an "End User" in his role as a
"Requestor" of the service? What do you need this consent for?


> 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.
>
NO! Correct thread! Without the diagram, there is no way the reader can
figure out what is being discussed here.

/Francis

>
> 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> 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 AND and 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 U2F or 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> 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> 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>
>>>> 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> 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]
>>>>> Sent: Tuesday, August 11, 2020 6:21 PM
>>>>> To: Francis Pouatcha
>>>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; 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>> 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
>>>>> [
>>>>> 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>> 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<mailtomailto:
>>>>> 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..ly/37SSO1p>.
>>>>>
>>>>>
>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailtomailto:
>>>>> 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/
>>>>> --
>>>>> TXAuth mailing list
>>>>> TXAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>>>
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> --
>> TXAuth mailing list
>> 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/