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
