Re: [OAUTH-WG] Concerning OAuth introspection

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 24 January 2013 11:02 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4121F856D for <oauth@ietfa.amsl.com>; Thu, 24 Jan 2013 03:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level:
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15f+kask-rly for <oauth@ietfa.amsl.com>; Thu, 24 Jan 2013 03:02:09 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3678021F85C0 for <oauth@ietf.org>; Thu, 24 Jan 2013 03:02:09 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id fo13so2838203lab.24 for <oauth@ietf.org>; Thu, 24 Jan 2013 03:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NGFlyRZ6zHtdkrbeCgQsbgUu+mNrTl1NmPJ/BXHOlH4=; b=JJgVX7VIn3eGhGdNPuSZ/dCYTTnKY4qzZ4u4NzlM8T4A+HwhHcTqjET/V3dPdLrWov Eg//JccysnYPDxbN2m0FgMvGY/RG7eHeJbSbOSIT/bKdmy/nB3SEWurlHM+3nlqltxzu ei/Y8y5IoNxqPAFMH4/i0/7nNftRegZPzOoJfVvqelmTuMVtknIFisqpq1oBBI5x53qm RCwKn/+rBtD0olMehHCsFfAYcRiGQhkrtM5ZEgTa196Lt4U8UgiVpUUJBL7ujYOPSiEs 1E8u5tmZSTSlIH0w9i14Dq2E4rsxC9Peufayriiw1zE3b6bxQMJC6D4/YTJ9GwPytbOd Z+aw==
X-Received: by 10.112.17.3 with SMTP id k3mr630444lbd.42.1359025328030; Thu, 24 Jan 2013 03:02:08 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id bf3sm9460476lbb.16.2013.01.24.03.02.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 03:02:07 -0800 (PST)
Message-ID: <510114AD.1080708@gmail.com>
Date: Thu, 24 Jan 2013 11:02:05 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <CAHA4TYtCG+o0AZzh9e-3nb6gKLaWFeJuQfBxHVmUDH5Aj+TdpQ@mail.gmail.com> <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <5100111F.1090304@gmail.com> <622465D8-B15F-4516-A8D5-6559088BBD6E@xmlgrrl.com> <OFCE17A9F3.B4FE6513-ON85257AFC.0066892E-85257AFC.00669C86@us.ibm.com> <EBFE55AC-076A-409B-AFA1-4CD9E3A8F4A8@oracle.com> <255D2C5E-22CF-43BD-9789-0E6D25B5B7D8@xmlgrrl.com> <5100466F.3030506@mitre.org>
In-Reply-To: <5100466F.3030506@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 24 Jan 2013 11:02:11 -0000

On 23/01/13 20:22, Justin Richer wrote:
> While Eve is right in principle, I think it's better for everyone if
> things remain consistent across different endpoints where possible. This
> is why registration now does form input and json output, for instance.
> Still simple, not as RESTy, but ultimately REST-friendly, which is all
> OAuth ever sought to be.

+1; personally I've no problems for example working with production 
quality WS services supporting a higher-level RS application/services,
but indeed it is important to attempt to keep it as close as possible to 
the original idea of OAuth being REST friendly

thanks, Sergey

