But it's already not a fully RESTful setup, and it's not really meant to be as it stands. I realize that's how the original UMA registration spec did things, but the rest of OAuth doesn't work that way. I would rather it be parallel with the rest of the framework, all ideals aside.
Which brings us back to my original point: OAuth2 does a pretty good job at splitting up different endpoints for different functions. That's what I'm asking here, more than anything else. Do we want to define three endpoints: - client registration endpoint - client update endpoint - client secret rotation endpoint As opposed to a single registration endpoint with a switch? -- Justin On 01/23/2013 12:28 PM, Eve Maler wrote: > Tony took the words right out of my mouth. :-) Or, at least, the moment > someone expresses an actual need for the next piece of flexibility (beyond > "Wouldn't it be cool if..."* to "I have a customer that needs..."), you're on > the slope towards maybe benefiting from enabling more and more of the HTTP > verbs where only one or two made sense before. One way to do this is to work > within a pure-REST framework but say that only POST and GET are supported, > with all others producing an error. Over time, if DELETE is needed, it's > easier to turn it on. > > Eve > > * "The only thing worse than generalizing from one example is generalizing > from no examples at all." Not sure if Tony is expressing an actual need or > not. > > On 23 Jan 2013, at 9:21 AM, Anthony Nadalin <tony...@microsoft.com> wrote: > >> 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 > > 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
