[Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
Denis <denis.ietf@free.fr> Mon, 03 August 2020 07:35 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 CB0713A0C31 for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 00:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.212
X-Spam-Level: **
X-Spam-Status: No, score=2.212 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no 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 QUzAmeItuOCD for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 00:35:57 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E253A0C30 for <txauth@ietf.org>; Mon, 3 Aug 2020 00:35:56 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d08 with ME id Avbt2300D2bcEcA03vbuBS; Mon, 03 Aug 2020 09:35:55 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 03 Aug 2020 09:35:55 +0200
X-ME-IP: 90.79.51.120
From: Denis <denis.ietf@free.fr>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Message-ID: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr>
Date: Mon, 03 Aug 2020 09:35:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------B8761C8CAC6FB90B6037B4A9"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/hXw2yclJJKIghetP5shHsAH0cho>
Subject: [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: Mon, 03 Aug 2020 07:36:00 -0000
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] 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