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

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 <jricher@mit.edu> wrote:
> 
> 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 <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> 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
>> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth
> 
> -- 
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth