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

[Brian Campbell <[e-mail]>]

Yes, sorry about that. I realized this yesterday and as tried to write
quickly from from my phone just before my flight took off for Montreal
<https://mailarchive.ietf.org/arch/msg/oauth/2ss3hDa0xPQxaWiW6txj9W-vpqo>,
I'd gotten distracted with the question of what to do with the
registrations and lost track of this fork of the thread.  There are indeed
a couple of outstanding bits that need to be addressed in a -04.

I'll change adapt to downscope.

Regarding your unanswered questions from below - partially quoted here for
reference:

'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?'
-> the idea there is privacy in terms of limiting what one service
potentially leans about other services the user is using. In the houses on
the block case you mentioned, the downscoping prevents the corner house
from learning that the user also accesses the other houses on the block.

'I also don’t follow how reducing the scope impacts confidential data.' ->
to be honest, this particular text came as a suggestion from another WG
member on review of an earlier version of the document. So I struggle a bit
to defend/explain it but I think the idea is that in some cases a scope
value itself might contain sensitive data like an account number or
transaction identifier (e.g. something like "acct:123456789" or
"tx:987654321"). This is somewhat uncommon in practice today but does
happen in some situations. The same principal of limiting the scopes
revealed across different services applies here too but with arguably worse
consequences due to the sensitive data within the scope value. It's the
same concept though and I think the mention of confidential data and scope
here in the document is more likely cause confusion than it is to help
anything. As such, I'm proposing to change that sentence as follows to
remove the confidential bit and somewhat better describe the cross-service
scope revealing issue.

      "This further improves privacy as scope values give an indication of
what services the resource
      owner uses and downscoping a token to only that which is needed for a
particular service can
      limit the extent to which such information is revealed across
different services."


On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw <[e-mail]> wrote:

> Hi Brian!
>
>
>
> Thanks for the update in -03.  The item below is the only thing that
> remains outstanding.
>
>
>
> Thanks,
>
> Roman
>
>
>
>
>
> *From:* Roman Danyliw
> *Sent:* Wednesday, July 17, 2019 6:05 PM
> *To:* Brian Campbell <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
>
>
> *From:* Brian Campbell [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, July 17, 2019 4:35 PM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> [snip]
>
>
>
> (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.
>
>
>
>
>

-- 
_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._