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

Sergey Beryozkin <sberyozkin@gmail.com> Tue, 09 December 2014 15:59 UTC

Return-Path: <sberyozkin@gmail.com>
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 DDE111A0364 for <oauth@ietfa.amsl.com>; Tue, 9 Dec 2014 07:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 O7rmAtIjEHVG for <oauth@ietfa.amsl.com>; Tue, 9 Dec 2014 07:59:50 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C050C1A0369 for <oauth@ietf.org>; Tue, 9 Dec 2014 07:59:49 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ex7so2220358wid.0 for <oauth@ietf.org>; Tue, 09 Dec 2014 07:59:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G4KUT1yL5Iwb6zfcCVaKR8KOxeivfVsQFyoMzKJdRlc=; b=oIBkM5udE1aD3PlnUerWM6hxhcMp3/2cTDy/v+hl9UpaHK5IG29QutK8R9BJ6rCO1L 6AOH9fudXGiW5esyn/x/1Nz2Qb4rOORSfmnjz2jx/DuhRtCYOtc1ZQaraG5boRokJmXf AvmQBlmAZlIF+PKDibXSsy6spiTPWH7vP7YAbYD4mpj1dn7L3fI12ghBjjK9zrB6JNvp WTq9/M2WfRACUiBI8rJrrrvGHZ7GUq7XuAkbvffybkaRqIM73cEgg0p0qhORa+PqiC5N IDJAfbDOFiY5DpbiRRpLFmJA5geVLV44nocxz5eFM7yRqUI32TQSbV0I5d5qTrAXK94i s9VA==
X-Received: by 10.194.24.103 with SMTP id t7mr6146148wjf.15.1418140788382; Tue, 09 Dec 2014 07:59:48 -0800 (PST)
Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id ei5sm12016193wid.2.2014.12.09.07.59.47 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 07:59:47 -0800 (PST)
Message-ID: <54871C72.60006@gmail.com>
Date: Tue, 09 Dec 2014 15:59:46 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <20141207033213.26273.31418.idtracker@ietfa.amsl.com> <1416B7A5-2CCE-4E6F-B9CB-56C606076DD3@mit.edu> <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu>
In-Reply-To: <32999E7E-459F-44C1-916C-67318C3968F8@mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h_1w7gQuUg2jB-nBDXbhhaq-NUU
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 15:59:53 -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



On 07/12/14 03:38, Justin Richer wrote:
> … 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
> On Dec 6, 2014, at 10:34 PM, Justin Richer <jricher@mit.edu> wrote:
>
>> 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, internet-drafts@ietf.org wrote:
>>
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>