Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Denis <> Tue, 04 August 2020 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 331563A0CA7 for <>; Tue, 4 Aug 2020 02:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.733
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2SF0fKvXN9Zm for <>; Tue, 4 Aug 2020 02:31:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C9D33A0C13 for <>; Tue, 4 Aug 2020 02:31:36 -0700 (PDT)
Received: from [] ([]) by mwinf5d64 with ME id BMXa2300A2bcEcA03MXbHc; Tue, 04 Aug 2020 11:31:35 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 04 Aug 2020 11:31:35 +0200
To: Justin Richer <>
Cc: "" <>
References: <> <>
From: Denis <>
Message-ID: <>
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: <>
Content-Type: multipart/alternative; boundary="------------6617F29754A354476A9FF77E"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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)


>  — Justin
>> On Aug 3, 2020, at 3:35 AM, Denis < 
>> <>> 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
>> <>