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:28 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 8C07D3A0BE9 for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 02:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level:
X-Spam-Status: No, score=-0.734 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] 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 roNsobwwujFS for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 02:28:07 -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 695413A0CA7 for <txauth@ietf.org>; Tue, 4 Aug 2020 02:28:06 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d64 with ME id BMU4230042bcEcA03MU4Yv; Tue, 04 Aug 2020 11:28:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 04 Aug 2020 11:28:04 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
References: <c5f40413-93b8-2e8c-0a3e-14a07cd27ad0@free.fr> <CAD9ie-t_gacW_sOVqEqb4vq2uNa3pNQ4Fg4qDrXdk8m+5UZphA@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr>
Date: Tue, 4 Aug 2020 11:28:03 +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: <CAD9ie-t_gacW_sOVqEqb4vq2uNa3pNQ4Fg4qDrXdk8m+5UZphA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D261EB99C977F2A555DF457E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/OH6ymASWSQ8Mud6HhQHdzpUIeHU>
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:28:10 -0000

Hi Dick,

> Hi Denis
>
> In your proposed flow, how does RS2 know who the user is that it is 
> dealing with?

The response is in the text: "The Client connects to the printing 
service (RS2) and the User authenticates to the printing service (RS2)".

> In OAuth, the AS authenticates the User for the RS. In the photo 
> sharing example, the AS and RS are from the same organization, so the 
> AS knowing what the RS was doing was not an issue.

Nevertheless, a full description is still missing and might help to 
better understand the privacy issues.

> What you call a Client is not an OAuth Client, but is more of an agent 
> for the User.

RFC 6749 states:

    In OAuth, the client requests access to resources controlled by the
    resource owner and hosted by the resource server,
    and is issued a different set of credentials than those of the
    resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

    client
           An application making protected resource requests on behalf
    of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but I clearly like better 
the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

> Microsoft InfoCards comes to mind as a comparable architecture, and it 
> seems aligned with what Tom is asking for.
>
>
>
>
>
> On Mon, Aug 3, 2020 at 12: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
>