Re: [OAUTH-WG] RAR WGLC comment

2021-06-25 Thread Justin Richer 
I agree with this change, but with one caveat (already expressed in the PR) 
that an AS should be aware that clients can now send scope, resource, and 
authorization_details parameters together on a single request. It’s not up to 
RAR to define how all of those fit together, but an AS implementing RAR is 
going to need to know that it’s going to have to deal with this potentially 
unwieldy mix. 

 — Justin

> On Jun 20, 2021, at 6:54 AM, Torsten Lodderstedt 
>  wrote:
> 
> Hi all,
> 
> I created a PR for this change. 
> 
> https://github.com/oauthstuff/draft-oauth-rar/pull/76 
> 
> 
> Please review and comment/approve. 
> 
> best regards,
> Torsten. 
> 
>> Am 19.06.2021 um 17:01 schrieb Filip Skokan > >:
>> 
>> I support such change.
>> 
>> Odesláno z iPhonu
>> 
>>> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
>>> >> >:
>>> 
>>> 
>>> Hi Brian,
>>> 
>>> the idea was to use resource indicators as convenient short cut to support 
>>> audience restricted access tokens. However, I agree this can be achieved by 
>>> specifying authorization details in the token request as well.
>>> 
>>> So I‘m fine with dropping resource indicators for RAR at all. This means 
>>> RAR on one hand and scopes + resource indicators on the other hand are 
>>> clearly decoupled and independent.
>>> 
>>> best regards,
>>> Torsten.
>>> 
 Am 18.06.2021 um 20:13 schrieb Brian Campbell 
 >>> >:
 
 
 In my reading and understanding of the text and intent, the content and 
 meaning of a particular authorization details object are fully governed by 
 its "type". And while the draft provides a set of common data elements 
 intended to be usable across different types (locations, actions, 
 datatypes, identifier, privileges) a specific type is free to define 
 whatever suits its needs. A type definition may or may not involve those 
 common elements and could even use the same name(s) with different meaning 
 or structure. 
 
 So, while I understand the motivation behind the RFC8707 resource 
 parameter being usable in a token request to make the AS filter, the 
 included authorization details of the resultant token based on the 
 "locations" element[1], I'm a bit concerned about a layering problem here. 
 The authorization details objects of the grant might not contain a 
 "locations" element or might have one with a different meaning or 
 structure.  
 
 The draft also describes using the authorization_details token request 
 parameter to specify the authorization details a client wants the AS to 
 assign to a particular access token[2]. So the problematic resource 
 parameter behaviour is also kind of redundant. I think maybe it should be 
 removed.
 
 [*] described in 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 
 
  and mentioned at 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 
 
  and in 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 
 
 
 [2] 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
  
 
 CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
 material for the sole use of the intended recipient(s). Any review, use, 
 distribution or disclosure by others is strictly prohibited.  If you have 
 received this communication in error, please notify the sender immediately 
 by e-mail and delete the message and any file attachments from your 
 computer. Thank you.___
 OAuth mailing list

Re: [OAUTH-WG] RAR WGLC comment

2021-06-20 Thread Torsten Lodderstedt 
Hi all,

I created a PR for this change. 

https://github.com/oauthstuff/draft-oauth-rar/pull/76 


Please review and comment/approve. 

best regards,
Torsten. 

> Am 19.06.2021 um 17:01 schrieb Filip Skokan :
> 
> I support such change.
> 
> Odesláno z iPhonu
> 
>> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
>> :
>> 
>> 
>> Hi Brian,
>> 
>> the idea was to use resource indicators as convenient short cut to support 
>> audience restricted access tokens. However, I agree this can be achieved by 
>> specifying authorization details in the token request as well.
>> 
>> So I‘m fine with dropping resource indicators for RAR at all. This means RAR 
>> on one hand and scopes + resource indicators on the other hand are clearly 
>> decoupled and independent.
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
>>> :
>>> 
>>> 
>>> In my reading and understanding of the text and intent, the content and 
>>> meaning of a particular authorization details object are fully governed by 
>>> its "type". And while the draft provides a set of common data elements 
>>> intended to be usable across different types (locations, actions, 
>>> datatypes, identifier, privileges) a specific type is free to define 
>>> whatever suits its needs. A type definition may or may not involve those 
>>> common elements and could even use the same name(s) with different meaning 
>>> or structure. 
>>> 
>>> So, while I understand the motivation behind the RFC8707 resource parameter 
>>> being usable in a token request to make the AS filter, the included 
>>> authorization details of the resultant token based on the "locations" 
>>> element[1], I'm a bit concerned about a layering problem here. The 
>>> authorization details objects of the grant might not contain a "locations" 
>>> element or might have one with a different meaning or structure.  
>>> 
>>> The draft also describes using the authorization_details token request 
>>> parameter to specify the authorization details a client wants the AS to 
>>> assign to a particular access token[2]. So the problematic resource 
>>> parameter behaviour is also kind of redundant. I think maybe it should be 
>>> removed.
>>> 
>>> [*] described in 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 
>>> 
>>>  and mentioned at 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 
>>> 
>>>  and in 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 
>>> 
>>> 
>>> [2] 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
>>>  
>>> 
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>>> material for the sole use of the intended recipient(s). Any review, use, 
>>> distribution or disclosure by others is strictly prohibited.  If you have 
>>> received this communication in error, please notify the sender immediately 
>>> by e-mail and delete the message and any file attachments from your 
>>> computer. Thank you.___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162464483100=AOvVaw1Ol8hiDotFufYe9jQCTi1m
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RAR WGLC comment

