Re: [OAUTH-WG] Concerning OAuth introspection

Nat Sakimura <sakimura@gmail.com> Wed, 23 January 2013 01:05 UTC

Return-Path: <sakimura@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 60B3321F874F for <oauth@ietfa.amsl.com>; Tue, 22 Jan 2013 17:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
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 f3xKrevXhFYa for <oauth@ietfa.amsl.com>; Tue, 22 Jan 2013 17:05:35 -0800 (PST)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id A590221F8830 for <oauth@ietf.org>; Tue, 22 Jan 2013 17:05:35 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id e53so3660772eek.26 for <oauth@ietf.org>; Tue, 22 Jan 2013 17:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=VavsTOljQ6ahLYy3erngqv0BLJhoISZbbNbjy4ytfKA=; b=MRHTI0f+u7Lre8fLxd7Hl+XY0Kl2vcK0R9sW60mIVyTHgCgpTctVRmD2tTMsc+O7xN 7RabRFy2mfKygyvM13vM6G5NSC+PiSDc56w/PadJUb0VJGsTGhpOPv5o4ZhpoE3pUg9t GqPi2Cz1KXmOat5Ir31+npOKzR25icGb9qJ28Th/rIcxnKkJCfVnR8hRye0CkNF85j94 bfTZGr+ZInLlQC065VQGq1MTuDvtPVGjlsjC0i7PgbGZRCL5R02hzP0jqivHu4codNBE phlLyP31xdHWv/iS4UZ3OMKhjtyawlnoCueR5Vr2ZQRjEogaL7SFQG7FP8vPBL+B9U3C EuZQ==
X-Received: by 10.14.3.195 with SMTP id 43mr78331917eeh.36.1358903134677; Tue, 22 Jan 2013 17:05:34 -0800 (PST)
References: <CAHA4TYtCG+o0AZzh9e-3nb6gKLaWFeJuQfBxHVmUDH5Aj+TdpQ@mail.gmail.com> <50FEE1BF.5050200@mitre.org>
From: Nat Sakimura <sakimura@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <50FEE1BF.5050200@mitre.org>
Date: Wed, 23 Jan 2013 10:05:32 +0900
Message-ID: <-6134323107835063788@unknownmsgid>
To: Justin Richer <jricher@mitre.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: base64
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 01:05:36 -0000

"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