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 15:29 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 DBF263A0D4D for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 08:29:24 -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 HHT6IcsgjpBN for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 08:29:20 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 51FDA3A0DAA for <txauth@ietf.org>; Thu, 13 Aug 2020 08:29:18 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id v15so3243963lfg.6 for <txauth@ietf.org>; Thu, 13 Aug 2020 08:29:18 -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=jw/PzH2Ksjc9UjEHaIqHnwyq46uopEuo1RaX4V/592c=; b=bAp9/rZtM2s4JVW6NLt0x5Evjc1lYqRU6vvwlNK5rUeL1FbPCTmatqGtn8hY6m8zti kMKXDst0+4lkowHrh0CvfVQ/i/+xBAuwsNVFWfNzsj/DLcuKzn/TAImtyMwXiHMdAQaE SYsKZYltXT++ZLT2vpLuRsbxqL/rVl+QHbK23ikoy+Z42HlorGRA+Nmh0vb05wgB6sfM iFXgM82flCROW/y67Etk4bmcgxfYRFNkK1ZFWBGTYABkNSusUAIap7PIYY+PIoY/Wxav OHNAvao7x3tCXIyMoNAR6BordO57jChiUfdUxFpthOAY0wPOIkQJD6TkZn3ZvSjxE09i vV5g==
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=jw/PzH2Ksjc9UjEHaIqHnwyq46uopEuo1RaX4V/592c=; b=KjirdplY2BVg2BPwG8dZxlU5tSG8Azy/OvfNbPD1i7QReLuTeUYeM2Z6/vqVGUgSOk ua/ltn4J1An2qEVV3crcGnXbpz9wp27+GKJYFLQQj6BDnagm9bXnnH+JbEADRvLzznqX 9yw4vbpj17K5cMsX3utRkhsj0wb7kkzg+YuYc/K/BCDYYwVleJiRJELKeRvj+WsIKe0/ yH9pr4jeRXvaOKEPlIsCWUe2Zl8RmaBuouytGCgSRnKbmXmTk54CRvU9FwOMiitIbP17 QvqLQ0BMGHWiJ4FS/BDW0B1+aL2sNBX/hk2k0jIdRjNRD5nELa3tv6arjxFAGaR7HCcK 7xQw==
X-Gm-Message-State: AOAM5324D7VGbT5bm0ZQtpXALe1sBGjvqqAMo6qU4s+hDbyNDJYhj272 zffSoPQljKETgVfeGQtDD/SGLn/xdOd0uziw+kB3TpN4
X-Google-Smtp-Source: ABdhPJx+Nrfzo+7sls3ktPy+6uHU+0W+4kFC793BG7954FvWdZaXt8HejERVwDdkU/lw26/3M/n1wKBo/+mm+qSIKWs=
X-Received: by 2002:a19:8044:: with SMTP id b65mr2468328lfd.91.1597332555742; Thu, 13 Aug 2020 08:29:15 -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> <CAOW4vyOrXstAvc3eKbsUh+gOPT-79nevR8nT5FyKTe+aAQ1pSw@mail.gmail.com> <CAD9ie-sZbxBKuLgC3Bu+yzJATOETdto=S83B6FOmC3gFJWz1jw@mail.gmail.com> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <CAD9ie-s5_tOZhE57tj1b+XaqDw+D43n_wStOPSmi7cioG2Z+gw@mail.gmail.com> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <CAD9ie-vhnePQ0_GNEYWiRWbhPGyivrWNfN9VPnnL=wt3mB+aXg@mail.gmail.com> <b5d6c85a-2741-9a30-65d7-837e7a3ec115@free.fr>
In-Reply-To: <b5d6c85a-2741-9a30-65d7-837e7a3ec115@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 13 Aug 2020 08:28:38 -0700
Message-ID: <CAD9ie-utO56ArFkdQWDURUfKBZpJjq3AdjrKuV6xjFf8qJpe=Q@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Francis Pouatcha <fpo@adorsys.de>, Benjamin Kaduk <kaduk@mit.edu>, Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092c0b905acc3f72d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/pCEz3HPHPb2OkeIPxqvXds8cWec>
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 15:29:25 -0000
Hi Denis, we were discussing if a developer needs to read docs to use an API. If you want to introduce a new topic, would you start a new thread? ᐧ On Thu, Aug 13, 2020 at 7:04 AM Denis <denis.ietf@free.fr> wrote: > Dick, > > A web browser is not a person. > > Denis > > PS1. You didn't reply to the second point of my email about a "consent" > endpoint at the RS. > > PS2. It would be better that you wait until you can use a real laptop to > respond and that you re-use the original message, > because the message you sent back is almost unreadable. > > The Client is not a person, it is software created by a developer. The > developer of the client is going to read the documentation for the RS to > program the Client. > > On Thu, Aug 13, 2020 at 6:47 AM Denis <denis.ietf@free.fr> wrote: > >> >> >> >> >> >> >> >> >> >> >> Dick, >> >> >> >> >> >> >> >> I first jump on the >> >> following exchanges: >> >> >> >> >> >> >> [Dick] Most deployments today accomplish >> >> (2) by the developer reading RS documentation. I'm in favor >> >> of showing that step in an abstract diagram. >> >> >> [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag >> >> förstår inte svenska. Jeg forstår ikke norsk. >> >> >> One of the goals is for any Client to access any >> >> RS without the need to read any documentation. >> >> >> [Dick]That is >> >> impractical. Most RSes today have resource specific APIs. >> >> The Client is either reading a standard API doc, or the >> >> resource specific API doc. >> >> >> >> >> >> >> >> >> I am not so sure >> >> that it is impractical. >> >> >> >> >> >> >> >> In 2012, Geert >> >> Jansen considered the possibility for complete auto-discovery >> >> by the API user, so that the API can be used by a human with a >> >> web browser, >> >> >> without any reference to external documentation. See the "Form >> >> Definition Language" in : >> >> https://restful-api-design.readthedocs.io/en/latest/forms.html >> >> >> >> >> >> >> >> >> In his view, forms >> >> need to specify three pieces of information: >> >> >> >> >> 1. How to contact the target >> >> and format the input. >> >> >> 2. A list of all available input fields. >> >> >> 3. A list of constraints with which the input fields must >> >> comply. >> >> >> >> >> Hence, >> >> in his view, the >> >> form consists of 3 parts: form metadata, field definitions, >> >> and constraints. >> >> >> >> >> >> >> >> What do you think ? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The second point on >> >> which I would like to insist is about the use of a "dialog >> >> box" for user interaction. This wording is used in RFC 6973. >> >> >> >> >> >> >> >> In OAuth 2.0, the user >> >> consent is performed by the AS using an authorize endpoint >> >> where the user consent is solicited and captured. >> >> >> >> >> >> >> >> Since a user, with no >> >> prior experience, shall first connect to a RS to perform an >> >> operation, the user consent >> >> shall be performed by the RS, >> >> >> instead of the >> >> AS. This means that we >> >> should define a "consent" endpoint at the RS. >> >> >> >> >> >> >> >> Denis >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> comments inline ... >> >> >> >> >> >> >> >> On Wed, Aug 12, 2020 at 7:14 >> >> AM Denis <denis.ietf@free.fr> wrote: >> >> >> >> >> >>> >>> >>> >>> Hi Dick, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Francis, responses inline ... >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 11, >>> >>> 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> >>> >>> wrote: >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> Hello Dick, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug >>>> >>>> 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> "Requestor" is the role (*was* >>>> >>>> User). So the UML participant refers to the >>>> >>>> role "Requestor" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> I still don't understand what is happening in >>> >>> (1) and (7) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> Would you provide more explanation? >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I also think that (2) could be an >>>>> >>>>> extension to GNAP, rather than part of >>>>> >>>>> the core protocol. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> If you make it an extension, you hide. It >>>> >>>> shall rather be an optional, integral part >>>> >>>> of the protocol. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Most deployments today accomplish (2) by the >>> >>> developer reading RS documentation. I'm in favor >>> >>> of showing that step in an abstract diagram. >>> >>> >>> >>> >>> >>> >>> >>> >>> [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag >>> förstår inte svenska. Jeg >>> >>> forstår ikke norsk. >>> >>> >>> One of the goals is for any >>> >>> Client to access any RS without the need >>> >>> to read any documentation. >>> >>> >>> >>> >>> >> >> >> >> >> >> >> That is impractical. Most RSes today have resource >> >> specific APIs. The Client is either reading a standard API >> >> doc, or the resource specific API doc. >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> But it is not clear to me what the requirements >>> >>> for (2), and they may vary radically across use >>> >>> cases, so putting it in the core document seems to >>> >>> be getting ahead of ourselves. >>> >>> >>> >>> >>> >>> >>> >>> >>> [Denis] I can >>> >>> only reinsist on earlier explanations given about >>> >>> the Client-server use cases built along "Privacy by >>> >>> Design" since they are fundamental. >>> >>> >>> >>> >>> >> >> I agree with the principle of "Privacy by Design". There >> >> are LOTS of details in how to do what you outline below, and >> >> I expect they will be radically different across use cases, >> >> which is why I don't think it fits into the core document, >> >> but I do agree with calling it out in the abstract. When I >> >> publish an updated draft, let me know what you think then. >> >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Taking into >>> >>> consideration both the "data minimization" >>> >>> principle and the "user participation" principle >>> >>> when a user first authenticates to a RS leads to >>> >>> the following: >>> >>> >>> >>> >>> >>> >>> >>> >>> 1) When >>> >>> accessing a RS for the first time, the user should >>> >>> be informed of the authentication means proposed >>> >>> by the RS. The user should be able to use a dialog >>> >>> box >>> >>> >>> where some choices are presented by the RS. The >>> >>> user should be able to locally make his own >>> >>> choices and to indicate his consent to its Client. >>> >>> >>> 2) When a user chooses to perform one >>> >>> operation on a RS, the RS should limit the data to >>> >>> be collected from the user to only what is >>> >>> strictly necessary >>> >>> >>> to perform that operation. That data consists of >>> >>> specific types of attributes that need to be >>> >>> guaranteed by one or more ASs. The user should be >>> >>> able >>> >>> >>> to use a dialog box where some ASs choices are >>> >>> proposed by the RS. The user should be able to >>> >>> locally make his own choices and to indicate >>> >>> >>> his consent to its Client. >>> >>> >>> >>> >>> >>> >>> >>> >>> It is >>> >>> important to notice that the choices that will be >>> >>> proposed to a user may depend upon previous >>> >>> personal information voluntarily released by that >>> >>> user. >>> >>> >>> This means >>> >>> that the choices proposed by the RS may be >>> >>> tailored for the user. Furthermore, the proposed >>> >>> choices may only be disclosed to already >>> >>> authenticated users. >>> >>> >>> >>> >>> Denis >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> In some open banking designs, >>>> >>>> >>>> - the "Orchestrator/Negotiator/Client" >>>> >>>> will not know the AS to talk to unless the >>>> >>>> call (2). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Have you put these use cases in the wiki? >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> - the request (2) might result in an >>>> >>>> exemption, meaning no need for further >>>> >>>> authorization, allowing to skip (3, 4, 5) >>>> >>>> and even (6). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Agreed. >>> >>> >>> >>> >>> >>> >>> >>> >>> ᐧ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> ᐧ >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> 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