Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
Denis <denis.ietf@free.fr> Tue, 04 August 2020 09:31 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 331563A0CA7
for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 02:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level:
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5
tests=[FREEMAIL_FROM=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 2SF0fKvXN9Zm for <txauth@ietfa.amsl.com>;
Tue, 4 Aug 2020 02:31:37 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr
[80.12.242.128])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 0C9D33A0C13
for <txauth@ietf.org>; Tue, 4 Aug 2020 02:31:36 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d64 with ME
id BMXa2300A2bcEcA03MXbHc; Tue, 04 Aug 2020 11:31:35 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 04 Aug 2020 11:31:35 +0200
X-ME-IP: 90.79.51.120
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr>
<ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr>
Date: Tue, 4 Aug 2020 11:31:34 +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: <ECF217AE-1D67-4EAE-AE51-531F6EE6E222@mit.edu>
Content-Type: multipart/alternative;
boundary="------------6617F29754A354476A9FF77E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/wtBLUYLSpyLZoLliqRelE7pLbBg>
Subject: Re: [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: Tue, 04 Aug 2020 09:31:40 -0000
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. > This could mean splitting up things into multiple roles, or defining > new roles for aspects that weren’t in consideration in the protocol > previously. > Perhaps what you’re calling a client below could potentially be > considered the “interaction component” or “consent gatherer”, which > was previously a portion of the AS. > > I’ve never been a fan of the term “client” in OAuth because it’s too > generic and confusing to a lot of developers, especially the web > programmers that OAuth is aimed at. If the term “client” in OAuth should be understood as defined in in section 1.1 (Roles) from RFC 6749, i.e.: client : An application making protected resource requests on behalf of the resource owner and with its authorization. then this term is clearly not compatible with the term client from the Client-Server model. > “User Agent” would be similarly unsuitable for the same reasons — both > “client” and “user agent” are taken to mean “browser” in many circles. Maybe, but it is not my understanding. > I’d love for us to come up with a new term for this, but apart from > the “Resource Client (RC)” that I proposed in the XYZ Draft, I don’t > have an answer. By best answer is to use the term Client for what it means in the context of a Client-Server model. Hereafter are two ISO definitions: client : entity that requests a service from a server (ISO/IEC 14776-414:2009, 3.1.16) client application: software application that accesses a remote service usually on another computer system (ISO 24619:2011, 3.3.5) Denis > > — Justin > >> On Aug 3, 2020, at 3:35 AM, Denis <denis.ietf@free.fr >> <mailto:denis.ietf@free.fr>> wrote: >> >> Hello Dick, >> >> >> This is a follow-up of the thread: "Reviewing >> draft-hardt-xauth-protocol-11". >> >> Hereafter are three exchanges between you and me which triggered this >> new thread: >> >> [Dick] The photo sharing example was a driving use case for >> the creation of OAuth. >> [Denis] We would need to revisit the original scenario and >> consider if it can be addressed in a different way than the >> original way. >> [Dick] The use case is the same. Is there a different solution >> you are proposing ? >> >> My response is : Yes indeed, I have a different solution to address >> the same use case. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >> >> For example, an end-user (resource owner) can grant a printing >> service (client) access to her protected photos stored at >> a photo-sharing service (resource server), without sharing her >> username and password with the printing service. Instead, >> she authenticates directly with a server trusted by the >> photo-sharing service (authorization server), which issues the >> printing >> service delegation-specific credentials (access token). >> >> There are no further explanations. >> >> Which information will be disclosed by the resource owner to the >> authorization server to get "the printing service delegation-specific >> credentials" >> is not described. It is a private agreement between the AS and the >> RS. It is more than likely that the authorization server will learn >> information >> about which operation the resource owner is wishing to perform and >> where. Since in OAuth, the access token is supposed to be opaque to >> the Client, >> the user will be unable to make sure that her instructions have been >> carefully followed. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they >> do not contain a "Privacy Considerations" section. >> Thus, the leakage of information to the AS is not discussed. >> >> It is possible to revisit the original scenario by applying "Privacy >> by design" principles. >> >> The scenario can be solved by using an old data transfer method that >> has been first described 32 years ago under the name >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years >> later in ISO/IEC 10740-2:1993. >> >> RDT allows two servers to directly exchange large amounts of data >> under the supervision of a client by communicating, through the client, >> a reference generated by one server to the other server. RDT does not >> use any Authorization Server (AS). This means that no AS is able >> to act as Big Brother and this solves a major privacy concern. >> * >> The three entities involved >> * >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1. >> The Printing service (was the client): RS2. >> * >> * >> >> *Flow of operations with the Photo-sharing service (RS1) >> >> *The Client first connects to the photo-sharing service (RS1) and the >> User authenticates to the photo-sharing service (RS1). >> >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party printing >> service". >> >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >> >> RS 1 User consent: "Do you agree RS1 to communicate your selection of >> pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference to be >> used by your printing service to get the selected pictures". >> * >> Flow of operations with the Printing service* (*RS2) >> * >> The Client connects to the printing service (RS2) and the User >> authenticates to the printing service (RS2). >> >> _Note_: This allows to make sure that the user has an account on RS2 >> so that further operations can be charged to this account >> and that the prints can be sent to a known address. >> >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a photo-sharing >> service ". >> RS2 to User: "Please indicate your photo-sharing service". >> The User responds: RS1. >> >> "Please enter the reference to be used by RS2 to receive the set of >> pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >> >> RS2 contacts RS1 using that reference in order to get the >> characteristics and the thumbnails of the pictures to be printed >> (i.e. not yet the whole pictures). >> >> RS2 to client: What are your printing preferences for each picture >> (e.g. number of prints, size, quality of the paper, resolution, >> margins, colours, etc... ) ? >> The User responds to all these questions. >> >> RS 2 User consent: This operation will be charged XX € ? Do you agree ? >> If the payment needs to be done on-line, then a payment phase is >> inserted. >> * >> Continuation of the flow of operations >> >> *Final message from RS1 to the Client: "Your selection of pictures >> will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be soon on >> their way". >> >> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding >> to this reference. >> * >> Some of the advantages of RDT* >> >> 1. An end-user can grant a printing service (RS2) access to her >> protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the printing service. >> 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves >> the Big Brother privacy issue. >> 3. Any authentication method supported by RS1 or RS2 can be used by >> the User. >> 4. The User can use any photo-sharing service (RS1) with any >> printing service (RS2), as long as they both support RDT. >> 5. The User consent is first performed with the photo-sharing >> service (RS1) and then after with the printing service (RS2). >> 6. The reference generated by RS1 will only be accepted by RS1 >> during a time period. >> 7. The reference generated by RS1 allows RS2 to query first the >> thumbnails and then after the pictures selected by the User at RS1. >> 8. The data transfer of the pictures selected at RS1 by the User is >> performed asynchronously from RS1 to RS2 as a back-office operation. >> >> *Questions*: What would be the full scenario of this use case using >> OAuth ? What about Privacy Considerations ? >> >> Denis >> >> -- >> 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