Re: [OAUTH-WG] Concerning OAuth introspection

Sergey Beryozkin <> Wed, 23 January 2013 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9568B21F8678 for <>; Wed, 23 Jan 2013 08:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Smc0DPCb1Kca for <>; Wed, 23 Jan 2013 08:34:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9E17421F866E for <>; Wed, 23 Jan 2013 08:34:42 -0800 (PST)
Received: by with SMTP id fe20so9062478lab.1 for <>; Wed, 23 Jan 2013 08:34:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=CG1cvQyJyPp9yUPdYoqFRHaIeNeyU0QVrK/VJXh+duo=; b=RTVSqhjCzTJr2YbsJpIYwIyhfodwyiQ6gWNRXRu/2rGs99NH1r2Si5bs7y5Kgvgsk5 N4P0sYOcn1KyODJH6XbePeZ7cOxtBO0ELfTGgNfKW/X/d+GhFCRu5+NM+KvvdCau5+ya etbZSpRfNQZ32LI93fqGj9gaIV7vPQF2gFS6x8Ug4AMDQv6+szqJlrcqhqiQq/iuHVkV g/4Zjjn2s6gyBaEXgMkVeEeiyZWnoCJAw4VJ9xPOnsdMSsNqEy3Qm0J4YL4rZIwSGuHt LPivjagiFuzx57la9EOFR51ZYlPy937ewpjZ6geKQTBkVIVN971ORN+aq4MiQ2ygOLb6 WVFw==
X-Received: by with SMTP id s3mr931894lba.113.1358958881589; Wed, 23 Jan 2013 08:34:41 -0800 (PST)
Received: from [] ([]) by with ESMTPS id o2sm8612399lby.11.2013. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 08:34:40 -0800 (PST)
Message-ID: <>
Date: Wed, 23 Jan 2013 16:34:39 +0000
From: Sergey Beryozkin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
References: <> <> <-6134323107835063788@unknownmsgid> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jan 2013 16:34:43 -0000

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<>  のメッセージ:
>>> (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 mailing list