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

Tom Jones <> Mon, 03 August 2020 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFF5C3A0D50 for <>; Mon, 3 Aug 2020 14:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0WkYcM10m8KX for <>; Mon, 3 Aug 2020 14:16:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A04AC3A0C89 for <>; Mon, 3 Aug 2020 14:16:36 -0700 (PDT)
Received: by with SMTP id a9so7562165oof.12 for <>; Mon, 03 Aug 2020 14:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=glnorEcQL51DxjDfcT/k5NwoW+nU/m3AMKZLXsNYyq8=; b=uNs+SKFdECKJmhJqGcAbnm6yZpLXklh/G72RJSfZ65f6NVN5A2wZ7g1tD6+OuTIpd3 mfqqhwZZ83+GNR2Q+m9QU44RMu9UxK+qAR9Nx2zXo2gYMbHqU+21pIOcPO+AqujkWR8C 635OeUBeF6YqMj1Z8oMJmVGsEnbGzT9PniApHO1/40BO0kfRoNBdsGZmABhGJo6/Ojqa cizbYF4FCsj8MbjJuEYAHz6YRrbP5P4Vlw1TGvSXfb+j+zO4XE6utQ3k+Lvt4bo0RSuA t6doIJDKG8ZnopeIj1d8goYFhmp1HSgbQB3yqMkpNqkpHgHw5qxZcnOxg7L3qPqjPv8e u8iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=glnorEcQL51DxjDfcT/k5NwoW+nU/m3AMKZLXsNYyq8=; b=Kg2713M5QqL6XCpaca5gZNBoaudAxFeDWNF46w7uDDF1N4wBjJi2DxqVqz6L2jLNay BxnzRIyOfBbFcd0Yje2/+fb3s/M8F1JKvH2+VUKDBZALE1UhXlExi4/z1TKyYE+RolGv amKpCtGFsNgoAiud+H+5pgfQmL9Iz4X2NBwaZZYe2xeohysByK+kflt78A0FETNKDrc9 xjmU0V/G/uqdsLQc3TGfrVMnm4kvhu34os6bRRpPWcTviQN3nKfxe7NrmzPdcOwokboM /t9NNfn6NKdQVDK8P1i//Y1xkTpcFQJaFPNMZHWx0VtN5E/OmlVA4LM4pXh9rbPci+yi zsAQ==
X-Gm-Message-State: AOAM532nyVQS3VP4iFGKLVS/CCLYd09Iv2/7hVKu+nwEMFf7N7hWDbnR wBzG/Uc5dTZaZIxkPoDG5tO6GJUIx2SlrK8eP9M=
X-Google-Smtp-Source: ABdhPJzsLQj+0tVSj4+OvMh6HHjeaxVCwT87859+cfWi15/VpobYcLDtYspdA6vWxkjmLn+L/HRPwZSvQXgPxncdTXU=
X-Received: by 2002:a4a:3443:: with SMTP id n3mr16093766oof.30.1596489395512; Mon, 03 Aug 2020 14:16:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Jones <>
Date: Mon, 3 Aug 2020 14:16:24 -0700
Message-ID: <>
To: Justin Richer <>
Cc: Denis <>, "" <>, Dick Hardt <>
Content-Type: multipart/alternative; boundary="0000000000004ea9d705abffa78a"
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: Mon, 03 Aug 2020 21:16:39 -0000

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 <> 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 <> 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
> --
> Txauth mailing list