Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )

From: Nat Sakimura <[email-masked]>
Date: Thu, 31 Jan 2013 11:21:35 +0900

(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 <[email-masked]>

> 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&paramaters -> 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 <[email-masked]> 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 <[email-masked]> 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:[email-masked]]
> >>>>>> Sent: Wednesday, January 23, 2013 9:27 AM
> >>>>>> To: Anthony Nadalin
> >>>>>> Cc: Nat Sakimura; Shiu Fun Poon;[email-masked]
> >>>>>> 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:[email-masked]]
> >>>>>>> Sent: Wednesday, January 23, 2013 9:18 AM
> >>>>>>> To: Anthony Nadalin
> >>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;[email-masked]
> >>>>>>> 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:[email-masked] [mailto:[email-masked]] On
> >>>>>>>> Behalf Of Justin Richer
> >>>>>>>> Sent: Wednesday, January 23, 2013 7:47 AM
> >>>>>>>> To: Nat Sakimura
> >>>>>>>> Cc: Shiu Fun Poon;[email-masked]
> >>>>>>>> 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<[email-masked]>  のメッセージ:
> >>>>>>>>>
> >>>>>>>>>> (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
> >>>>>>>>>> [email-masked]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>> _______________________________________________
> >>>>>>>> OAuth mailing list
> >>>>>>>> [email-masked]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 Jan 2013 02:31:21 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Wednesday, January 30, 2013 6:22 PM
To: John Bradley
Cc: [email-masked]
Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )

Right. It does not have to be three endpoints. One endpoint would do (though it depends on how you count the URLs).

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 <[email-masked]<mailto:[email-masked]>>
That is better, but I don't see an advantage to that over using a query parameter.

On 2013-01-30, at 1:17 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> 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:
>
>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>> 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
>>>>> argued to help multitenancy because setting up routing to multiple URL
>>>>> endpoints can sometimes be problematic in hosted environments. However,
>>>>> 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
>>>>> 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
>>>>> switched by a flag, the latter uses the URL itself as an implicit flag.
>>>>> With that said, can somebody please explain to me how allowing *both* of
>>>>>> 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.
>>>>>>
>>>>>> From: Justin Richer [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;[email-masked]<mailto:[email-masked]>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Registration has to work in a multi-tenant environment  so flexibility
>>>>>>> is needed
>>>>>>>
>>>>>>> From: Justin Richer [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>> Cc: Nat Sakimura; Shiu Fun Poon;[email-masked]<mailto:[email-masked]>
>>>>>>> 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
>>>>>>>
>>>>>>>> From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>>>>>> Behalf Of Justin Richer
>>>>>>>> Cc: Shiu Fun Poon;[email-masked]<mailto:[email-masked]>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>> Jan 23, 2013 4:00、Justin Richer<[email-masked]<mailto:[email-masked]>>  のメッセージ:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>> One thing I would like to recommend is to add "action"/"operation"
>>>>>>>>>>> to the request.  (and potentially add client_id and client_secret)
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 31 Jan 2013 11:59:44 +0900

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 <[email-masked]>

>  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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, January 30, 2013 6:22 PM
> *To:* John Bradley
> *Cc:* [email-masked]
> *Subject:* [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )
> ****
>
> ** **
>
> (I changed the subject to match the content.) ****
>
> ** **
>
> (though it depends on how you count the URLs).  ****
>
> ** **
>
> However, I would do it slightly differently than you (John B.) proposes. *
> ***
>
> ** **
>
> represents the collection of registered clients. ****
>
> (This is the registration endpoint.) ****
>
> ** **
>
> Then, ****
>
> ** **
>
> associate) ****
> update the resource. ****
>
> resource. ****
> ****
> ** **
> It is idempotent. ****
> DELETE to /clients?client_id=12345 would delete the resource. ****
>
> ** **
>
> resource, and is idempotent. ****
>
>  (I am not sure if we need this. Probably better not have one.) ****
>
> ** **
>
> entire object. ****
> ** **
> 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 <[email-masked]>****
>
> The downside is developers understanding****
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> @_nat_en****

---

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Jan 2013 20:11:09 -0800

+1

Thanks Nat. These are important points.

Phil

Sent from my phone.

On 2013-01-30, at 18:59, Nat Sakimura <[email-masked]> wrote:

> OAuth did not talk make distinctions or talk about HTTP methods because of two reasons: 
> 
> (2) The protected resource is the party who decides what semantics is being mapped to the HTTP methods. 
> 
> 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
> 
>> 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: Todd W Lainhart <[email-masked]>
Date: Thu, 31 Jan 2013 09:58:48 -0500

We implemented our dynamic client registration along the lines that Nat 
describes, except that the resource segment and not the query parm 
identifies the client.  The POST and the GET on the collection return the 
resource identifiers (HATEOS).  Query parms on the collection GET works as 
you might imagine. 

There's a lot of precedent for this style of CRUD programming - I'd be 
surprised if developers didn't get the pattern, and expected consistency 
with OAuth authz programming.  I'm not manipulating resources when I'm 
hitting OAuth endpoints.

Create a client:
---------
POST /example/clients HTTP/1.1
Host: example.com:9443
Content-Length: 494
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 
client_name=My%20App&...

Fetch a single client:
----------
GET /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1 

Fetch all clients:
----------
GET /example/clients HTTP/1.1 

Modify a client:
------
PUT /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1
Host: example.ibm.com:9443
Content-Type: application/json;charset=UTF-8
If-Match: "osQf9mPplNvituLylwpDmQ=="
Content-Length: 217

Delete a client:
--------
DELETE /example/clients/6b4333771e1a409c90dd2062dd9e266e HTTP/1.1
Host: example.ibm.com:9443
If-Match: "osQf9mPplNvituLylwpDmQ==" 

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Nat Sakimura <[email-masked]>
To:     John Bradley <[email-masked]>, 
Cc:     [email-masked]
Date:   01/30/2013 09:22 PM
Subject:        [OAUTH-WG] Registration endpoints? (was: Re:  Concerning 
OAuth )
Sent by:        [email-masked]

Then, 

the registration etc. 
For example, 
to use /clients/12345/ 

Nat

POST /reg_endpoint?paramaters ?  -> register
PUT  /reg_endpoint?client_id=12345&paramaters -> update
PUT /reg_endpoint?client_id=12345&rotate_secret=true

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.
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.
that
environment
to
clients
URL
However,
implementation
code,
always
You
how
HTTP
flag.
*both* of
>>>>>> 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.
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?
flexibility
>>>>>>> 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.
>>>>>>>> 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.
"action"/"operation"
client_secret)
(default) | revoke ...

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Todd W Lainhart <[email-masked]>
Date: Thu, 31 Jan 2013 10:00:31 -0500

+1

Todd Lainhart
Rational software
IBM Corporation

From:   Nat Sakimura <[email-masked]>
To:     Mike Jones <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   01/30/2013 10:00 PM
Subject:        Re: [OAUTH-WG] Registration endpoints? (was: Re: 
Concerning OAuth )
Sent by:        [email-masked]

(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. 

We should not conflate with OAuth core framework requirements and 
protected resource requirements. 

Nat

2013/1/31 Mike Jones <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf Of 
Nat Sakimura
Sent: Wednesday, January 30, 2013 6:22 PM
To: John Bradley
Cc: [email-masked]
Subject: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )

 

Then, 

 

 
Nat

have it both ways.
that
environment
to
clients
URL
However,
implementation
code,
always
You
how
HTTP
flag.
*both* of
flexibility
"action"/"operation"
client_secret)
(default) | revoke ...