Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9E1AD412 for ; Thu, 4 Dec 2014 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZM0kgC_vbGJ for ; Thu, 4 Dec 2014 07:04:52 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id F214C1AD410 for ; Thu, 4 Dec 2014 07:04:45 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C46952E1DE; Thu, 4 Dec 2014 10:04:45 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 6D48C33205B; Thu, 4 Dec 2014 10:04:45 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Thu, 4 Dec 2014 10:04:44 -0500 From: "Richer, Justin P." To: Thomas Broyer Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt Thread-Index: AQHQD1WE7TfAWu1mH0SVOqzin8wav5x+4W2AgABbzJ2AAJ/EAA== Date: Thu, 4 Dec 2014 15:04:44 +0000 Message-ID: <0A1A0CA9-C342-4BA1-82AC-A4D455A7FE16@mitre.org> References: <20141203235937.18518.61073.idtracker@ietfa.amsl.com> <1CC6F891-189D-416F-8C34-281997F8A1B7@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: multipart/alternative; boundary="_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uTwxicG8DvH4m99NRjHbsiCHmBY Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 15:05:10 -0000 --_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 4, 2014, at 5:34 AM, Thomas Broyer > wrote: A few notes on the "form" only (not the "content"): HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actua= lly replacing 2617). Specifically, the GET and POST methods are defined in = RFC 7231. Thanks, will update the reference there. application/x-www-form-urlencoded refers to RFC 1866; the same media type i= s said to be defined in HTML 4 in RFC 6749 and RFC 6750; and HTML 5 is now = a thing. RFC 7009 uses the media type too but doesn't refer to any other RF= C defining it. I think this draft should either refer to RFC 6749, Appendix B or to HTML 4 (for consistency with RFC= 6750) or to HTML 5 (because HTML 5 supersedes HTML 4). I'd go with HTML 5, given that the IANA registration has been updated in th= at sense (see http://www.w3.org/TR/2014/REC-html5-20141028/iana.html#applic= ation/x-www-form-urlencoded and https://www.iana.org/assignments/media-type= s/application/x-www-form-urlencoded); but given that RFC 6749, Appendix B a= lgorithm is a subset of the HTML 5 one (enforces the use of UTF-8, ignoring= the special key "_charset_"), and for consistency with other OAuth 2.0 spe= cs, then maybe it'd be wiser to use the RFC 6749, Appendix B algorithm. I'll just go with HTML5 as that's the canonical spec for this mime type now= . No need to make it complicated, and any updates of 6749/6750 will likely = do the same I would imagine. References to sections of other specs form broken links in the rfcmarkup ve= rsion, because of the name of the other spec appearing between "section N o= f" and the bracketed reference. For example, in section 2.3, "section 5.2 o= f OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]" I've seen this happen before, and I think it's a tool artifact. There's a dangling "These parameters" in section 2.1. This lacks at least a= verb and a colon ("These parameters are:"). Thanks, good catch! I think I was in the middle of rewriting that part when= I got distracted. -- Justin A last note on the content itself: +1, I don't think I have any further com= ment to make. On Thu Dec 04 2014 at 01:05:07 Richer, Justin P. > wrote: Small update to the Introspection draft incorporating comments from the pas= t couple days. I haven't put together the IANA considerations section that = will tie the introspection claims to the JWT registry yet, but that's the i= ntent. Please check the diffs, read the new version, and continue to send c= omments to the list. Thanks, -- Justin On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-02.txt > Pages : 11 > Date : 2014-12-03 > > Abstract: > This specification defines a method for a protected resource to query > an OAuth 2.0 authorization server to determine the active state of an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information about > the authorization context of the token from the authorization server > to the protected resource. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-02 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <986D59257FF4E343885AA035D38A39F4@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
On Dec 4, 2014, at 5:34 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

A few notes on the "form" only (not the= "content"):

HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actua= lly replacing 2617). Specifically, the GET and POST methods are defined in = RFC 7231.

Thanks, will update the reference there.


application/x-www-form-urlencoded refers to RFC 1866; the same media t= ype is said to be defined in HTML 4 in RFC 6749 and RFC 6750; and HTML 5 is= now a thing. RFC 7009 uses the media type too but doesn't refer to any oth= er RFC defining it.
I think this draft should either refer to RFC 6749, Appendix B <https://tools.ietf.= org/html/rfc6749#appendix-B> or to HTML 4 (for consistency with RFC6= 750) or to HTML 5 <http://xml2rfc.ietf.org/public/rfc/b= ibxml4/reference.W3C.REC-html5-20141028.xml> (because HTML 5 supersedes HTML 4).
I'd go with HTML 5, given that the IANA registration has been updated = in that sense (see http://www.w3.org/TR/2014/REC-html5-20141028/iana.html#application/x-www-fo= rm-urlencoded and https://www.iana.org/assignments/media-types/application/x-www-form-urlenco= ded); but given that RFC 6749, Appendix B algorithm is a subset of the = HTML 5 one (enforces the use of UTF-8, ignoring the special key "_char= set_"), and for consistency with other OAuth 2.0 specs, then maybe it'd be wiser to use the RFC 6749, Appendix B = algorithm.

I'll just go with HTML5 as that's the canonical spec for this mime typ= e now. No need to make it complicated, and any updates of 6749/6750 will li= kely do the same I would imagine.


References to sections of other specs form broken links in the rfcmarkup ve= rsion, because of the name of the other spec appearing between "sectio= n N of" and the bracketed reference. For example, in section 2.3, &quo= t;section 5.2 of OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]"

I've seen this happen before, and I think it's a tool artifact. <= /div>

There's a dangling "These parameters" in section 2.1. This l= acks at least a verb and a colon ("These parameters are:").

Thanks, good catch! I think I was in the middle of rewriting that part= when I got distracted.

 -- Justin


A last note on the content itself: +1, I don't think I have a= ny further comment to make.

On Thu Dec 04 2014 at 01:05:07 Richer, Justin P.= <jricher@mitre.o= rg> wrote:
Small update to the Introspection draft incorporating comments from the pas= t couple days. I haven't put together the IANA considerations section that = will tie the introspection claims to the JWT registry yet, but that's the i= ntent. Please check the diffs, read the new version, and continue to send comments to the list.

Thanks,
 -- Justin

On Dec 3, 2014, at 6:59 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>        Title          &nb= sp;: OAuth 2.0 Token Introspection
>        Author          : = Justin Richer
>       Filename        : draft-= ietf-oauth-introspection-02.txt
>       Pages          &nbs= p;: 11
>       Date           = ; : 2014-12-03
>
> Abstract:
>   This specification defines a method for a protected resour= ce to query
>   an OAuth 2.0 authorization server to determine the active = state of an
>   OAuth 2.0 token and to determine meta-information about th= is token.
>   OAuth 2.0 deployments can use this method to convey inform= ation about
>   the authorization context of the token from the authorizat= ion server
>   to the protected resource.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-intr= ospection/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-introspect= ion-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-in= trospection-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_0A1A0CA9C3424BA182ACA4D455A7FE16mitreorg_--