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

[Brian Campbell <[e-mail]>]

Thanks Adam, for the review and No Objection ballot.

On Wed, Sep 4, 2019 at 12:07 AM Adam Roach via Datatracker <[e-mail]>
wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection
>
> ----------------------------------------------------------------------
> 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.
>

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.


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

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.



§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"?
>

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.


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

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