That is better, but I don't see an advantage to that over using a query parameter.
They are equally restful or not as the case may be. To be more restful I think you want a single endpoint using HTTP verbs. POST /reg_endpoint?paramaters … -> register PUT /reg_endpoint?client_id=12345¶maters -> update PUT /reg_endpoint?client_id=12345&rotate_secret=true The downside is developers understanding On 2013-01-30, at 1:17 PM, Justin Richer <jric...@mitre.org> wrote: > > On 01/30/2013 10:55 AM, John Bradley wrote: >> My feeling was that letting the registration endpoint be a single URL (any >> url) and using query paramaters was easer for servers and clients. >> >> Saying take the base URI for the registration endpoint and append these >> paths to it to do different operations seems more likely to go wrong fro >> developers. > Right, and to clarify, this isn't what I was saying. The spec wouldn't > specify the path at all, just say that they're three different endpoint URLs. > The same way that we specify that the auth endpoint and token endpoint are > different URLs. > > I think my example might have been misleading. The URLs could just as easily > be: > > client_register -> /register_a_new_client > rotate_secret -> /client/go_get_a_secret_or_something > client_update-> /maintenance/update_client_information > > > >> >> Allowing both bath and query parameters is the worst option. >> >> I am sympathetic with using POST and PUT and perhaps GET but I worry about >> OAuth developers not getting it. >> >> I also don't get Tony's point about multi tenancy. If each tenant can have >> there own registration endpoint I don't see a problem beyond finding the >> endpoint and that is what we have WF for. > Exactly. And to Bill's point in another thread, we could also register a link > type for each endpoint to help facilitate discovery: > http://tools.ietf.org/html/draft-wmills-oauth-lrdd-06 > > -- Justin > >> >> John B. >> >> On 2013-01-24, at 11:26 AM, Justin Richer <jric...@mitre.org> wrote: >> >>> On 01/24/2013 05:56 AM, Sergey Beryozkin wrote: >>>> I like this most, would rename it to say >>>> >>>> /oauth/client/registration >>>> or >>>> /oauth/client-registration >>>> >>>> etc >>>> >>>> and reword the spec such that it will let those who implement do it with >>>> one endpoint or many, whatever is preferred >>>> >>> That's the whole point of this discussion -- I don't believe you can have >>> it both ways. >>> >>> In one way, you say there are three endpoints and, if you're keeping with >>> the rest of OAuth, you don't give them official URL patterns that they must >>> follow. How the client gets those endpoints is up to discovery or >>> configuration, but the client has an internal map from each bit of >>> functionality to a particular URL that's specific to the service, much in >>> the same way that the client today has to map the authorization and token >>> endpoints. In the other method, you've got one endpoint that the client >>> sends a well-defined parameter to in order to accomplish the same goal. >>> >>> So if you allow both at once, does a client send the "operation" parameter >>> or not? Is it looking for one url or three to store in its configuration? I >>> don't think this level of flexibility buys you anything useful, and I >>> strongly believe that it will deeply hurt the functionality of dynamic >>> registration if it's allowed. >>> >>> As it stands today, you can still make the URL whatever you want. If we >>> went with three endpoints you could also make those URLs whatever you >>> wanted. Nobody has yet pointed out to me what the actual benefit is of >>> making both valid. >>> >>> I personally prefer the method of three endpoint URLs because it's cleaner >>> and semantically equivalent, but I am hesitant to change that behavior >>> unless there's strong working group support for it. I haven't seen real >>> support for it yet -- it's not a good call to make it fully RESTful, and >>> it's not a good call to leave it undefined. A client MUST have a very clear >>> recipe of what to do on startup for this to work in the wild. >>> >>> -- Justin >>> >>>>> >>>>> help multitenancy? How does it even affect that use case? Consider that >>>>> the base URL for all of these is completely up to the host environment >>>>> (nothing is bound to the root URL). Consider that clients still have to >>>>> know what the URL (or URLs) are, in either case. Consider that clients >>>>> still need to know how to manage all the parameters and responses. >>>>> >>>>> If anything, keeping it the way that it is with a single URL could be >>>>> argued to help multitenancy because setting up routing to multiple URL >>>>> endpoints can sometimes be problematic in hosted environments. However, >>>>> OAuth already defines a bunch of endpoints, and we have to define at >>>>> least one more with this extension, so I'm not convinced that having >>>>> three with specific functions is really any different from having one >>>>> with three functions from a development, deployment, and implementation >>>>> perspective. I can tell you from experience that in our own server code, >>>>> the difference is trivial. (And from OAuth1 experience, you can always >>>>> have a query parameter as part of your endpoint URL if you need to. You >>>>> might hate yourself for doing it that way, but nothing says your base >>>>> URL can't already have parameters on it. A client just needs to know how >>>>> to appropriately tack its parameters onto an existing URL, and any HTTP >>>>> client worth its salt will know how to augment a query parameter set >>>>> with new items.) >>>>> >>>>> The *real* difference between the two approaches is a philosophical >>>>> design one. The former overloads one URL with multiple functions >>>>> switched by a flag, the latter uses the URL itself as an implicit flag. >>>>> Under the hood, these could (and in many cases will) be all served by >>>>> the same chunks of code. The only difference is how this switch in >>>>> functionality is presented. >>>>> >>>>> >>>>> With that said, can somebody please explain to me how allowing *both* of >>>>> these as options simultaneously (what I understand Tony to be >>>>> suggesting) is a good idea, or how multitenancy even comes into play? >>>>> Because I am completely not seeing how these are related. >>>>> >>>>> Thanks, >>>>> -- Justin >>>>> >>>>> >>>>> >>>>> On 01/23/2013 12:46 PM, Anthony Nadalin wrote: >>>>>> It will not work the way you have it, as people do multi-tendency >>>>>> different and they are already stuck with the method that they have >>>>>> chosen, so they need the flexability, to restrict this is nuts as people >>>>>> won't use it. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Justin Richer [mailto:jric...@mitre.org] >>>>>> Sent: Wednesday, January 23, 2013 9:27 AM >>>>>> To: Anthony Nadalin >>>>>> Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Concerning OAuth introspection >>>>>> >>>>>> I completely disagree with this assessment. Multi-tenancy will work just >>>>>> fine (or even better) if everyone uses the same pattern. Telling someone >>>>>> "it might be three different urls or it might be all one url with a >>>>>> parameter" is just asking for a complete disaster. What does the >>>>>> flexibility of allowing two approaches actually accomplish? >>>>>> >>>>>> You can argue about the merits of either approach, but having both as >>>>>> unspecified options for registration, which is meant to help things get >>>>>> going in a cold-boot environment, is just plain nuts. >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> >>>>>> On 01/23/2013 12:21 PM, Anthony Nadalin 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 >>>> _______________________________________________ >>>> 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
