Why not just have a physical and logical endpoint options -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, January 23, 2013 7:47 AM To: Nat Sakimura Cc: Shiu Fun Poon; oauth@ietf.org 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 <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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
