My understanding is OAuth is an HTTP protocol. It is not intended to be REST specific or by implication be RESTful.
@independentid www.independentid.com phil.h...@oracle.com On 2013-01-23, at 10:40 AM, Todd W Lainhart wrote: > > 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...@xmlgrrl.com> > To: Sergey Beryozkin <sberyoz...@gmail.com>, > Cc: Paul Bryan <em...@pbryan.net>, "oauth@ietf.org WG" > <oauth@ietf.org> > Date: 01/23/2013 12:18 PM > Subject: Re: [OAUTH-WG] Concerning OAuth introspection > Sent by: oauth-boun...@ietf.org > > > > 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 <sberyoz...@gmail.com> 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<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 > > > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > _______________________________________________ > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
