Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 03 Sep 2019 23:06:43 -0700

Adam Roach has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks to everyone who worked on this refinement to OAuth.
It seems like it will be a significant improvement over today's
ad-hoc system.

I agree with Barry and Alexey about the need for some language discussing
the privacy implications of explicitly signaling audience resources to
OAuth servers.

---------------------------------------------------------------------------

§2:

>  The client SHOULD use the base URI of the API
>  as the "resource" parameter value unless specific knowledge of the
>  resource dictates otherwise.  For example, the value
>  "https://api.example.com/" would be used for a resource that is the
>  exclusive application on that host, however, if the resource is one
>  of many applications on that host, something like
>  "https://api.example.com/app/" would be used as a more specific
>  value.  Another example, for an API like SCIM [RFC7644] that has
>  multiple endpoints such as "https://apps.example.com/scim/Users",
>  "https://apps.example.com/scim/Groups", and
>  "https://apps.example.com/scim/Schemas" The client would use
>  "https://apps.example.com/scim/" as the resource so that the issued
>  access token is valid for all the endpoints of the SCIM API.

This seems pretty intuitive in the examples given. It may be a little
less clear when applications are indicated by query parameter instead
of path prefixes. For example, if an endpoint is running two applications
distinguished thus:

https://example.com/apps/?app=app1
https://example.com/apps/?app=app2

...and in a form that allows for additional parameters:

https://example.com/apps/?darkmode=true&version=1.2&app=app2

...then the notion of the "most specific API" isn't quite as clear.
Intuitively, I think the idea would be that the resource for app2
would be <https://example.com/apps/?app=app2>. It may be useful
to include an example along these lines as an illustration.

---------------------------------------------------------------------------

§2.2:

>    &resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F
...
>        "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
>         JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
>         iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
>         ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
>         OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
>         UowfmtNaA5EikYAw",

The "aud" value here is "https://contacts.example.com/" rather than the
"https://contacts.example.com/app/" that I would expect -- that is, I would
expect them to match. Am I misunderstanding the intended relationship between
"resouce" and "aud"?

---------------------------------------------------------------------------

§3:

>  Some servers may host user content or be multi-tenant.  In order to
>  avoid attacks that might confuse a client into sending an access
>  token to a resource that is user controlled or is owned by a
>  different tenant, it is important to use a specific resource URI
>  including a path component.

Related to my comment about §2 above, "path component" isn't quite sufficient.
What you want is "including any portion of the URI that identifies the
resource, such as a path component."

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Sep 2019 14:46:26 -0600

Thanks Adam, for the review and No Objection ballot.

> draft-ietf-oauth-resource-indicators-05: No Objection

Barry had other nits and was looking for some clarifying hyphenation. While
it was Alexey, Mirja, Alissa and Eric who have expressed the desire to see
some discussion of the privacy implications added. But I digress and the
who doesn't much matter as the need for something seems to have been
clearly established via comment by a few folks. I've been working on some
text towards that end. Honestly, I'm not too thrilled with it - it amounts
to saying that there's already not much privacy in OAuth and explicitly
signaling resources might make the situation only marginally worse - not
sure what else to say but I do plan to put some text along those lines
discussing the privacy implications in for the next revision.

> to include an example along these lines as an illustration.

Yeah, with query parameters lacking the hierarchical semantics that the
path component has, it is much less clear. In fact, an earlier revision of
the draft forbid the query part as I was trying to avoid the ambiguity that
it brings. But there were enough folks with some use case for it that it
made its way back in. While I am sympathetic to the point you're making
here, I'd prefer to not codify the practice any further by way of example
in the document.

> expect them to match. Am I misunderstanding the intended relationship

The relationship doesn't necessarily have to be 1-1 (text about that at the
very end of the main sec 2) but I think here I've just messed up the
example a bit. Looking again at series of examples that kinda build on one
another as well as the explanatory text leading up to figures 5 & 6, it
seems that the value of the resource in the request in figure 5 probably
should have also been just "https://contacts.example.com/" without the
extraneous path part. And that would then match up to your expectations of
the aud claim in figure 6. I'll change figure 5 accordingly to fix that.

> resource, such as a path component."

Fair point. Will change.

-- 
_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: Barry Leiba <[email-masked]>
Date: Wed, 4 Sep 2019 16:53:52 -0400

> Yeah, with query parameters lacking the hierarchical semantics that the path component has, it is much less clear. In fact, an earlier revision of the draft forbid the query part as I was trying to avoid the ambiguity that it brings. But there were enough folks with some use case for it that it made its way back in. While I am sympathetic to the point you're making here, I'd prefer to not codify the practice any further by way of example in the document.

Is it perhaps reasonable to discourage the use of a query component
while still allowing it?  Maybe a "SHOULD NOT", such as this?:

OLD
      Its value MUST be an absolute URI, as specified by
      Section 4.3 of [RFC3986], which MAY include a query component but
      MUST NOT include a fragment component.
NEW
      Its value MUST be an absolute URI, as specified by
      Section 4.3 of [RFC3986].  The URI MUST NOT include
      a fragment component.  It SHOULD NOT include a query
      component, but it is recognized that there are cases that
      make a query component useful.
END

What do you think?

Barry

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Sep 2019 15:07:31 -0600

Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change
like that at this stage. I guess I'd be looking for a little more buy-in
from folks first. Though it's not actually a functional breaking change. So
maybe okay to just go with.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Sep 2019 13:01:00 -0600

I went ahead with this in -07.

On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <[email-masked]>
wrote:

> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a
> change like that at this stage. I guess I'd be looking for a little more
> buy-in from folks first. Though it's not actually a functional breaking
> change. So maybe okay to just go with.
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 Sep 2019 17:01:36 -0400

Thanks, Brian.  I hope Adam is happy with that as well.

Barry

On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell
<[email-masked]> wrote:
> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <[email-masked]> wrote:
>>
>> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change like that at this stage. I guess I'd be looking for a little more buy-in from folks first. Though it's not actually a functional breaking change. So maybe okay to just go with.
>>
> 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: Adam Roach <[email-masked]>
Date: Thu, 5 Sep 2019 19:41:17 -0500

I don't have a strong objection to it. I still think that, if this is 
allowed (even as a SHOULD NOT), we need clarity that any query 
parameters that are used to scope queries to an application necessarily 
form part of the resource parameter. It's significantly less important, 
though, now that the practice is discouraged, and I won't mind if you go 
ahead without adding such text.

/a

---

From: Brian Campbell <[email-masked]>
Date: Fri, 6 Sep 2019 12:17:28 -0600

I don't have any aversion to adding something but I've been at a bit of a
loss as to what exactly to say or how to say it. But here's a stab at
something. How about the following sentence, which kind of layers your
words onto the text that Barry previously suggested:

"It SHOULD NOT include a query component, but it is recognized that there
are cases that make a query component a useful and necessary part of the
resource parameter, such as when query parameter(s) are used to scope
requests to an application."

On Thu, Sep 5, 2019 at 6:41 PM Adam Roach <[email-masked]> wrote:

> >>>>> Yeah, with query parameters lacking the hierarchical semantics that
> the path component has, it is much less clear. In fact, an earlier revision
> of the draft forbid the query part as I was trying to avoid the ambiguity
> that it brings. But there were enough folks with some use case for it that
> it made its way back in. While I am sympathetic to the point you're making
> >> 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.
>
>
>