Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt

From: [email-masked]
Date: Wed, 03 Dec 2014 15:59:37 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 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=draft-ietf-oauth-introspection-02

Please note that it may take a couple of minutes from the time of submission
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/

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Dec 2014 00:04:47 +0000

Small update to the Introspection draft incorporating comments from the past 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 intent. 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, [email-masked] wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 04 Dec 2014 10:34:53 +0000

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
actually replacing 2617). Specifically, the GET and POST methods are
defined in RFC 7231.

application/x-www-form-urlencoded refers to RFC 1866; the same media type
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 other
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 RFC6750) or to HTML 5 <
http://xml2rfc.ietf.org/public/rfc/bibxml4/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-form-urlencoded
and
https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded);
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 "_charset_"), and for
consistency with other OAuth 2.0 specs, then maybe it'd be wiser to use the
RFC 6749, Appendix B algorithm.

References to sections of other specs form broken links in the rfcmarkup
version, because of the name of the other spec appearing between "section N
of" and the bracketed reference. For example, in section 2.3, "section 5.2
of OAuth 2.0 [RFC6749]" should instead read "section 5.2 of [RFC6749]"

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

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

On Thu Dec 04 2014 at 01:05:07 Richer, Justin P. <[email-masked]> wrote:

> Small update to the Introspection draft incorporating comments from the
> past 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 intent. Please check the diffs, read the new version, and continue to
> send comments to the list.
>
> Thanks,
>  -- Justin
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Dec 2014 15:04:44 +0000

On Dec 4, 2014, at 5:34 AM, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:

HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actually 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 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 other 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 RFC6750) or to HTML 5 <http://xml2rfc.ietf.org/public/rfc/bibxml4/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-form-urlencoded and https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded); 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 "_charset_"), 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 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 version, because of the name of the other spec appearing between "section N of" and the bracketed reference. For example, in section 2.3, "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.

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 comment to make.

On Thu Dec 04 2014 at 01:05:07 Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:
Small update to the Introspection draft incorporating comments from the past 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 intent. 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, [email-masked]<mailto:[email-masked]> wrote:

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth