Thanks Adam, for the review and No Objection ballot. On Wed, Sep 4, 2019 at 12:07 AM Adam Roach via Datatracker <[email protected]> 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._
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
