Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation
Hi Brian, > Am 24.01.2014 um 22:37 schrieb Brian Campbell : > > Thanks Torsten, > > The intent there definitely makes sense. Thanks for clarifying. And I had > sort of guessed that retaining the query component was what that reference > was trying to do. But a flat reading of the text doesn't convey that, I don't > think. I'd guess the answer is "no" but does this kind of thing warrant > errata consideration? I don't know. I suggest we discuss this in London. best regards, Torsten. > > > > >> On Wed, Jan 8, 2014 at 11:51 AM, Torsten Lodderstedt >> wrote: >> Hi Brian, >> >> this particular sentence is intended to specify the structure of the >> revocation URL only. It refers to this text in RFC 6749: >> >> "The endpoint URI MAY include an "application/x-www-form-urlencoded" >>formatted (per Appendix B) query component ([RFC3986] Section 3.4), which >> MUST be retained when adding additional query parameters. The endpoint URI >> MUST NOT include a fragment component.", >> >> which is equivalent for authz and token endpoint. >> >> I see your point, it seems to confuse (at least) a bit. In retrospective, it >> would have been a better idea to copy the text. >> >> The reference in section 2.1 is wrong, it should point to RFC 6749 >> (http://tools.ietf.org/html/rfc6749#section-2.3). >> >> regards, >> Torsten. >> >> Am 13.12.2013 00:42, schrieb Brian Campbell: >>> The second paragraph of section 2 of RFC 7009 [1] says that the revocation >>> endpoint must conform to the rules in section 3.1 of RFC 6749 (The OAuth >>> 2.0 Authorization Framework) [2] but that section is about the >>> *Authorization Endpoint*, which doesn't make much sense to me. The resource >>> owner is involved with the authorization endpoint but not with the >>> revocation endpoint. The authorization endpoint MUST accept GET and MAY >>> accept POST while the revocation endpoint always accepts POST except for >>> the JSONP support which is just a MAY for GET. There's also talk elsewhere >>> in RFC 7009 about client authentication, which only happens at the token >>> endpoint, not the authorization endpoint (note that the link in in 2.1 of >>> RFC 7009 [3] that should go to 2.3 of RFC6749 actually links back to >>> itself). >>> >>> Is the reference a mistake in RFC 7009? If not, could someone explain what >>> the intent was there or what it really means? >>> >>> Thanks for any clarification! >>> >>> [1] http://tools.ietf.org/html/rfc7009#section-2 >>> [2] http://tools.ietf.org/html/rfc6749#section-3.1 >>> [3] http://tools.ietf.org/html/rfc7009#section-2.1 >>> >>> >>> >>> ___ >>> 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
Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation
Thanks Torsten, The intent there definitely makes sense. Thanks for clarifying. And I had sort of guessed that retaining the query component was what that reference was trying to do. But a flat reading of the text doesn't convey that, I don't think. I'd guess the answer is "no" but does this kind of thing warrant errata consideration? On Wed, Jan 8, 2014 at 11:51 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Brian, > > this particular sentence is intended to specify the structure of the > revocation URL only. It refers to this text in RFC 6749: > > "The endpoint URI MAY include an "application/x-www-form-urlencoded" >formatted (per Appendix B) query component ([RFC3986] Section 3.4), > which MUST be retained when adding additional query parameters. The > endpoint URI MUST NOT include a fragment component.", > > which is equivalent for authz and token endpoint. > > I see your point, it seems to confuse (at least) a bit. In retrospective, > it would have been a better idea to copy the text. > > The reference in section 2.1 is wrong, it should point to RFC 6749 ( > http://tools.ietf.org/html/rfc6749#section-2.3). > > regards, > Torsten. > > Am 13.12.2013 00:42, schrieb Brian Campbell: > > The second paragraph of section 2 of RFC 7009 [1] says that the > revocation endpoint must conform to the rules in section 3.1 of RFC 6749 > (The OAuth 2.0 Authorization Framework) [2] but that section is about the > *Authorization Endpoint*, which doesn't make much sense to me. The resource > owner is involved with the authorization endpoint but not with the > revocation endpoint. The authorization endpoint MUST accept GET and MAY > accept POST while the revocation endpoint always accepts POST except for > the JSONP support which is just a MAY for GET. There's also talk elsewhere > in RFC 7009 about client authentication, which only happens at the token > endpoint, not the authorization endpoint (note that the link in in 2.1 of > RFC 7009 [3] that should go to 2.3 of RFC6749 actually links back to > itself). > > Is the reference a mistake in RFC 7009? If not, could someone explain > what the intent was there or what it really means? > > Thanks for any clarification! > > [1] http://tools.ietf.org/html/rfc7009#section-2 > [2] http://tools.ietf.org/html/rfc6749#section-3.1 > [3] http://tools.ietf.org/html/rfc7009#section-2.1 > > > > ___ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation
Hi Brian, this particular sentence is intended to specify the structure of the revocation URL only. It refers to this text in RFC 6749: "The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.", which is equivalent for authz and token endpoint. I see your point, it seems to confuse (at least) a bit. In retrospective, it would have been a better idea to copy the text. The reference in section 2.1 is wrong, it should point to RFC 6749 (http://tools.ietf.org/html/rfc6749#section-2.3). regards, Torsten. Am 13.12.2013 00:42, schrieb Brian Campbell: The second paragraph of section 2 of RFC 7009 [1] says that the revocation endpoint must conform to the rules in section 3.1 of RFC 6749 (The OAuth 2.0 Authorization Framework) [2] but that section is about the *Authorization Endpoint*, which doesn't make much sense to me. The resource owner is involved with the authorization endpoint but not with the revocation endpoint. The authorization endpoint MUST accept GET and MAY accept POST while the revocation endpoint always accepts POST except for the JSONP support which is just a MAY for GET. There's also talk elsewhere in RFC 7009 about client authentication, which only happens at the token endpoint, not the authorization endpoint (note that the link in in 2.1 of RFC 7009 [3] that should go to 2.3 of RFC6749 actually links back to itself). Is the reference a mistake in RFC 7009? If not, could someone explain what the intent was there or what it really means? Thanks for any clarification! [1] http://tools.ietf.org/html/rfc7009#section-2 [2] http://tools.ietf.org/html/rfc6749#section-3.1 [3] http://tools.ietf.org/html/rfc7009#section-2.1 ___ 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
