heartb...@yahoo.com,rafal.rog...@aol.com, rogalarafa...@gmail.com, rogalarafa...@gmail.com,24piotrpawe...@gmail.com, heartb...@heartblit.org,aidis_add...@outlook.be, atomic_f...@hotmail.com,microshe...@outlook.com,rafalrog...@rafal.rogala.com,rogalik1...@interia.pl
Sent from Yahoo Mail on Android On Thu, 18 Jul 2019 at 0:05, oauth-requ...@ietf.org<oauth-requ...@ietf.org> wrote: Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-requ...@ietf.org You can reach the person managing the list at oauth-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: AD Review: draft-ietf-oauth-resource-indicators-02 (Brian Campbell) 2. Re: AD Review: draft-ietf-oauth-resource-indicators-02 (Roman Danyliw) 3. Re: AD Review: draft-ietf-oauth-resource-indicators-02 (Roman Danyliw) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jul 2019 14:35:17 -0600 From: Brian Campbell <bcampb...@pingidentity.com> To: Roman Danyliw <r...@cert.org> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Message-ID: <ca+k3ecrs2hkduwkhqzwomvauuk7ubadw_pwdf6cxh0+bszt...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Thank you, Roman, for the review. Some replies are inline below. I'll aim to push out a -03 addressing this stuff sometime not too long after the I-D submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw <r...@cert.org> wrote: > Hi! > > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. > That's always nice to hear :-) > > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is > this "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? > Absolutely (see what I did there? sigh...). Syntactically it's an absolute URI. Semantically, while it might be an actual network addressable location identified by an HTTPS URL, it might also be a URN or something that more abstractly indicates a resource or grouping of resources. But its format is an absolute URI regardless. I'm not sure what, if anything, can be added or changed here to help clarify. But I'm happy to entertain suggestions, if you've got em and/or think something is needed. > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > -- is this language suggesting that the authorization server is modifying > the scope value based on the resource it sees? I'm trying to understand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > Perhaps "adapt" wasn't the best choice of word but it's meant to say that an authorization server with sufficient understanding of what scopes are applicable to what resources (which won't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really) to only the scope that is applicable to the resource. Some of the examples (figures 2 - 6) attempt to show, among other things, a hypothetical case of how this might go down. In Figure 2 the initial authorization request that's approved has scope of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/ A subsequent access token request (Figure 3) has resource https://cal.example.com/ and the issued access token scope (Figure 4) is "adapted" to that resource to be only calendar Another subsequent access token request (Figure 5) has resource https://contacts.example.com/ and the issued access token scope (Figure 6) is downscoped based on that resource to be only contacts Would it be easier to understand if the word "downscope" was used rather than "adapt"? > > -- (Depending on the above) Is there a security consideration here for the > server relative to confidential scope values and how they might be modified? > I'm not sure, to be honest. Downscopping when possible and to the extent possible is usually a good idea (least privilege and all that) but I think maybe I'm missing your point/question. > > (3) Editorial > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > Apparently I'm fond of the double "the" and have a hard time spotting it myself. I think this is the second review in as many weeks that you've caught a few of those. Will fix. > > ** Section 2. Editorial. s/resource at which/resource to which/ > Okay. > > ** Section 2. Editorial. > s/ And can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > It can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > Yup. > > ** Section 2.1. Multiple Typo. s/an an/an/g > Again with the double words. Sigh. A double double even. > ** Section 2.2. Editorial. s/token request and response/token request > (Figure 3) and response (Figure 4)/ > Makes sense. > ** Section 3. Typo. s/a invalid/an invalid/ > Of course. > > ** Section 3. Missing words. "A bearer token that has multiple intended > recipients (audiences) can be used by any one of those recipients at any > other." Is it protected resource? > Well, those are all the words that I'd intended to be there :/ But it does read a little curtly. How about the following instead? "A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources." -- _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._ -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190717/50785876/attachment.html> ------------------------------ Message: 2 Date: Wed, 17 Jul 2019 21:13:07 +0000 From: Roman Danyliw <r...@cert.org> To: "'oauth@ietf.org'" <oauth@ietf.org> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> Content-Type: text/plain; charset="us-ascii" Hi! I forgot one more thing about this draft after re-reading draft-ietf-oauth-token-exchange. Per the IANA action in Section 4.1, I need help understanding on the thinking to resolve this TODO: o Parameter usage location: authorization request, token request [[TODO: draft-ietf-oauth-token-exchange will have already registered this for 'token request' and this draft has a more generalized usage and needs to somehow either update that registration or do a partial registration and reference]] o Change controller: IESG o Specification document(s): [[ this specification ]] My read of draft-ietf-oauth-token-exchange it that it defines 'resource' for 'token exchange'. This draft (draft-ietf-oauth-resource-indicators) has guidance on 'resource' for 'authorization request' but also additional guidance for 'token request'. Is the token guidance request stated here applicable to draft-ietf-oauth-token-exchange too (i.e., is the text effectively saying oauth-resource-indicators updates oauth-token-exhange)? I ask because these drafts don't reference each other. Correct me because there is likely a history, but it seems the TODO is that there is a dependency to resolve and a need to coming up with a way to signal in the registry which draft should be read for what usage location. Could draft-ietf-oauth-resource-indicators officially register 'resource'; and instead of draft-ietf-oauth-token-exchange including the text defining 'resource' in Section 2.1, it would make a normative reference to Section 2 of draft-ietf-oauth-resource-indicators? Roman > -----Original Message----- > From: Roman Danyliw > Sent: Tuesday, July 16, 2019 7:23 PM > To: oauth@ietf.org > Subject: AD Review: draft-ietf-oauth-resource-indicators-02 > > Hi! > > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. > > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is this > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? > > (2) Section 2.2. in the sentence "To the extent possible, when issuing access > tokens, the authorization server should adapt the scope value associated > with an access token to the value the respective resource is able to process > and needs to know": > > -- is this language suggesting that the authorization server is modifying the > scope value based on the resource it sees? I'm trying to understand what > "adapt" means, especially in relation to the improved security and privacy the > subsequent sentence suggests. > > -- (Depending on the above) Is there a security consideration here for the > server relative to confidential scope values and how they might be modified? > > (3) Editorial > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > > ** Section 2. Editorial. s/resource at which/resource to which/ > > ** Section 2. Editorial. > s/ And can also be used to inform the client that it has requested an invalid > combination of resource and scope./ It can also be used to inform the client > that it has requested an invalid combination of resource and scope./ > > ** Section 2.1. Multiple Typo. s/an an/an/g > > ** Section 2.2. Editorial. s/token request and response/token request > (Figure 3) and response (Figure 4)/ > > ** Section 3. Typo. s/a invalid/an invalid/ > > ** Section 3. Missing words. "A bearer token that has multiple intended > recipients (audiences) can be used by any one of those recipients at any > other." Is it protected resource? ------------------------------ Message: 3 Date: Wed, 17 Jul 2019 22:04:49 +0000 From: Roman Danyliw <r...@cert.org> To: Brian Campbell <bcampb...@pingidentity.com> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> Content-Type: text/plain; charset="utf-8" Hi Brian! From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 17, 2019 4:35 PM To: Roman Danyliw <r...@cert.org> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thank you, Roman, for the review. Some replies are inline below. I'll aim to push out a -03 addressing this stuff sometime not too long after the I-D submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw <r...@cert.org<mailto:r...@cert..org>> wrote: Hi! The following is my AD review of draft-ietf-oauth-resource-indicators-02. The document is in good shape. That's always nice to hear :-) (1) Section 2. Per "The parameter can carry the location of a protected resource, typically as an https URL, or a more abstract identifier", is this "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? Absolutely (see what I did there? sigh...). Syntactically it's an absolute URI. Semantically, while it might be an actual network addressable location identified by an HTTPS URL, it might also be a URN or something that more abstractly indicates a resource or grouping of resources. But its format is an absolute URI regardless. I'm not sure what, if anything, can be added or changed here to help clarify. But I'm happy to entertain suggestions, if you've got em and/or think something is needed. [Roman] Understood. Concur there is nothing to do here. (2) Section 2.2. in the sentence "To the extent possible, when issuing access tokens, the authorization server should adapt the scope value associated with an access token to the value the respective resource is able to process and needs to know": -- is this language suggesting that the authorization server is modifying the scope value based on the resource it sees? I'm trying to understand what "adapt" means, especially in relation to the improved security and privacy the subsequent sentence suggests. Perhaps "adapt" wasn't the best choice of word but it's meant to say that an authorization server with sufficient understanding of what scopes are applicable to what resources (which won't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really) to only the scope that is applicable to the resource. Some of the examples (figures 2 - 6) attempt to show, among other things, a hypothetical case of how this might go down. In Figure 2 the initial authorization request that's approved has scope of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/ A subsequent access token request (Figure 3) has resource https://cal.example.com/ and the issued access token scope (Figure 4) is "adapted" to that resource to be only calendar Another subsequent access token request (Figure 5) has resource https://contacts.example.com/ and the issued access token scope (Figure 6) is downscoped based on that resource to be only contacts Would it be easier to understand if the word "downscope" was used rather than "adapt"? [Roman] Using ?downscope? does work for me. It captures that the server is going to reduce the scope (and certainly not expand it). -- (Depending on the above) Is there a security consideration here for the server relative to confidential scope values and how they might be modified? I'm not sure, to be honest. Downscopping when possible and to the extent possible is usually a good idea (least privilege and all that) but I think maybe I'm missing your point/question. [Roman] Yes, least privilege was part of it and I think the text above gets at it. However, the other part is the relationship with the next sentence in the paragraph, ?This further improves privacy as scope values give an indication of what services the resource owner uses and it improves security as scope values may contain confidential data?. If the initial request was notionally a scope of ?all the houses on the block?, but the server knew that this request was too broad and down-scoped to ?only the corner house?, wouldn?t this actually be worse for privacy? I also don?t follow how reducing the scope impacts confidential data. (3) Editorial ** Section 1 and 2.1. Multiple Typo. s/the the/the/g Apparently I'm fond of the double "the" and have a hard time spotting it myself. I think this is the second review in as many weeks that you've caught a few of those. Will fix. ** Section 2. Editorial. s/resource at which/resource to which/ Okay. ** Section 2. Editorial. s/ And can also be used to inform the client that it has requested an invalid combination of resource and scope./ It can also be used to inform the client that it has requested an invalid combination of resource and scope./ Yup. ** Section 2.1. Multiple Typo. s/an an/an/g Again with the double words. Sigh. A double double even. ** Section 2.2. Editorial. s/token request and response/token request (Figure 3) and response (Figure 4)/ Makes sense. ** Section 3. Typo. s/a invalid/an invalid/ Of course. ** Section 3. Missing words. "A bearer token that has multiple intended recipients (audiences) can be used by any one of those recipients at any other." Is it protected resource? Well, those are all the words that I'd intended to be there :/ But it does read a little curtly. How about the following instead? "A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources." [Roman] Thanks for fixing all of these. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190717/de45ad15/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 129, Issue 23 **************************************
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
