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

From: [email-masked]
Date: Sat, 06 Dec 2014 19:32:13 -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-03.txt
	Pages           : 12
	Date            : 2014-12-06

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-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03

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: Justin Richer <[email-masked]>
Date: Sat, 6 Dec 2014 22:34:15 -0500

Small update to introspection, now the returned values reference the JWT claims specifically (as requested). Also updated the HTTP and HTML references.

No normative changes.

 — Justin

On Dec 6, 2014, at 10:32 PM, [email-masked] wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Sat, 6 Dec 2014 22:38:16 -0500

… and I just noticed hanging text at the top of section 2.2 due to the JWT claims edit. My working copy has removed the extraneous text “Several of these”.

Also, as always, latest XML is up on GitHub:

https://github.com/jricher/oauth-spec

— Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 09 Dec 2014 15:59:46 +0000

Hi Justin

IMHO the section 2.1 [1] requires more work.

First, "resource_id". Having such a parameter does not add anything to 
the interoperability side of the spec. It is a "server specific 
string..." which may be anything and as such a 3rd party AS is unlikely 
to do any work around this parameter unless both RS and AS are from the 
same provider.
IMHO it either has to be dropped, the text "The endpoint MAY allow other 
parameters to provide further context to the query" covers whatever else 
that server may want to add or attach some more specific meaning to it. 
Besides that, the MUST authentication requirement covers properly a 
possible RS identification requirement.
I'd rather have a "resource_id" representing an RS base address or 
better, a current request URI, which in combination with an optional 
client_ip can help AS to make a more specific introspection action.

I also suggested to promote a parameter like "client_ip". Just referring 
to a possibility of RS reporting a client IP adress does not help 
improving the interoperability either with respect to RS and AS offered 
by different providers working with a client IP property

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 19 Dec 2014 23:13:02 +0000

Hi Justin

returning a client public/confidential status may be useful in case RS 
chooses to allow for a more restricted access to public clients in cases 
where both public & private clients are accepted

Thanks, Sergey
On 09/12/14 15:59, Sergey Beryozkin wrote:
> [1]
> http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1
>
>
>
>> … and I just noticed hanging text at the top of section 2.2 due to the
>> JWT claims edit. My working copy has removed the extraneous text
>> “Several of these”.
>>
>>> Small update to introspection, now the returned values reference the
>>> JWT claims specifically (as requested). Also updated the HTTP and
>>> HTML references.
>>>
>>> No normative changes.
>>>
>>> — Justin
>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Dec 2014 19:50:25 -0500

There’s a whole host of client information that “might” be helpful to an RS, but I don’t think it would be helpful for us to try to determine all of that information since, as far as I know, there is no implementation today that is passing that kind of information over. Especially consider that whether the client is public or not has no bearing over how the token is presented to the RS.

If in the future someone wants to standardize that kind of information as an extension to introspection, the data model used in Dynamic Registration could be referenced for this purpose. But something like that very much belongs in an extension after there are at least a couple implementations of it.

 — Justin

> On Dec 19, 2014, at 6:13 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi Justin
> 
> returning a client public/confidential status may be useful in case RS chooses to allow for a more restricted access to public clients in cases where both public & private clients are accepted
> 
> Thanks, Sergey