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

Reply via email to