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 <jric...@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
>> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to