Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
Dick Hardt <dick.hardt@gmail.com> Thu, 13 August 2020 18:17 UTC
Return-Path: <dick.hardt@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 2BBEB3A0FFA for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:17:08 -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=ham 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 hYWAOxHR6pUR for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:17:05 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B81893A1082 for <txauth@ietf.org>; Thu, 13 Aug 2020 11:16:52 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id k13so3543579lfo.0 for <txauth@ietf.org>; Thu, 13 Aug 2020 11:16:52 -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=qNiXbXZPZs7Y6G2RwVu0bjm2VzhApsxnEcrCkfbq22M=; b=lOe2UCKcByqL9JJj3QyT5SBRx0AePMY/fEtQFSnCogrFKNdZu7e561o6wqnj63uLGV trYYtSmpe4upoH2OnAyTOV3sdv9tldVDkc9iFZadi1Kjhb0Vun0d8NCExUogXr6e3IJy hq4aKjxK2MUSPqPY11z2gQAuj+ul7goHDhFxWaXg/X948cU1qkltkcC4if6hvPbhwAnG w1s8q9URmjYza4+8/utS3lzLpfmdubH8TBB3WaseXJncRRFF+OWZmVkLGDBNafalaSVq B+n0OkntDuYrLMxSxr1ph+QKyU9JBgf4hAYY8Nx+lCNwhpcq1MZdQ+aU4jC8W77v27Qm UBoQ==
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=qNiXbXZPZs7Y6G2RwVu0bjm2VzhApsxnEcrCkfbq22M=; b=AKMtIC4QQihtPjXGNT7ij8bbISfosakzrNTJpN/bl8T/rmj4IJLN/OB8a5OascQS71 QFTSSnVnCAh3VVzEPhdsjmi64jtxacYvDfVFB20qQ3v8mwBRG2UgvdosbAgwLXN9RqGc e5UflRxJ+DhHrN3FQdmQ0z/Xoq1L8HlpxlZelEZpyDWRhprAstOKLQU7gPHzPmH9m6Xa uM6UuG80C+jLDxBLY4/hJnQdnwRLkBiiVzIH/bX6bxfGJsT+TUDFPiAvP6SDmbcAmHiX U7nazpjb8cytJYbmczUXA8pQ6HHeHT2n0JmAmdT/ilrLx5FOnFni8+MmS3hCC/dMkSYu A+bA==
X-Gm-Message-State: AOAM531/Hn9wfeypHEyIExKFn/HGvMxYUCPoqE5oApMxKFxAHNkCHM5O Ch7XdaYubk5BYIk5Oab3skkWnJ/kG2uqWPOd7fM=
X-Google-Smtp-Source: ABdhPJxiJKR5X6iTzjjQw5quxnxyNMDUKaqaSzC9JPfHQ9fH2Jk188NB7lm2iYjOzZcRFrAqtoUxtR71HYmX32tMvWI=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr2779480lfp.23.1597342610648; Thu, 13 Aug 2020 11:16:50 -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>
In-Reply-To: <a3e44960-3e2f-03cf-08e7-412525443ff5@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 13 Aug 2020 11:16:14 -0700
Message-ID: <CAD9ie-v_YFufNmgfHSx0sr9kmMTjrOa--acic2UAg9LfpLNssQ@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e472a405acc64e90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9cCCZli7cPNTzfTz5-Hn3FRqe_0>
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 18:17:08 -0000
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. 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. ᐧ 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] 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