>
> -- Justin
>
> On 01/23/2013 03:12 PM, Eve Maler wrote:
>> I'd say OAuth is an HTTP security mechanism or protocol (50,000-foot view). To the extent that it, or its constituent parts, defines endpoints, it also is a security API or set of APIs (10,000-foot view). Since its endpoints use HTTP, this gives the opportunity to ask the question: how RESTful should its APIs be? I'm hearing one firm design principle:
>>
>> - Make new constituent parts be consonant with the rest of OAuth design
>>
>> And a couple of competing soft design principles:
>>
>> - Make it easy to develop endpoints (especially but not exclusively client-side)
>> - Make it flexible to accommodate lots of situations
>>
>> I'm suggesting considering another one, possibly ranking it lower than others:
>>
>> - Make its endpoints operate in a RESTful, resource-oriented way
>>
>> (While OAuth hasn't gone through this exercise, UMA has, and we included a DP about RESTfulness; you can see the results here:http://kantarainitiative.org/confluence/display/uma/UMA+Requirements  That's why we defined draft-hardjono-oauth-resource-reg the way we did.)
>>
>> The dyn reg spec is a kind of bootstrapping spec, so one can expect that it would be out of the REST mainstream in any case -- its credential provisioning function is sui generis. But the functions to create and update metadata look like pretty ordinary CRUD functions that usually correspond to various POST or PUT patterns in REST. If the client metadata were conceived of as a true web resource, it's not wildly out of left field to consider defining their creation and management in high-REST-maturity ways, and even imagine what (say) DELETE, PATCH, and GET might mean, even if not allowed in the spec today.
>>
>> (Justin, I promise I'm not trying to give you a hard time. :-)
>>
>> 	Eve
>>
>> On 23 Jan 2013, at 10:54 AM, Phil Hunt<phil.hunt@oracle.com>  wrote:
>>
>>> My understanding is OAuth is an HTTP protocol.  It is not intended to be REST specific or by implication be RESTful.
>>>
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote:
>>>
>>>>> On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>>> +1
>>>>
>>>>    -- Todd
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From:        Eve Maler<eve@xmlgrrl.com>
>>>> To:        Sergey Beryozkin<sberyozkin@gmail.com>om>,
>>>> Cc:        Paul Bryan<email@pbryan.net>,"oauth@ietf.org WG"  <oauth@ietf.org>
>>>> Date:        01/23/2013 12:18 PM
>>>> Subject:        Re: [OAUTH-WG] Concerning OAuth introspection
>>>> Sent by:oauth-bounces@ietf.org
>>>>
>>>>
>>>>
>>>> Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
>>>>
>>>> If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used:
>>>>
>>>> http://tools.ietf.org/html/draft-pbryan-http-json-resource-03
>>>>
>>>> With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction.
>>>>
>>>>                  Eve
>>>>
>>>> On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin<sberyozkin@gmail.com>  wrote:
>>>>
>>>>> On 23/01/13 15:47, Justin Richer wrote:
>>>>>> Which brings up an interesting question for the Registration doc: right
>>>>>> now, it's set up as a single endpoint with three operations. We could
>>>>>> instead define three endpoints for the different operations.
>>>>>>
>>>>>> I've not been keen to make that deep of a cutting change to it, but it
>>>>>> would certainly be cleaner and more RESTful API design. What do others
>>>>>> think?
>>>>>>
>>>>> IMHO the purity should be balanced against the practicality/simplicity
>>>>> of the implementation.
>>>>> Talking about 3 endpoints at the spec level may be treated as the exact
>>>>> requirement to have 3 separate application endpoints for the single type
>>>>> of activity, the registration. Can the spec be re-worded such that
>>>>> "resources" are used instead of endpoints or similar, example, "resource
>>>>> available at /a will support the following, at /b - something else", or
>>>>> may be something similar,  thus it will read better too from the design
>>>>> point of view, and let implementers to use 1 endpoint or 3 ones,
>>>>> whichever way they prefer it
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>> On 01/22/2013 08:05 PM, Nat Sakimura wrote:
>>>>>>> "Action" goes against REST principle.
>>>>>>> I do not think it is a good idea.
>>>>>>>
>>>>>>> =nat via iPhone
>>>>>>>
>>>>>>> Jan 23, 2013 4:00、Justin Richer<jricher@mitre.org>   のメッセージ:
>>>>>>>
>>>>>>>> (CC'ing the working group)
>>>>>>>>
>>>>>>>> I'm not sure what the "action/operation" flag would accomplish. The idea behind having different endpoints in OAuth is that they each do different kinds of things. The only "action/operation" that I had envisioned for the introspection endpoint is introspection itself: "I have a token, what does it mean?"
>>>>>>>>
>>>>>>>> Note that client_id and client_secret *can* already be used at this endpoint if the server supports that as part of their client credentials setup. The examples use HTTP Basic with client id and secret right now. Basically, the client can authenticate however it wants, including any of the methods that OAuth2 allows on the token endpoint. It could also authenticate with an access token. At least, that's the intent of the introspection draft -- if that's unclear, I'd be happy to accept suggested changes to clarify this text.
>>>>>>>>
>>>>>>>>   -- Justin
>>>>>>>>
>>>>>>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>>>>>>>> Justin,
>>>>>>>>>
>>>>>>>>> This spec is looking good..
>>>>>>>>>
>>>>>>>>> One thing I would like to recommend is to add "action"/"operation" to the request.  (and potentially add client_id and client_secret)
>>>>>>>>>
>>>>>>>>> So the request will be like :
>>>>>>>>> token                                             REQUIRED
>>>>>>>>> operation (wording to be determine)  OPTIONAL inquire (default) | revoke ...
>>>>>>>>> resource_id                                    OPTIONAL
>>>>>>>>> client_id                                         OPTIONAL
>>>>>>>>> client_secret                                   OPTIONAL
>>>>>>>>>
>>>>>>>>> And for the OAuth client information, it should be an optional parameter (in case it is a public client or client is authenticated with SSL mutual authentication).
>>>>>>>>>
>>>>>>>>> Please consider.
>>>>>>>>>
>>>>>>>>> ShiuFun
>>>>
>>>> Eve Malerhttp://www.xmlgrrl.com/blog
>>>> +1 425 345 6756http://www.twitter.com/xmlgrrl
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> Eve Malerhttp://www.xmlgrrl.com/blog
>> +1 425 345 6756http://www.twitter.com/xmlgrrl
>>
>>
>>
>>
>> _______________________________________________
>> 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