Re: [OAUTH-WG] Concerning OAuth introspection

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 30 January 2013 22:31 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 8623621F8521 for <oauth@ietfa.amsl.com>; Wed, 30 Jan 2013 14:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.173
X-Spam-Level:
X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, 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 AZka7SeFUwcP for <oauth@ietfa.amsl.com>; Wed, 30 Jan 2013 14:31:03 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8299121F84E3 for <oauth@ietf.org>; Wed, 30 Jan 2013 14:31:02 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id e12so1597201wge.10 for <oauth@ietf.org>; Wed, 30 Jan 2013 14:31:01 -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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yfI5jsQjWSmChgtqJqMbX4NCC0tAe8vaUKHkik/kvGQ=; b=VrYr4M+juSpU+GXVk3ETvnE1CiS14tZRZMff7k0VVSqXGfRLQJ/9Khp19KazO6lzha baX1ZP4xceNmX5mJpVT6DmAU1OcLkexDi7/JZApzP36V/g0gqjvV6sf+9wQFVdBo9yD+ FHs5U5H9BOEV3QowS1vzSCmLc2eZ/aOHGOLu5A5q5RV/739bVt42gjfwsZv+ySZkQCjJ 3Z2hXRU0jptzkpnA7L7e/ZQAUxuuZ6WkJtIo65NQolQEpNCdmL7eKtkL0Du4da/tK7t2 Nb+Byf6hUPRPbyUDAqlEpZ4yevytEpWs4Ws43klNMt4WEvKA3N8+6hBKYKTaOp40V0rk SGeQ==
X-Received: by 10.194.19.170 with SMTP id g10mr11736711wje.56.1359585061323; Wed, 30 Jan 2013 14:31:01 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id gz3sm11880804wib.2.2013.01.30.14.30.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 14:31:00 -0800 (PST)
Message-ID: <51099F23.6010306@gmail.com>
Date: Wed, 30 Jan 2013 22:30:59 +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: Justin Richer <jricher@mitre.org>
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> <51001D61.1060000@mitre.org> <1b7dbe92b69e4e51bbb0012f06381756@BY2PR03MB041.namprd03.prod.outlook.com> <51002656.2050900@mitre.org> <CAHA4TYv7Fr=K4o3_NMni4_mvHMy6eV7ZuMvSO8wJU1k9SkK+GA@mail.gmail.com> <51093A3D.8030306@mitre.org> <68b9a48845df4dd2ade2536cc5a2dfb5@BY2PR03MB041.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943673EB05C@TK5EX14MBXC284.redmond.corp.microsoft.com> <510999D7.3000805@mitre.org> <51099D86.8070708@gmail.com> <51099E4C.9030403@mitre.org>
In-Reply-To: <51099E4C.9030403@mitre.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 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, 30 Jan 2013 22:31:04 -0000

On 30/01/13 22:27, Justin Richer wrote:
>
> On 01/30/2013 05:24 PM, Sergey Beryozkin wrote:
>> On 30/01/13 22:08, Justin Richer wrote:
>>> I completely agree that OAuth is not RESTful in any meaningful sense of
>>> the term (and have stated so several times in this thread).
>>
>> That is fine, this is not the issue, OAuth2 itself does not have to be
>> 'pure' but having individual bits from which the whole ecosystem is
>> build upon offering a RESTful interface when possible is very
>> important IMHO and in this case it is possible.
>>
>> What if the introspection endpoint would also offer an ability to
>> search ? Some query parameters will mean 'action', some - something
>> else, not cool really
>
> If a service were to offer other functionalities from the same URL as
> the token endpoint, and those other functionalities were switched by
> some kind of parameter, then this is well outside the definition of the
> introspection endpoint.
>
>>
>> Anyway, too much noise I guess from someone who is not even a member
>> of the working group, sorry :-)
>
> In the IETF, if you post to the list, you're in the working group.
> Welcome. :)

Nice :-), thanks

Cheers, Sergey

