Re: [GNAP] User consent
Tom Jones <thomasclinganjones@gmail.com> Fri, 14 August 2020 16:39 UTC
Return-Path: <thomasclinganjones@gmail.com>
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 1E4113A0E4F for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 09:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 t29Oe1nhQzCQ for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 09:39:15 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 18AF53A0E3F for <txauth@ietf.org>; Fri, 14 Aug 2020 09:39:15 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id t7so8061091otp.0 for <txauth@ietf.org>; Fri, 14 Aug 2020 09:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=36mRrNSPnnXhNwmxeQxPA/s923RzireFi8FYpgp5RsI=; b=JsdQ3H0aXmPTdzdtxCtA1dpVnZ3y8Lct/1VmOsiPRY+vhCxgnIKu5ZTBBeZ5Klm4Qf qDsk+oT5vS4rOuUbaCzQR0pwvXXX0kEkn6LrDVWXg9TRSX+BCJKjvcl6HCe2x93H6d9v qd6pgsAZvpIhdqFUnuguC4kOxvMcCU4Jfqxj+gyha35X9A4FUaJ9IdCRobXcg+On3vwB l0vOgZHlT1MnRwYwczPdhvNlvYOpy1OA3WlwCCkF0L64dchFD1Wec0lHetjQZgSZpdb2 OG31WOc/wb/TuPhWDW6NxMLBiAtbo4Jz32lFA5/2SJ6hdiemz/12XOdr04JRP9rNhOUF VRow==
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=36mRrNSPnnXhNwmxeQxPA/s923RzireFi8FYpgp5RsI=; b=a24xwK0jMfzMCXl8LM7AnhnMrv7pIq7tqw32F3lryk3/mjv30IBU2ln6pOhUwacQ38 4W4szh3KpTT1B3xvfKJw5I3dveyJqw2kyKoEpoIibFqS+zuPyeGmMzcka+vNKIJM+NlN 5CjiNGkUrKSIAXZvOCV2xlVrDu3Zzsc4wKW57sJQsB3qWmjsZI5VLML6Qfbe5FK2nkkf iWFIrY6yCSXlm9bEGdcP47CDmliy4pqus0PgD7s/OyB2dK+Ka1BSdzNzI3/my+n7euPd mjDQsqIi/JPEUY0pF6NxT/21wUU0DUxaiYitZT9OKjpkfjlQYu1JJu6smJguVbkvlXFc n3Yg==
X-Gm-Message-State: AOAM530hzX5sJMhsvW9wlD2l7NSlQeN7T4ahCEcmzxVXhC631yymkL7X Iu72dOnbrdyJ8NoepMfRJdGH4AyTDTgi5WZLE6A=
X-Google-Smtp-Source: ABdhPJzWtPTzqZ9kkri+ejP33opmSMCgjku0xKEnIVuXSWyyjN8uNAWwalNz8fN0EJBgWf+Mt51PjbCONzREOBGaraA=
X-Received: by 2002:a9d:84c:: with SMTP id 70mr2425019oty.358.1597423154144; Fri, 14 Aug 2020 09:39:14 -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>
In-Reply-To: <CAOW4vyNu=BLC_fKSAU8Nk-oLHXfaU6pNCAc7nbAXXKiUZ=Fnvg@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Fri, 14 Aug 2020 09:39:02 -0700
Message-ID: <CAK2Cwb6Sf9Q_=hLmykGpi_3TqMyKFvNRcq-5rkRrU85D0hpRqw@mail.gmail.com>
To: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
Cc: Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a8abe105acd90f6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/NpI00p0l4jN3FPEn6BWTIo5ZNWU>
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:20 -0000
Here are some proposals that are working their way through other channels. 1. on consent grant.: https://wiki.idesg.org/wiki/index.php/Consent_Grant 2 on delegations: https://wiki.idesg.org/wiki/index.php/Delegation Comments are welcomed. Peace ..tom On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha <fpo= 40adorsys.de@dmarc.ietf.org> wrote: > 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<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..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/ >>>>> -- >>>>> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [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