Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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._