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