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

[Dick Hardt <[e-mail]>]

+1 to Client and RS being the roles they are playing in the protocol.
ᐧ

On Tue, Aug 4, 2020 at 8:51 AM Justin Richer <[e-mail]> wrote:

> That’s exactly why “client” and “RS” need to be thought of as a “role” and
> not an “entity”. An entity can have several roles, and they’re all about
> context.
>
> The “client” role is always the “client” regardless of whether the entity
> being the “client” can also be an “RS” in another context milliseconds
> later.
>
>  — Justin
>
> On Aug 3, 2020, at 5:16 PM, Tom Jones <[e-mail]>
> wrote:
>
> In our use cases the client and rs are indistinguishable other than one is
> a source and the other a sink of data. They can reverse roles rapidly. I
> agree that client is not a helpful name.
> Peace ..tom
>
>
> On Mon, Aug 3, 2020 at 12:02 PM Justin Richer <[e-mail]> wrote:
>
>> 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. 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. “User Agent” would be similarly
>> unsuitable for the same reasons — both “client” and “user agent” are taken
>> to mean “browser” in many circles. 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.
>>
>>  — Justin
>>
>> On Aug 3, 2020, at 3:35 AM, Denis <[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]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>