Re: [OAUTH-WG] Concerning OAuth introspection

Eve Maler <eve@xmlgrrl.com> Wed, 23 January 2013 17:28 UTC

Return-Path: <eve@xmlgrrl.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 E2BB121F85FD for <oauth@ietfa.amsl.com>; Wed, 23 Jan 2013 09:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.68
X-Spam-Level:
X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, 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 kCqGC3aYVAu9 for <oauth@ietfa.amsl.com>; Wed, 23 Jan 2013 09:28:19 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFA21F85D0 for <oauth@ietf.org>; Wed, 23 Jan 2013 09:28:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id C619B9A71C4; Wed, 23 Jan 2013 09:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4SQgHPhtUgn; Wed, 23 Jan 2013 09:28:14 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 617F09A71A7; Wed, 23 Jan 2013 09:28:14 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=iso-2022-jp
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com>
Date: Wed, 23 Jan 2013 09:28:13 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6F13E85-C7F9-49DE-9CC3-C045DEC22003@xmlgrrl.com>
References: <CAHA4TYtCG+o0AZzh9e-3nb6gKLaWFeJuQfBxHVmUDH5Aj+TdpQ@mail.gmail.com> <50FEE1BF.5050200@mitre.org> <-6134323107835063788@unknownmsgid> <510005F5.6000004@mitre.org> <4a060479b5374e8ba58d3c9e1b15d917@BY2PR03MB041.namprd03.prod.outlook.com> <51001B5C.80407@mitre.org> <9a1d3f9d095e4f14b55ff99c9cf1799e@BY2PR03MB041.namprd03.prod.outlook.com>
To: Anthony Nadalin <tonynad@microsoft.com>
X-Mailer: Apple Mail (2.1499)
Cc: Shiu Fun Poon <shiufunpoon@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
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: Wed, 23 Jan 2013 17:28:20 -0000

Tony took the words right out of my mouth. :-) Or, at least, the moment someone expresses an actual need for the next piece of flexibility (beyond "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on the slope towards maybe benefiting from enabling more and more of the HTTP verbs where only one or two made sense before. One way to do this is to work within a pure-REST framework but say that only POST and GET are supported, with all others producing an error. Over time, if DELETE is needed, it's easier to turn it on.

	Eve

* "The only thing worse than generalizing from one example is generalizing from no examples at all." Not sure if Tony is expressing an actual need or not.

On 23 Jan 2013, at 9:21 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

> Registration has to work in a multi-tenant environment  so flexibility is needed
> 
> -----Original Message-----
> From: Justin Richer [mailto:jricher@mitre.org] 
> Sent: Wednesday, January 23, 2013 9:18 AM
> To: Anthony Nadalin
> Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
> 
> Because then nobody would know how to actually use the thing.
> 
> In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way.
> 
> -- Justin
> 
> On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
>> Why not just have a physical and logical endpoint options
>> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf 
>> Of Justin Richer
>> Sent: Wednesday, January 23, 2013 7:47 AM
>> To: Nat Sakimura
>> Cc: Shiu Fun Poon; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>> 
>> 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?
>> 
>> -- 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
>>>> _______________________________________________
>>>> 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


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl