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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
