+1 Thanks Nat. These are important points.
Phil Sent from my phone. On 2013-01-30, at 18:59, Nat Sakimura <sakim...@gmail.com> wrote: > OAuth did not talk make distinctions or talk about HTTP methods because of > two reasons: > > (1) Browser in the middle with HTTP redirect constraint. > (2) The protected resource is the party who decides what semantics is being > mapped to the HTTP methods. > > The (1) above is just a work around for the constrained user agents. > > Registration is server to server, so we do not need to be constrained by > this. > > The (2) is a requirement to the framework because OAuth should not pollute > the space and should let the protected resource decide on their own. > > Registration endpoint is a protected resource that should decide the mapping. > > > We should not conflate with OAuth core framework requirements and protected > resource requirements. > > Nat > > 2013/1/31 Mike Jones <michael.jo...@microsoft.com> >> OAuth *never* makes a distinction between what GET and POST do. (Yes, they >> pass the input parameters differently.) I *really* don’t think we should >> start doing this now for new operations. It will likely only confuse >> developers and make things harder for them – especially when using software >> that may not always give them full access to all HTTP verbs and header >> parameters. >> >> >> >> -- Mike >> >> >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Nat Sakimura >> Sent: Wednesday, January 30, 2013 6:22 PM >> To: John Bradley >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth ) >> >> >> >> (I changed the subject to match the content.) >> >> >> >> Right. It does not have to be three endpoints. One endpoint would do (though >> it depends on how you count the URLs). >> >> >> >> However, I would do it slightly differently than you (John B.) proposes. >> >> >> >> As an example, let the registration endpoint be named /clients, which >> represents the collection of registered clients. >> >> (This is the registration endpoint.) >> >> >> >> Then, >> >> >> >> POST to the /clients would create the resource in question. (client >> associate) >> >> POST to /clients?client_id=12345 and post params (the resource URL) would >> update the resource. >> >> This is not an idempotent request, and could update any portion of the >> resource. >> >> In particular, client_secret=null or something could mean "rotate secret." >> >> >> >> GET to /clients?client_id=12345 would return the client registration data. >> It is idempotent. >> >> DELETE to /clients?client_id=12345 would delete the resource. >> >> >> >> PUT to /clients?client_id=12345 (the resource URL) would replace the >> resource, and is idempotent. >> >> (I am not sure if we need this. Probably better not have one.) >> >> >> >> For any of the above request except DELETE, the response should return the >> entire object. >> >> >> >> (For the purists: Right. This still could be improved by using URI template. >> >> The server could publish the server metadata including URI template for the >> registration etc. >> >> At that point, server is freed from forced to use the query parameters. For >> example, >> >> instead of /clients?client_id=12345, it could have instructed the client to >> use /clients/12345/ >> >> or /clients/id/12345 etc. but I think that is going too far.) >> >> >> >> Nat >> >> 2013/1/31 John Bradley <ve7...@ve7jtb.com> >> >> 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 >> >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > 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
