Re: [OAUTH-WG] Concerning OAuth introspection

[Sergey Beryozkin <[e-mail]>]

On 23/01/13 18:05, Justin Richer 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

I like this most, would rename it to say

/oauth/client/registration
or
/oauth/client-registration

etc

and reword the spec such that it will let those who implement do it with 
one endpoint or many, whatever is preferred

Cheers, Sergey

>
>
> 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]
>> 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]
>>> 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]] On
>>>> Behalf Of Justin Richer
>>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>>> To: Nat Sakimura
>>>> Cc: Shiu Fun Poon;[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]>  のメッセージ:
>>>>>
>>>>>> (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]
>>>>>> 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