Registration has to work in a multi-tenant environment so flexibility is needed
-----Original Message----- From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, January 23, 2013 9:18 AM To: Anthony Nadalin Cc: Nat Sakimura; Shiu Fun Poon; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerning OAuth introspection Because then nobody would know how to actually use the thing. In my opinion, this is a key place where this kind of flexibility is a very bad thing. Registration needs to work one fairly predictable way. -- Justin On 01/23/2013 12:14 PM, Anthony Nadalin wrote: > 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
