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

[Denis <[e-mail]>]

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

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