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

From: Roman Danyliw <[email-masked]>
Date: Tue, 16 Jul 2019 23:23:29 +0000

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?

---

From: Brian Campbell <[email-masked]>
Date: Wed, 17 Jul 2019 14:35:17 -0600

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.

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

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

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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 17 Jul 2019 21:13:07 +0000

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: [email-masked]
> Subject: AD Review: draft-ietf-oauth-resource-indicators-02
> 
> Hi!
> 
> 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.
> 
> 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./
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 17 Jul 2019 22:04:49 +0000

Hi Brian!

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, July 17, 2019 4:35 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

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.

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

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

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.

Okay.

** Section 2.  Editorial.

Yup.

Makes sense.

Of course.

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.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 17 Jul 2019 16:31:01 -0600

Yeah, as you surmised, there is some history behind this. Basically
draft-ietf-oauth-token-exchange predates
draft-ietf-oauth-resource-indicators by a good long time (years) and with
the hope and expectation that draft-ietf-oauth-token-exchange would move to
RFC, I've avoided having a reference in it to a draft much earlier along in
the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd
history too in that an initial call for adoption around the Buenos Aires
meeting kinda fizzled out and it was left for dead until being unexpected
resurrected around Montreal last year due to renewed interest and other
factors I'm still not sure I understand.

You are correct that draft-ietf-oauth-token-exchange defines "resource" for
token exchange. However the registry itself doesn't have that level of
granularity. It has authorization request, authorization response, token
request, and token response as the possible locations for parameter usage.
A token exchange request is a particular kind of token request so
draft-ietf-oauth-token-exchange registers "resource" for the token request
location. The IANA section was written before
draft-ietf-oauth-resource-indicators even existed. And leaving the
registration in draft-ietf-oauth-token-exchange seemed like the right thing
to do to even after draft-ietf-oauth-resource-indicators came along. But
I'm not sure, to be honest. Also FWIW a temporary registration entry for it
is already in
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

draft-ietf-oauth-resource-indicators defines "resource" for use at the
authorization endpoint (which token exchange does not) so that's the
impetus behind having the registration request there include authorization
request in the location. draft-ietf-oauth-resource-indicators also has
"resource" for use at the token endpoint using the same semantics as in
draft-ietf-oauth-token-exchange but in a way that is applicable to all
types of token requests to the the token endpoint and not only token
exchange requests. That's where the idea of updating the registry came from
- it's not a name collision and it's not a different definition - it's just
a more generalized usage.

I hope this makes some sense and hasn't muddied the waters more.

On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw <[email-masked]> wrote:

> 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
>
> this
> access
> invalid
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 17 Jul 2019 23:49:49 +0000

Hi Brian!

Thanks for this background and explanation.  There was history here I didn’t know.

With the benefit of this thread and private exchanges, the key takeaways for me are:

** the definition of 'resource' for 'token exchange' is identical in both drafts (draft-ietf-oauth-resource-indicator and draft-ietf-oauth-token-exchange)

** draft-ietf-oauth-resource-indicators has additional “uses” of resource not germane to draft-ietf-oauth-resource-indicator

** the desired ends-state after the IANA considerations sections of both drafts were process, the Oauth registry would look as follows:
- name = resource
- parameter usage location = authorization request, token request
- change controller = IETF
- reference = draft-ietf-oauth-resource-indicator

Is that right?

If the above is correct, would the following way ahead work:

** for draft-ietf-oauth-token exchange: Nothing

** for draft-ietf-oauth-resource-indicator

Per Section 4.1:

   This specification updates the following value in the IANA "OAuth
   Parameters" registry [IANA.OAuth.Parameters] established by
   [RFC6749].

   o  Parameter name: resource
   o  Parameter usage location: authorization request, token request
   o  Change controller: IESG
   o  Specification document(s): [[ this specification ]]

Per Section 4.2
   This specification updates the following error in the IANA "OAuth
   Extensions Error Registry" [IANA.OAuth.Parameters] established by
   [RFC6749].

   o  Error name: invalid_target
   o  Error usage location: implicit grant error response, token error
      response
   o  Related protocol extension: resource parameter
   o  Change controller: IESG
   o  Specification document(s): [[ this specification ]]

Roman

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, July 17, 2019 6:31 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Yeah, as you surmised, there is some history behind this. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-resource-indicators by a good long time (years) and with the hope and expectation that draft-ietf-oauth-token-exchange would move to RFC, I've avoided having a reference in it to a draft much earlier along in the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd history too in that an initial call for adoption around the Buenos Aires meeting kinda fizzled out and it was left for dead until being unexpected resurrected around Montreal last year due to renewed interest and other factors I'm still not sure I understand.

You are correct that draft-ietf-oauth-token-exchange defines "resource" for token exchange. However the registry itself doesn't have that level of granularity. It has authorization request, authorization response, token request, and token response as the possible locations for parameter usage. A token exchange request is a particular kind of token request so draft-ietf-oauth-token-exchange registers "resource" for the token request location. The IANA section was written before draft-ietf-oauth-resource-indicators even existed. And leaving the registration in draft-ietf-oauth-token-exchange seemed like the right thing to do to even after draft-ietf-oauth-resource-indicators came along. But I'm not sure, to be honest. Also FWIW a temporary registration entry for it is already in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

