Re: [GNAP] Terminology
Denis <denis.ietf@free.fr> Tue, 11 August 2020 17:25 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 BD7183A084C for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 10:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 TyY5iOBN2zVS for <txauth@ietfa.amsl.com>; Tue, 11 Aug 2020 10:25:12 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3477B3A0847 for <txauth@ietf.org>; Tue, 11 Aug 2020 10:25:11 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d06 with ME id EHR42300A2bcEcA03HR5eB; Tue, 11 Aug 2020 19:25:09 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 11 Aug 2020 19:25:09 +0200
X-ME-IP: 90.79.51.120
To: Mike Jones <Michael.Jones@microsoft.com>, Tom Jones <thomasclinganjones@gmail.com>, Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Fabien Imbault <fabien.imbault@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
References: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <63a40d80-e7b3-4016-d92c-f1889fe62dfe@free.fr>
Date: Tue, 11 Aug 2020 19:25:02 +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: <DM6PR00MB0684496FAFF843EF4286B0ECF5451@DM6PR00MB0684.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------169998FF4A838E80D85F2C33"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fYBWGnAbXHXnuqbiWzber9B_5Mo>
Subject: Re: [GNAP] Terminology
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: Tue, 11 Aug 2020 17:25:16 -0000
To all, We are circling around. In order to progress about the terminology, I propose the following: 1° Adopt the ISO rule for a definition: The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop. A definition shall not take the form of, or contain, a requirement. 2° Propose at the same time a term AND its definition. 3° If you don't like a term or its definition proposed by someone else, this is fine ... but only as long as you have a counter proposal for either the term and/or its definition. As an example, only stating that " "client" can be confusing" would not be a valid proposal. Terms and definitions are used in the context of RFCs issued by a WG and it is fine using terms already used by other RFCs issued by another WG as long as we clearly define them. Denis > One of the things that people hated about OAuth was it invented new > terminology that wasn’t in common use. But for better or for worse, > the terms Client, Authorization Server, and Protected Resource are now > widely understood. > > Let’s not make people similarly hate GNAP by inventing even more novel > terms, when existing terms will fit the bill. Client wasn’t a perfect > choice but adding “Orchestrator” to the vocabulary menagerie would > definitely make things worse. > > -- Mike > > *From:* TXAuth <txauth-bounces@ietf.org> *On Behalf Of *Tom Jones > *Sent:* Tuesday, August 11, 2020 8:44 AM > *To:* Dave Tonge <dave.tonge@moneyhub.com> > *Cc:* Francis Pouatcha <fpo@adorsys.de>; Justin Richer > <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk > <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis > <denis.ietf@free.fr>; txauth@ietf.org > *Subject:* Re: [GNAP] Terminology > > the term "orchestator" does not match any use case i have. > > Let's be clear that there are four entities to a single transaction in > the real world sense of things. (and others that support the > transaction.) > > Then we can focus on the end point roles. I will focus on the data > privacy issues, API's have the same parties with different terminology. > > 1. the subject of the data to be transferred. > > 2. the user of a grant from the subject to act as delegate. (see > https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the > user) > > 3. the site that has a repository of user data with legal obligations > to protect that data (the GDPR) (role resource server.) > > 4 the site that wants either access to the data, or some privacy > preserving statement about the existence and content of the data. > (role of client, vendor, PISP, etc.) > > 5. some sorts of facilitator sites for allowing access (roles like > authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been > left out of OAUTH for good reason. > > This is a note supporting the separation of roles from legal > entities. BTW, I firmly believe that the legal entity also needs to > be ID'd by the transaction. > > Peace ..tom > > On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com > <mailto:dave.tonge@moneyhub.com>> wrote: > > Hi all > > I agree that "client" can be confusing. I would be in support of > alternative terminology. > > We can always have some wording that explains that an > "Orchestrator" in GNAP plays a similar role to "Client" in OAuth. > > Dave > > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote: > > Hi Francis, > > I like your proposal, seems much more intuitive. > > Fabien > > Le mar. 11 août 2020 à 04:17, Francis Pouatcha <fpo@adorsys.de > <mailto:fpo@adorsys.de>> a écrit : > > Hello Denis, Justin, Dick, Fabien, > > In this post > (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) > i suggested we use the word "Orchestrator" to designate > the piece of software that orchestrate interaction between > "Requestor" (a.k.a. User), AS and RS to obtain the > protected resource. > > We are turning around the same topic. As soon as we go > beyond the original oAuth protocol, the word 'Client' > becomes confusing. > > In the same response, I suggest we talk about "roles" and > not "entities". > > Best regards. > > /Francis > > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote: > > I still think that client was the right name in OAuth > 2, as the client wanted to do a client-server > interaction, so the client used OAuth 2 to get an > access token to interact with the "server". > > I do agree that it is not the best term in GNAP. > Primarily because GNAP is a combination of the client > from OAuth 2, and the relying party from OIDC. > > /Dick > > ᐧ > > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: > > On Aug 6, 2020, at 12:53 PM, Dick Hardt > <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>> wrote: > > The term client in OAuth came from the > computer science definition of client-server > interaction. > > This, I would argue, is exactly why it’s a bad > label for something that’s distinctly more > specific in this context, and I would love to see > GNAP adopt a more specific label for the role that > we traditionally called “client” in OAuth. > > — Justin > > > > The client is getting an access token so it > can call a server, specifically, a resource > server (to differentiate it from the > authorization server). > > The confusion in my experience usually stems > from people working with software that is > acting in multiple roles. IE, the > software that is acting as a client in once > context, is also acting as an RS in other > contexts, or even acting as an AS. The other > confusion is that people view clients as being > the software the user is using -- although it > may not be acting as a client in the oauth > context. > > ᐧ > > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault > <fabien.imbault@gmail.com > <mailto:fabien.imbault@gmail.com>> wrote: > > Hi, > > To me, client has always been a strange > word in the context of OAuth, as it has a > meaning well defined both in everyday life > (this client is a good customer) and in > computer science (client-server > interaction). Thus I always have to make > the mental translation to the OAuth world > before any discussion... And any teaching > experience shows that it does make the > concepts hard to grasp for a majority of > (clever) people. > > As for the RO, previous discussions > suggested Resource Controller (RC) also, > which may be a bit more specific than > manager. > > Fabien > > On Thu, Aug 6, 2020 at 1:00 PM Denis > <denis.ietf@free.fr > <mailto:denis.ietf@free.fr>> wrote: > > Justin and Dick, > > [Was: "Revisiting the photo sharing > example (a driving use case for the > creation of OAuth)"] > > So let us attempt to define new terms: > > *initiating application (IA)*: > application by means of which a > user initiates interactions with > RS(s) and AS(s) > > In the same way, we should get rid of > the term Resource Owner (RO), which is > currently defined as: > > Resource Owner (RO): entity > capable of granting access to a > protected resource > > I propose to replace it with Resource > Manager (RM): > > *Resource Manager (RM)*: > application or user that manages > an access decision function of a > Resource Server > > Denis > > 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 > > -- > 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 <mailto:TXAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/txauth > > *Moneyhub Enterprise is a trading style of Moneyhub Financial > Technology Limited which is authorised and regulated by the > Financial Conduct Authority ("FCA"). Moneyhub Financial Technology > is entered on the Financial Services Register (FRN 809360) at > https://register.fca.org.uk/ <https://register.fca.org.uk/>. > Moneyhub Financial Technology is registered in England & Wales, > company registration number 06909772. Moneyhub Financial > Technology Limited 2020 © Moneyhub Enterprise, Regus Building, > Temple Quay, 1 Friary, Bristol, BS1 6EA. * > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this > email or of any information in it other than by the addressee is > unauthorised and unlawful. Whilst reasonable efforts are made to > ensure that any attachments are virus-free, it is the recipient's > sole responsibility to scan all attachments for viruses. All calls > and emails to and from this company may be monitored and recorded > for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those > of the author and do not necessarily represent the opinions of > Moneyhub Financial Technology Limited or of any other group company.** > > > -- > TXAuth mailing list > TXAuth@ietf.org <mailto: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