Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation
Hi Brian, Am 24.01.2014 um 22:37 schrieb Brian Campbell bcampb...@pingidentity.com: 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 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 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
