Hi Roman, Thanks again for sticking with me through this one with and associated registry updates with token exchange as well as my temporarily overlooking some needed changes.
-04 is now up <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-04> and this time I think I've actually addressed all your comments. On Mon, Jul 22, 2019 at 7:11 AM Roman Danyliw <r...@cert.org> wrote: > Hi Brian! > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] > *Sent:* Monday, July 22, 2019 8:37 AM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > 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." > > > > [Roman] Thanks for the explanation relative to my analogy. I agree that > the proposed text above is a lot clearer and it addresses my concern. > > > > Roman > > > > > > On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw <r...@cert.org> 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 <bcampb...@pingidentity.com> > *Cc:* oauth@ietf.org > *Subject:* RE: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com > <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 > > > > [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.* > -- _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
