Rudely responding to myself: I'm not saying this approach should definitely be
taken, just that it's a good idea to spend 15 minutes looking at the benefits
and downsides of it vs. the current laser-focus approach.
Eve
On 23 Jan 2013, at 9:28 AM, Eve Maler <[email protected]> wrote:
> Tony took the words right out of my mouth. :-) Or, at least, the moment
> someone expresses an actual need for the next piece of flexibility (beyond
> "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on
> the slope towards maybe benefiting from enabling more and more of the HTTP
> verbs where only one or two made sense before. One way to do this is to work
> within a pure-REST framework but say that only POST and GET are supported,
> with all others producing an error. Over time, if DELETE is needed, it's
> easier to turn it on.
>
> Eve
>
> * "The only thing worse than generalizing from one example is generalizing
> from no examples at all." Not sure if Tony is expressing an actual need or
> not.
>
> On 23 Jan 2013, at 9:21 AM, Anthony Nadalin <[email protected]> wrote:
>
>> Registration has to work in a multi-tenant environment so flexibility is
>> needed
>>
>> -----Original Message-----
>> From: Justin Richer [mailto:[email protected]]
>> Sent: Wednesday, January 23, 2013 9:18 AM
>> To: Anthony Nadalin
>> Cc: Nat Sakimura; Shiu Fun Poon; [email protected]
>> 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: [email protected] [mailto:[email protected]] On Behalf
>>> Of Justin Richer
>>> Sent: Wednesday, January 23, 2013 7:47 AM
>>> To: Nat Sakimura
>>> Cc: Shiu Fun Poon; [email protected]
>>> 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 <[email protected]> のメッセージ:
>>>>
>>>>> (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
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
