Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

Currently the canonical form of RFC is ASCII and there is a external tool that tries to do HTML markup on the ascii version.

When authoring something that works in english may well not get the right HTML markup.
The Authors do there best but there is no way to fix by editing the HTML as a reasonable person might expect.

The process is changing to make the XML the canonical form so that HTML can be produced with correct markup.

Going forward I hope these markup problems are eliminated in new drafts.

John B.

> On Jan 15, 2016, at 9:21 AM, Buhake Sindi <buhake@gmail.com> wrote:
> 
> Hi,
> 
> Was just reading the specification (RFC 7662) and the following link "breaks"
> 
> Chapter 2.3
> 
> 
> 2.3 <https://tools.ietf.org/html/rfc7662#section-2.3>.  Error Response
> 
>    If the protected resource uses OAuth 2.0 client credentials to
>    authenticate to the introspection endpoint and its credentials are
>    invalid, the authorization server responds with an HTTP 401
>    (Unauthorized) as described in Section 5.2 <https://tools.ietf.org/html/rfc7662#section-5.2> of OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>].
> 
> 
> 
> 
> 
> Richer                       Standards Track                    [Page 8]
>   <https://tools.ietf.org/html/rfc7662#page-9>
> RFC 7662 <https://tools.ietf.org/html/rfc7662>                   OAuth Introspection              October 2015
> 
> 
>    If the protected resource uses an OAuth 2.0 bearer token to authorize
>    its call to the introspection endpoint and the token used for
>    authorization does not contain sufficient privileges or is otherwise
>    invalid for this request, the authorization server responds with an
>    HTTP 401 code as described in Section 3 <https://tools.ietf.org/html/rfc7662#section-3> of OAuth 2.0 Bearer Token
>    Usage [RFC6750 <https://tools.ietf.org/html/rfc6750>].
> 
> The link of [Section 5.2] and [Section 3] both points to the same link (of RFC 7662) instead of the specified RFC. E.g. There is no Section 5.2 on RFC 7662 but the link points to it.
> 
> 
> Kind Regards,
> 
> 
> Buhake Sindi
> 
> 
> On 15 January 2016 at 16:15, Sergey Beryozkin <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>> wrote:
> Ouch, you are right, sorry for the confusion,
> Thanks, Sergey
> On 15/01/16 14:13, Buhake Sindi wrote:
> Hi,
> 
> Are you not mistaking this with RFC 7662? :-)
> 
> Kind Regards,
> 
> Buhake Sindi
> 
> On 15 Jan 2016 12:34, "Sergey Beryozkin" <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>
> <mailto:sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>>> wrote:
> 
>     Hi All,
> 
>     I'm reviewing RFC 7622 as we are going ahead with implementing it.
>     I have a question:
> 
>     1. Token Hint in the introspection request.
>     The spec mentions 'refresh_token' as one of the possible values. But
>     a protected resource does not see a refresh token (ever ?), it is
>     Access Token service which does.
>     When would a protected resource use a 'refresh_token' hint when
>     requesting an introspection response ?
> 
>     Thanks, Sergey
> 
> 
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
>     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/ <http://coders.talend.com/>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth