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

[Denis <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>