Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
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 On 9/5/19 4:01 PM, Barry Leiba wrote: Thanks, Brian. I hope Adam is happy with that as well. Barry On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell wrote: I went ahead with this in -07. On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell 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. On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba 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 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 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
I went ahead with this in -07. On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell 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. > > On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba > 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 >> 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 >> > -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename: draft-ietf-oauth-resource-indicators-07.txt Pages : 14 Date: 2019-09-05 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-resource-indicators-06.txt
-06 should address comments from IESG evaluation -- Forwarded message - From: Date: Thu, Sep 5, 2019 at 12:45 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename: draft-ietf-oauth-resource-indicators-06.txt Pages : 14 Date: 2019-09-05 Abstract: This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
thanks and done On Thu, Sep 5, 2019 at 11:53 AM Benjamin Kaduk wrote: > On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote: > > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > > > > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > > Thanks Ben, for the review and non-objectional ballot. > > > > > > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > > > > nore...@ietf.org> wrote: > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > > > > > > > > Section 3 > > > > > > > > > >An access token that is audience restricted to a protected > resource > > > > >that obtains that token legitimately cannot be used to access > > > > >resources on behalf of the resource owner at other protected > > > > >resources. The "resource" parameter enables a client to > indicate > > > the > > > > > > > > > > nit: This sentence has a pretty strange construction. I think the > > > > > intent is to say that that a token, legitimately presented to a > > > > > resource, cannot then be taken by that resource server and > > > > > illegitimately present it somewhere else for access to other > resources. > > > > > But with the current wording we seem to be missing part of the part > > > > > where some entity obtains the token with intent for illegitimate > > > access. > > > > > > > > > > > > > Yes, despite the pretty strange construction, you have the correct > > > intent. > > > > I'll work on improving that sentence (borrowing heavily from your > words > > > > there). > > > > > > > > > > > > > > > > >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. This will cause any access token > issued > > > > >for accessing the user controlled resource to have an invalid > > > > >audience if replayed against the legitimate resource API. > > > > > > > > > > I'm not entirely sure what this is trying to say. What is the > > > > > "legitimate resource API"? Why would a token be issued for > accessing a > > > > > user-controlled resource if that's something we're trying to avoid > > > > > having confused clients access? > > > > > > > > > > > > > Um... so on rereading that I might say that it's also "pretty > strange". > > > > > > > > What it was trying to somehow say is similar to the previous nit > about > > > > audience-restricted not being usable at the resource for whom the > weren't > > > > intended. But saying so in the context of a multi-tenant environment. > > > > Basically it's trying to say that, in a multi-tenant environment, the > > > > resource URI and subsequent token audience need to have something > that > > > > identifies the tenant so as to prevent the token from being used by > one > > > > tenant to illegitimately access resources at a different tenant. I'll > > > work > > > > on trying to improve that text to better explain all that. > > > > > > Ah, yes, that's a very good point to make. I'm happy to look at some > draft > > > text if you want. > > > > > > > Thanks, here's what I've got now for this and the previous item in sec 3. > > Suggestions welcome. > > > > 3. Security Considerations > > > >An audience-restricted access token, legitimately presented to a > >resource, cannot then be taken by that resource to present it > >elsewhere for illegitimate access to other resources. The "resource" > > I think "by that resource and presented elsewhere" probbaly has a more > parallel flow. > > >parameter enables a client to indicate the protected resources where > >the requested access token will be used, which in turn enables the > >authorization server to apply the appropriate audience restrictions > >to the token. > > > >Some servers may host user content or be multi-tenant. In order to > >avoid attacks where one tenant uses an access token to illegitimately > >access resources owned by a different tenant, it is important to use > >a specific resource URI including any portion of the URI that > >identifies the tenant, such as a path component. This will allow > >access tokens to be audience-restricted in a way that identifies the > >tenant and prevent their use, due to an invalid audience, at > >resources owned by a different tenant. > > But other than the above nit, this all looks really good; thank you! > > -Ben > -- _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
Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote: > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > Thanks Ben, for the review and non-objectional ballot. > > > > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > > > nore...@ietf.org> wrote: > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-oauth-resource-indicators-05: No Objection > > > > > > > > Section 3 > > > > > > > >An access token that is audience restricted to a protected resource > > > >that obtains that token legitimately cannot be used to access > > > >resources on behalf of the resource owner at other protected > > > >resources. The "resource" parameter enables a client to indicate > > the > > > > > > > > nit: This sentence has a pretty strange construction. I think the > > > > intent is to say that that a token, legitimately presented to a > > > > resource, cannot then be taken by that resource server and > > > > illegitimately present it somewhere else for access to other resources. > > > > But with the current wording we seem to be missing part of the part > > > > where some entity obtains the token with intent for illegitimate > > access. > > > > > > > > > > Yes, despite the pretty strange construction, you have the correct > > intent. > > > I'll work on improving that sentence (borrowing heavily from your words > > > there). > > > > > > > > > > > > >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. This will cause any access token issued > > > >for accessing the user controlled resource to have an invalid > > > >audience if replayed against the legitimate resource API. > > > > > > > > I'm not entirely sure what this is trying to say. What is the > > > > "legitimate resource API"? Why would a token be issued for accessing a > > > > user-controlled resource if that's something we're trying to avoid > > > > having confused clients access? > > > > > > > > > > Um... so on rereading that I might say that it's also "pretty strange". > > > > > > What it was trying to somehow say is similar to the previous nit about > > > audience-restricted not being usable at the resource for whom the weren't > > > intended. But saying so in the context of a multi-tenant environment. > > > Basically it's trying to say that, in a multi-tenant environment, the > > > resource URI and subsequent token audience need to have something that > > > identifies the tenant so as to prevent the token from being used by one > > > tenant to illegitimately access resources at a different tenant. I'll > > work > > > on trying to improve that text to better explain all that. > > > > Ah, yes, that's a very good point to make. I'm happy to look at some draft > > text if you want. > > > > Thanks, here's what I've got now for this and the previous item in sec 3. > Suggestions welcome. > > 3. Security Considerations > >An audience-restricted access token, legitimately presented to a >resource, cannot then be taken by that resource to present it >elsewhere for illegitimate access to other resources. The "resource" I think "by that resource and presented elsewhere" probbaly has a more parallel flow. >parameter enables a client to indicate the protected resources where >the requested access token will be used, which in turn enables the >authorization server to apply the appropriate audience restrictions >to the token. > >Some servers may host user content or be multi-tenant. In order to >avoid attacks where one tenant uses an access token to illegitimately >access resources owned by a different tenant, it is important to use >a specific resource URI including any portion of the URI that >identifies the tenant, such as a path component. This will allow >access tokens to be audience-restricted in a way that identifies the >tenant and prevent their use, due to an invalid audience, at >resources owned by a different tenant. But other than the above nit, this all looks really good; thank you! -Ben ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Help
I have unsubscribed and banned this person from the list. Regards, Rifaat On Thu, Sep 5, 2019 at 11:18 AM Vanessa Andor wrote: > >1. Re: Benjamin Kaduk's No Objection on > draft-ietf-oauth-resource-indicators-05: (with COMMENT) > (Benjamin Kaduk) >2. Re: Benjamin Kaduk's No Objection on > draft-ietf-oauth-resource-indicators-05: (with COMMENT) > (Brian Campbell) >3. (no subject) (Vanessa Andor) > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Help
1. Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) (Benjamin Kaduk) 2. Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) (Brian Campbell) 3. (no subject) (Vanessa Andor) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] (no subject)
"Help" ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
