Re: [OAUTH-WG] Concerning OAuth introspection

[Sergey Beryozkin <[e-mail]>]

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:*[e-mail] [mailto:[e-mail]] *On
>>>> Behalf Of *Anthony Nadalin
>>>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>>>> *To:* Justin Richer; Shiu Fun Poon
>>>> *Cc:* [e-mail]
>>>> *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:[e-mail]]
>>>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>>>> *To:* Shiu Fun Poon
>>>> *Cc:* Anthony Nadalin; Nat Sakimura; [e-mail]
>>>> <mailto:[e-mail]>
>>>> *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 <[e-mail]
>>>> <mailto:[e-mail]>> 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:[e-mail]]
>>>>
>>>> Sent: Wednesday, January 23, 2013 9:27 AM
>>>>
>>>> To: Anthony Nadalin
>>>>
>>>> Cc: Nat Sakimura; Shiu Fun Poon;[e-mail] <mailto:[e-mail]>
>>>>
>>>> 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:[e-mail]]
>>>>
>>>> Sent: Wednesday, January 23, 2013 9:18 AM
>>>>
>>>> To: Anthony Nadalin
>>>>
>>>> Cc: Nat Sakimura; Shiu Fun Poon;[e-mail] <mailto:[e-mail]>
>>>>
>>>> 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:[e-mail] <mailto:[e-mail]>
>>>> [mailto:[e-mail]] On
>>>>
>>>> Behalf Of Justin Richer
>>>>
>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>>
>>>> To: Nat Sakimura
>>>>
>>>> Cc: Shiu Fun Poon;[e-mail] <mailto:[e-mail]>
>>>>
>>>> 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<[e-mail]>
>>>> <mailto:[e-mail]> のメッセージ:
>>>>
>>>>
>>>>
>>>> (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
>>>>
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>