>
> -- Justin
>
>
>>
>> Thanks, Sergey
>>
>>> I'm not at
>>> all against using query parameters to change behaviors. That's why
>>> they're there. But I'll point out that the examples that you give are
>>> still *doing* the same thing qualitatively (returning a token, in this
>>> instance), even though the mechanisms for doing so are a bit different.
>>> They're still basically the same "action", and if there were a
>>> protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
>>> they would all have the same value for it. The client registration
>>> endpoint is different, because even though all the actions are *about*
>>> client registration, they're different actions. This is the whole
>>> purpose of the "operation=" parameter in the first place. That's the
>>> reason that I brought up this idea of defining them as separate
>>> endpoints.
>>>
>>> Regardless, the group seems about even split on one mode versus the
>>> other. As such, I'm inclined to leave the "operation=" parameter in
>>> place on the registration endpoint even though I don't prefer it.
>>>
>>> I still am very strongly against the idea of defining a protocol-wide
>>> "operation=" parameter for switching between all endpoints, even if it
>>> were possible to do such a thing.
>>>
>>> -- Justin
>>>
>>> On 01/30/2013 04:51 PM, Mike Jones wrote:
>>>>
>>>> I’ll note that the OAuth token endpoint changes behaviors depending
>>>> upon the grant_type and whether code or refresh_token parameters are
>>>> present. The first case is described at
>>>> http://tools.ietf.org/html/rfc6749#section-4.1.3. The second case is
>>>> described at http://tools.ietf.org/html/rfc6749#section-6.
>>>>
>>>> There are already a bunch of ways in which OAuth is not RESTful in a
>>>> strict sense of the term. It doesn’t seem to be a problem in practice.
>>>>
>>>> -- Mike
>>>>
>>>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>>>> Behalf Of *Anthony Nadalin
>>>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>>>> *To:* Justin Richer; Shiu Fun Poon
>>>> *Cc:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> I would not say that this is incompatible with OAUTH at all , as OAUTH
>>>> has a physical and logical endpoints. We had to live through the Web
>>>> Service endpoint nightmare were we had to have separate services, nuts
>>>>
>>>> *From:*Justin Richer [mailto:jricher@mitre.org]
>>>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>>>> *To:* Shiu Fun Poon
>>>> *Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
>>>> <mailto:oauth@ietf.org>
>>>> *Subject:* Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>> Hi.. Tony.. You are able to present this better than I do.
>>>>
>>>> Justin,
>>>>
>>>> Currently as it is, the spec is unflexible. So when I send a
>>>> request to an endpoint, the endpoint will need to have information
>>>> like /revoke, /introspection, and others. I can imagine the
>>>> documented usage of this will a pages long just to describe all
>>>> the endpoint that is needed to support an application. (so far,
>>>> /authz, /token, /introspection, /revoke, /.....), and this will be
>>>> painful in the multi-tenant environment.
>>>>
>>>> So why not allow the flexibility of using one endpoint /token
>>>> (example only), and make the caller to tell you want the caller
>>>> wants ? It can be an optional field, and a hint to the
>>>> authorization/token endpoint on what you want to do.
>>>>
>>>> This is incompatible with OAuth as it stands today, which defines the
>>>> auth endpoint and token endpoint as logically separate, and therefore
>>>> there is not a parameter defined that would allow for such
>>>> functionality switching.
>>>>
>>>> That said, an *installation* could implement it this way if they
>>>> wanted to, they'd just have to document the endpoints like this:
>>>>
>>>> token endpoint: /oauth?op=token
>>>> auth endpoint: /oauth?op=auth
>>>> introspection endpoint: /oauth?op=introspect
>>>> revocation endpoint: /oauth?op=revoke
>>>>
>>>> etc. The key difference here is that the "op=" parameter is *system
>>>> specific* and is *not* part of the spec itself. And I think that's a
>>>> good design to continue to follow.
>>>>
>>>> Right now, the registration endpoint is the only one that defines an
>>>> "operation" parameter, and I was positing the question of defining it
>>>> in terms of three different endpoints instead. Most of the time, these
>>>> endpoints will have different URLs, as outlined below, but specific
>>>> instances could use some kind of "operation" parameter if they
>>>> wanted to.
>>>>
>>>> Defining it as one endpoint with a switch parameter actually decreses
>>>> flexibility quite a lot, especially if you're talking about
>>>> dispatching to different kinds of functionality all together, which is
>>>> the use case you brought up. There are some places where that could
>>>> make sense, and the definition of different endpoints allows you to do
>>>> that in specific instances of a system without breaking the
>>>> assumptions of clients.
>>>>
>>>> What Tony was talking about was allowing something to be either three
>>>> different URLs *or* using a spec-defined "operation" parameter. That
>>>> suggestion is completely nuts, in my opinion.
>>>>
>>>> And it does not violate the rest/json guideline.
>>>>
>>>> Yes it absolutely does. The REST principle is that a URL represents
>>>> one entity and the HTTP verbs represent different actions on that
>>>> entity. Using a query parameter to switch is very much directly
>>>> against REST guidelines. Not to say that OAuth is RESTful -- it's not,
>>>> by a long shot. But it does follow many rest-like principles, the
>>>> endpoint definitions being one of them.
>>>>
>>>>
>>>> Even with oauth specification, it provides a hint on what is to
>>>> come, e.g. grant_type refresh_token, indicates you want to
>>>> exchange a valid refresh_token to an access_token. There is
>>>> something in the payload which tell you what you need to do. In
>>>> this case, there is nothing in the payload which indicate what is
>>>> expected.
>>>>
>>>> These are functionality switches on the same kind of action, not
>>>> dispatch to different actions. you still do
>>>> authentication/authorization at the auth endpoint, you still get
>>>> tokens from the token endpoint, etc.
>>>>
>>>> If you standard that now (on the optional field), there is a
>>>> chance that companies can implement this according to what will
>>>> work best for them, and we actually have a chance to get this
>>>> working between different products.
>>>>
>>>> It's too late to standardize that field in the core, which is really
>>>> where it would belong. But as it stands today, an OAuth client is
>>>> going to need to be able to handle separate URLs for each defined
>>>> endpoint already, so it can already handle the case where it happens
>>>> to be the same base URL with different operations.
>>>>
>>>> For what it's worth, what I was trying to get discussion on was
>>>> whether it made sense to make Dynamic Registration look like the rest
>>>> of OAuth with separate endpoints, or not.
>>>>
>>>> -- Justin
>>>>
>>>>
>>>> On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer <jricher@mitre.org
>>>> <mailto:jricher@mitre.org>> wrote:
>>>>
>>>> I am very confused, and I need someone to explain to me what I
>>>> am missing. Why won't it work to just pick one? What are
>>>> people "already stuck with" that this would affect? It's not
>>>> like we're trying to unseat a well-established protocol with a
>>>> wide installation base here.
>>>>
>>>> How will giving people the choice between:
>>>>
>>>> /oauth/register?operation=client_register
>>>> /oauth/register?operation=client_update
>>>> /oauth/register?operation=rotate_secret
>>>>
>>>>
>>>> and:
>>>>
>>>> /oauth/client_register
>>>> /oauth/client_update
>>>> /oauth/rotate_secret
>>>>
>>>>
>>>> help multitenancy? How does it even affect that use case?
>>>> Consider that the base URL for all of these is completely up
>>>> to the host environment (nothing is bound to the root URL).
>>>> Consider that clients still have to know what the URL (or
>>>> URLs) are, in either case. Consider that clients still need to
>>>> know how to manage all the parameters and responses.
>>>>
>>>> If anything, keeping it the way that it is with a single URL
>>>> could be argued to help multitenancy because setting up
>>>> routing to multiple URL endpoints can sometimes be problematic
>>>> in hosted environments. However, OAuth already defines a bunch
>>>> of endpoints, and we have to define at least one more with
>>>> this extension, so I'm not convinced that having three with
>>>> specific functions is really any different from having one
>>>> with three functions from a development, deployment, and
>>>> implementation perspective. I can tell you from experience
>>>> that in our own server code, the difference is trivial. (And
>>>> from OAuth1 experience, you can always have a query parameter
>>>> as part of your endpoint URL if you need to. You might hate
>>>> yourself for doing it that way, but nothing says your base URL
>>>> can't already have parameters on it. A client just needs to
>>>> know how to appropriately tack its parameters onto an existing
>>>> URL, and any HTTP client worth its salt will know how to
>>>> augment a query parameter set with new items.)
>>>>
>>>> The *real* difference between the two approaches is a
>>>> philosophical design one. The former overloads one URL with
>>>> multiple functions switched by a flag, the latter uses the URL
>>>> itself as an implicit flag. Under the hood, these could (and
>>>> in many cases will) be all served by the same chunks of code.
>>>> The only difference is how this switch in functionality is
>>>> presented.
>>>>
>>>>
>>>> With that said, can somebody please explain to me how allowing
>>>> *both* of these as options simultaneously (what I understand
>>>> Tony to be suggesting) is a good idea, or how multitenancy
>>>> even comes into play? Because I am completely not seeing how
>>>> these are related.
>>>>
>>>> Thanks,
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
>>>>
>>>> It will not work the way you have it, as people do multi-tendency
>>>> different and they are already stuck with the method that they have
>>>> chosen, so they need the flexability, to restrict this is nuts as
>>>> people won't use it.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: Justin Richer [mailto:jricher@mitre.org]
>>>>
>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>
>>>> To: Anthony Nadalin
>>>>
>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org <mailto:oauth@ietf.org>
>>>>
>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection
>>>>
>>>>
>>>>
>>>> I completely disagree with this assessment. Multi-tenancy will work
>>>> just fine (or even better) if everyone uses the same pattern.
>>>> Telling someone "it might be three different urls or it might be all
>>>> one url with a parameter" is just asking for a complete disaster.
>>>> What does the flexibility of allowing two approaches actually
>>>> accomplish?
>>>>
>>>>
>>>>
>>>> You can argue about the merits of either approach, but having both
>>>> as unspecified options for registration, which is meant to help
>>>> things get going in a cold-boot environment, is just plain nuts.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 01/23/2013 12:21 PM, Anthony Nadalin 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 <mailto: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>
>>>> [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 <mailto: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>
>>>> <mailto: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 <mailto:OAuth@ietf.org>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org <mailto: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
>