Subject: [GNAP] A "privacy by design" delegation scheme

From: Denis <[email-masked]>
Date: Fri, 19 Mar 2021 15:27:32 +0100

The text that follows is extracted from :

      * Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
      * Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021

           " 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)/."

These two sentences are part of the foundations of OAuth 2.0 and OAuth 2.1.

The same delegation scheme can be supported without the need to use an 
authorization server (AS). Here is the story:

            For example, an end-user can grant a printing service access 
to her protected photos stored at a photo sharing service, without 
sharing her username and password
            with the printing service.Instead, she authenticates 
directly to the photo sharing service and asks to that service to 
deliver delegation-specific credentials (access token)
            able to grant to its owner a read access to a subset of her 
photos during some period of time. Once the access token has been 
delivered by the photo sharing service,
            she transmits it to the printing service. Then the printing 
service presents that access token to the photo sharing service which 
will deliver the subset of selected photos
            to the printing service.

_Requirement_ :_
_
The end-user must have an account on the photo sharing service.

_Advantages_: ,

  * Since there is no AS, the photo sharing service does not need to
    trust any AS nor have a relationship with an AS.
  * Since there is no AS, the printing service does not need to trust
    any AS, nor have as relationship with an AS.
  * Since there is no AS, no account is needed for the end-user at an AS.
  * Since there is no AS, no AS can know/spy what the end-user is doing.
  * The access token can be transmitted/communicated to anybody,
    including herself.
  * The end-user MAY have an account on the printing service, but she is
    NOT REQUIRED to have one.
  * The person that gets the photos printed will need to disclose to the
    printing service a name and an address for the delivery
    (not necessarily her name and her home address) /if she is not
    working at a kiosk /and will need to pay for the printing (/and
    postage/).

Denis

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 10:31:05 -0400

Hi Denis,

The abstraction of the authorization server is fundamental to the approach in both OAuth and GNAP.

I would personally encourage you to start a BoF and eventually a working group here in the IETF to pursue such a design as you are proposing.

 — Justin

> On Mar 19, 2021, at 10:27 AM, Denis <[email-masked]> wrote:
> 
> Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
> Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021
>           " 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)."
> 
> The same delegation scheme can be supported without the need to use an authorization server (AS). Here is the story:
> 
>            For example, an end-user can grant a printing service access to her protected photos stored at a photo sharing service, without sharing her username and password 
>            with the printing service.  Instead, she authenticates directly to the photo sharing service and asks to that service to deliver delegation-specific credentials (access token) 
>            able to grant to its owner a read access to a subset of her photos during some period of time. Once the access token has been delivered by the photo sharing service, 
>            she transmits it to the printing service. Then the printing service presents that access token to the photo sharing service which will deliver the subset of selected photos 
>            to the printing service. 
> 
> Requirement :
> 
> Advantages: ,
> Since there is no AS, the photo sharing service does not need to trust any AS nor have a relationship with an AS.
> Since there is no AS, the printing service does not need to trust any AS, nor have as relationship with an AS.
> Since there is no AS, no account is needed for the end-user at an AS.
> Since there is no AS, no AS can know/spy what the end-user is doing.
> The access token can be transmitted/communicated to anybody, including herself.
> The end-user MAY have an account on the printing service, but she is NOT REQUIRED to have one.
> The person that gets the photos printed will need to disclose to the printing service a name and an address for the delivery 
> (not necessarily her name and her home address) if she is not working at a kiosk and will need to pay for the printing (and postage).
> Denis
> 
> 
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 10:37:47 -0400

Also, I want to point out that in your description below, the photo sharing service is the AS and the RS. It’s fulfilling both roles. This isn’t “without an AS” this is simply saying that one party runs both components in a closely-knit manner. 

 — Justin

> On Mar 19, 2021, at 10:31 AM, Justin Richer <[email-masked]> wrote:
> 
> Hi Denis,
> 
>> On Mar 19, 2021, at 10:27 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Stephen Moore <[email-masked]>
Date: Fri, 19 Mar 2021 10:40:26 -0400

Denis,
All you are doing in that case is putting the AS into the photosharing
service. The photo sharing service still has an AS that it
explicitly trusts because it owns it, but now I need to have multiple
accounts on every RS I have data on it, rather than giving me the option as
a user to entrust an AS run by a reputable company that can be trusted by
many RS's.
The delivery information can be input at the Photo Printing service with or
without an account on the service, regardless of where the token comes
from. I don't see how your last two bullets matter in differentiating the
two takes.

I honestly don't see a difference between the two other than one service
hosting the two components (RS and AS)
-steve

On Fri, Mar 19, 2021 at 10:27 AM Denis <[email-masked]> wrote:

>    - Page 5 from RFC 6749 (OAuth 2.0). October 2012, and
>    - Page 5 & 6 from draft-ietf-oauth-v2-1-01. February 2021
>
>           " 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),
> 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)*."
>
>            For example, an end-user can grant a printing service access to
> her protected photos stored at a photo sharing service, without sharing her
> username and password
>            with the printing service.  Instead, she authenticates
> directly to the photo sharing service and asks to that service to deliver
> delegation-specific credentials (access token)
> photos during some period of time. Once the access token has been delivered
> by the photo sharing service,
> service presents that access token to the photo sharing service which will
> deliver the subset of selected photos
>            to the printing service.
>
> *Requirement* :
>
> *Advantages*: ,
>    - Since there is no AS, the photo sharing service does not need to
>    - Since there is no AS, the printing service does not need to trust
>    - Since there is no AS, no account is needed for the end-user at an AS.
>    - Since there is no AS, no AS can know/spy what the end-user is doing.
>    - The access token can be transmitted/communicated to anybody,
>    including herself.
>    - The end-user MAY have an account on the printing service, but she is
>    - The person that gets the photos printed will need to disclose to the
>    (not necessarily her name and her home address) *if she is not working
>    at a kiosk *and will need to pay for the printing (*and postage*).
>
> Denis
>
> --
> TXAuth mailing list
> [email-masked]

---

From: Denis <[email-masked]>
Date: Fri, 19 Mar 2021 16:06:40 +0100

Hi Steve,

Thank you for your feedback.

You wrote: "now I need to have multiple accounts on every RS I have data 
on it". Yes indeed, but you know that there exists
or there will exist solutions for that, one of them being FIDO. With 
FIDO the RS cannot link their user accounts using the login name.
FIDO has been thought with privacy in mind.

About the last two bullets, I fear I don't understand your question.
The end-user may pick the photos at the delivery service or someone else 
can pick these photos.
An account is useful to avoid the retyping of a name and a home address 
each time, but is not necessary otherwise.

You finally wrote: "I honestly don't see a difference between the two 
other than one service hosting the two components (RS and AS)".

You only see the difference if you consider the trust relationships. In 
the general case, an AS is trusted by several RSs, but not in this 
situation.
If you rely on the HTTPS protection on both segments, then no 
cryptography is even necessary: there is no signature needed from anyone.

Denis

> accounts on every RS I have data on it, rather than giving me the 
> option as a user to entrust an AS run by a reputable company that can 
> be trusted by many RS's.
> The delivery information can be input at the Photo Printing service 
> with or without an account on the service, regardless of where the 
> token comes from. I don't see how your last two bullets matter in 
> differentiating the two takes.
>
> I honestly don't see a difference between the two other than one 
> service hosting the two components (RS and AS)
> -steve
>
> On Fri, Mar 19, 2021 at 10:27 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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)/."
>
>     The same delegation scheme can be supported without the need to
>     use an authorization server (AS). Here is the story:
>
>                For example, an end-user can grant a printing service
>     access to her protected photos stored at a photo sharing service,
>     without sharing her username and password
>                able to grant to its owner a read access to a subset of
>     her photos during some period of time. Once the access token has
>     been delivered by the photo sharing service,
>                she transmits it to the printing service. Then the
>     printing service presents that access token to the photo sharing
>     service which will deliver the subset of selected photos
>                to the printing service.
>
>     _Requirement_ :_
>     _
>       * Since there is no AS, the photo sharing service does not need
>         to trust any AS nor have a relationship with an AS.
>       * Since there is no AS, the printing service does not need to
>         trust any AS, nor have as relationship with an AS.
>       * The end-user MAY have an account on the printing service, but
>         she is NOT REQUIRED to have one.
>       * The person that gets the photos printed will need to disclose
>         to the printing service a name and an address for the delivery
>         working at a kiosk /and will need to pay for the printing
>         (/and postage/).
>
>     Denis
>
>     -- 
>     TXAuth mailing list
>     <https://www.ietf.org/mailman/listinfo/txauth>
>