Re: [OAUTH-WG] Concerning OAuth introspection

[Todd W Lainhart <[e-mail]>]

> On the other hand, it's a useful exercise to imagine how much more 
benefit could potentially be gotten "for free" if we look at it through a 
pure-REST lens, not just with what's already been specified but the whole 
picture.

+1

  -- Todd







From:   Eve Maler <[e-mail]>
To:     Sergey Beryozkin <[e-mail]>, 
Cc:     Paul Bryan <[e-mail]>, "[e-mail] WG" 
<[e-mail]>
Date:   01/23/2013 12:18 PM
Subject:        Re: [OAUTH-WG] Concerning OAuth introspection
Sent by:        [e-mail]



Agreed that REST purity may come at a cost that's too high. On the other 
hand, it's a useful exercise to imagine how much more benefit could 
potentially be gotten "for free" if we look at it through a pure-REST 
lens, not just with what's already been specified but the whole picture.

If what you're registering is a client descriptor, then creating a new 
one, updating an existing one, deleting, and even patching could come for 
free if something like the following framework is used:

http://tools.ietf.org/html/draft-pbryan-http-json-resource-03

With standard libraries possibly floating around to support this framework 
(I think Paul B wrote one; maybe he open-sourced it?), it starts to become 
a lot cheaper to support client registration on both sides of the 
interaction.

                 Eve

On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <[e-mail]> wrote:

> On 23/01/13 15:47, Justin Richer wrote:
>> 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?
>> 
> IMHO the purity should be balanced against the practicality/simplicity
> of the implementation.
> Talking about 3 endpoints at the spec level may be treated as the exact
> requirement to have 3 separate application endpoints for the single type
> of activity, the registration. Can the spec be re-worded such that
> "resources" are used instead of endpoints or similar, example, "resource
> available at /a will support the following, at /b - something else", or
> may be something similar,  thus it will read better too from the design
> point of view, and let implementers to use 1 endpoint or 3 ones,
> whichever way they prefer it
> 
> Thanks, Sergey
> 
>> -- 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
> 


Eve Maler                                  http://www.xmlgrrl.com/blog
[phone]                         http://www.twitter.com/xmlgrrl

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth