"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