draft-ietf-oauth-resource-indicators defines "resource" for use at the authorization endpoint (which token exchange does not) so that's the impetus behind having the registration request there include authorization request in the location. draft-ietf-oauth-resource-indicators also has "resource" for use at the token endpoint using the same semantics as in draft-ietf-oauth-token-exchange but in a way that is applicable to all types of token requests to the the token endpoint and not only token exchange requests. That's where the idea of updating the registry came from - it's not a name collision and it's not a different definition - it's just a more generalized usage.

On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

Roman

> To: [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 19 Jul 2019 12:02:26 -0600

Thanks Roman,

I'm attempting to bring this thread and our private exchanges together
(sorry again that it ended up that way) and make sure we are on the same
page about the path forward before I start down that path.

Yes, your assessment below is correct. And yes I think the changes you
proposed to IANA section 4 of draft-ietf-oauth-resource-indicators follow
from that and make sense.

However, draft-ietf-oauth-token-exchange should also be changed to take on
a short sentence in its text about the resource parameter to mention
draft-ietf-oauth-resource-indicators and include an informational reference
to it.

Please confirm that or correct me and I'll proceed with the changes.

On Wed, Jul 17, 2019 at 5:49 PM Roman Danyliw <[email-masked]> wrote:

> ** the definition of 'resource' for 'token exchange' is identical in both
> drafts (draft-ietf-oauth-resource-indicator and
> draft-ietf-oauth-token-exchange)
>
>
>
> ** draft-ietf-oauth-resource-indicators has additional “uses” of resource
> not germane to draft-ietf-oauth-resource-indicator
>
>
>
> ** the desired ends-state after the IANA considerations sections of both
> drafts were process, the Oauth registry would look as follows:
>
> - name = resource
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, July 17, 2019 6:31 PM
> *To:* Roman Danyliw <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> You are correct that draft-ietf-oauth-token-exchange defines "resource"
> for token exchange. However the registry itself doesn't have that level of
> *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.*
>

---

From: Roman Danyliw <[email-masked]>
Date: Sat, 20 Jul 2019 00:17:33 +0000

Hi Brian!

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, July 19, 2019 2:02 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Thanks Roman,

I'm attempting to bring this thread and our private exchanges together (sorry again that it ended up that way) and make sure we are on the same page about the path forward before I start down that path.

Yes, your assessment below is correct. And yes I think the changes you proposed to IANA section 4 of draft-ietf-oauth-resource-indicators follow from that and make sense.

[Roman]  Ok.

However, draft-ietf-oauth-token-exchange should also be changed to take on a short sentence in its text about the resource parameter to mention draft-ietf-oauth-resource-indicators and include an informational reference to it.

[Roman] Correct.

Thanks for the iteration and explanations!

Roman

On Wed, Jul 17, 2019 at 5:49 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian!

Is that right?

Per Section 4.1:

Per Section 4.2

Roman

From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 17, 2019 6:31 PM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Roman

---

From: Brian Campbell <[email-masked]>
Date: Sun, 21 Jul 2019 10:50:32 -0600

Doh, I got distracted with the registration question and lost track of this
fork of the thread. I'll need to do a -04 also (after maybe some more
discussion too) before I pass the ball back to the AD.

On Wed, Jul 17, 2019, 4:04 PM Roman Danyliw <[email-masked]> wrote:

> *Sent:* Wednesday, July 17, 2019 4:35 PM
> Some of the examples (figures 2 - 6) attempt to show, among other things,
> a hypothetical case of how this might go down.
>
>
>
> https://contacts.example.com/ and the issued access token scope (Figure
> 6) is downscoped based on that resource to be only contacts
>
>
>
> [Roman] Using “downscope” does work for me.  It captures that the server
> is going to reduce the scope (and certainly not expand it).
>
>
>
>
> [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

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 21 Jul 2019 22:53:10 +0000

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 <[email-masked]>
Cc: [email-masked]
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[snip]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 22 Jul 2019 06:37:16 -0600

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 <[email-masked]> wrote:

> *From:* Roman Danyliw
> *Sent:* Wednesday, July 17, 2019 6:05 PM
> *To:* Brian Campbell <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [OAUTH-WG] AD Review:
> *From:* Brian Campbell [mailto:[email-masked]
> <[email-masked]>]

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 22 Jul 2019 13:11:29 +0000

Hi Brian!

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, July 22, 2019 8:37 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian!

Thanks,
Roman

From: Roman Danyliw
Sent: Wednesday, July 17, 2019 6:05 PM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[snip]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 22 Jul 2019 07:46:59 -0600

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 <[email-masked]> wrote:

> *Sent:* Monday, July 22, 2019 8:37 AM
> [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
>
>
>
>
>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 22 Jul 2019 13:50:30 +0000

Hi Brian!

The -04 version addresses my remaining concerned.  Thanks for this update.  I’ve advanced the document to IETF LC.

Roman

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, July 22, 2019 9:47 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian!

Roman

Thanks,
Roman

From: Roman Danyliw

[snip]