2021-06-19 Thread Filip Skokan 
I support such change.

Odesláno z iPhonu

> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
> :
> 
> 
> Hi Brian,
> 
> the idea was to use resource indicators as convenient short cut to support 
> audience restricted access tokens. However, I agree this can be achieved by 
> specifying authorization details in the token request as well.
> 
> So I‘m fine with dropping resource indicators for RAR at all. This means RAR 
> on one hand and scopes + resource indicators on the other hand are clearly 
> decoupled and independent.
> 
> best regards,
> Torsten.
> 
>>> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
>>> :
>>> 
>> 
>> In my reading and understanding of the text and intent, the content and 
>> meaning of a particular authorization details object are fully governed by 
>> its "type". And while the draft provides a set of common data elements 
>> intended to be usable across different types (locations, actions, datatypes, 
>> identifier, privileges) a specific type is free to define whatever suits its 
>> needs. A type definition may or may not involve those common elements and 
>> could even use the same name(s) with different meaning or structure. 
>> 
>> So, while I understand the motivation behind the RFC8707 resource parameter 
>> being usable in a token request to make the AS filter, the included 
>> authorization details of the resultant token based on the "locations" 
>> element[1], I'm a bit concerned about a layering problem here. The 
>> authorization details objects of the grant might not contain a "locations" 
>> element or might have one with a different meaning or structure.  
>> 
>> The draft also describes using the authorization_details token request 
>> parameter to specify the authorization details a client wants the AS to 
>> assign to a particular access token[2]. So the problematic resource 
>> parameter behaviour is also kind of redundant. I think maybe it should be 
>> removed.
>> 
>> [*] described in 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and 
>> mentioned at 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and 
>> in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1
>> 
>> [2] 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>> material for the sole use of the intended recipient(s). Any review, use, 
>> distribution or disclosure by others is strictly prohibited.  If you have 
>> received this communication in error, please notify the sender immediately 
>> by e-mail and delete the message and any file attachments from your 
>> computer. Thank you.___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162464483100=AOvVaw1Ol8hiDotFufYe9jQCTi1m
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RAR WGLC comment

2021-06-19 Thread Torsten Lodderstedt 
Hi Brian,

the idea was to use resource indicators as convenient short cut to support 
audience restricted access tokens. However, I agree this can be achieved by 
specifying authorization details in the token request as well.

So I‘m fine with dropping resource indicators for RAR at all. This means RAR on 
one hand and scopes + resource indicators on the other hand are clearly 
decoupled and independent.

best regards,
Torsten.

> Am 18.06.2021 um 20:13 schrieb Brian Campbell 
> :
> 
> 
> In my reading and understanding of the text and intent, the content and 
> meaning of a particular authorization details object are fully governed by 
> its "type". And while the draft provides a set of common data elements 
> intended to be usable across different types (locations, actions, datatypes, 
> identifier, privileges) a specific type is free to define whatever suits its 
> needs. A type definition may or may not involve those common elements and 
> could even use the same name(s) with different meaning or structure. 
> 
> So, while I understand the motivation behind the RFC8707 resource parameter 
> being usable in a token request to make the AS filter, the included 
> authorization details of the resultant token based on the "locations" 
> element[1], I'm a bit concerned about a layering problem here. The 
> authorization details objects of the grant might not contain a "locations" 
> element or might have one with a different meaning or structure.  
> 
> The draft also describes using the authorization_details token request 
> parameter to specify the authorization details a client wants the AS to 
> assign to a particular access token[2]. So the problematic resource parameter 
> behaviour is also kind of redundant. I think maybe it should be removed.
> 
> [*] described in 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and 
> mentioned at 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and 
> in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1
> 
> [2] 
> https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited.  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=162464483100=AOvVaw1Ol8hiDotFufYe9jQCTi1m
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] RAR WGLC comment

2021-06-18 Thread Brian Campbell 
In my reading and understanding of the text and intent, the content and
meaning of a particular authorization details object are fully governed by
its "type". And while the draft provides a set of common data elements
intended to be usable across different types (locations, actions,
datatypes, identifier, privileges) a specific type is free to define
whatever suits its needs. A type definition may or may not involve those
common elements and could even use the same name(s) with different meaning
or structure.

So, while I understand the motivation behind the RFC8707 resource parameter
being usable in a token request to make the AS filter, the included
authorization details of the resultant token based on the "locations"
element[1], I'm a bit concerned about a layering problem here. The
authorization details objects of the grant might not contain a "locations"
element or might have one with a different meaning or structure.

The draft also describes using the authorization_details token request
parameter to specify the authorization details a client wants the AS to
assign to a particular access token[2]. So the problematic resource
parameter behaviour is also kind of redundant. I think maybe it should be
removed.

[*] described in
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2
and mentioned at
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8
and in
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1

[2]
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth