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

[Stephen Moore <[e-mail]>]

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 <[e-mail]> wrote:

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