date:20130212

If we are sending JSON, then the content-type should be application/json, or
some variant of it if needed be (e.g. application/oauthreg+json etc.
-- I do not think we need it, though.)

I do not like posting it with other content-type unless we explicitly
create a variable and
define a serialization method (such as JWT).

My original comment was just asking to get some feedback from the developers.
Depending on the answer, we may want to put some explanatory notes on it.

My preference is to send JSON.

BTW, would there be a need for signing the registration data?

Nat

2013/2/13 John Bradley :
> I am OK with that language.
>
> On 2013-02-12, at 5:16 PM, Justin Richer  wrote:
>
> I would then request that people come up with a real example of where it
> *won't* work. I've seen workable solutions, and even some automagic ones, on
> several major platforms in which one would write a web server/AS: PHP, Java
> (Spring and raw servlets), Ruby (rails and sinatra), and Node.js can all do
> it.
>
> I would suggest the following text (adapted from what's in -05 right now) to
> address this:
>
>The Client sends an HTTP POST to the Client Registration Endpoint
>with a content type of "application/json". The HTTP Entity Payload is
>a JSON document consisting of a JSON object and all parameters as top-
>level members of that JSON object.
>
>
> (Would have to be tweaked for the PUT/PATCH verbs but it's effectively the
> same.)
>
>
>  -- Justin
>
> On 02/12/2013 03:07 PM, John Bradley wrote:
>
> I am fine with that as long as all the IdP tools have access to the entity
> body in some reasonable way.   That seems like the most sensible thing.
>
> However given the number of people talking about encoding it in a form to
> get access to it,  we should check that it works for everyone.
>
> John B.
> On 2013-02-12, at 4:59 PM, Justin Richer  wrote:
>
> If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
>  -- Justin
>
> On 02/12/2013 02:58 PM, John Bradley wrote:
>
> Some people apparently encode the JSON as the key in a form POST,  some
> people do a form POST with a special key and the JSON as the value.
>
> There appear to be a number of theories in the wild.   I am not an expert I
> just looked up code examples from several sources stack overflow and the
> like.
>
> We probably need to get input from developers who have experience working
> with different frameworks.   I think the differences have to do with
> decoding it at the receiver.
>
> We originally had registration posting JSON but we changed form encoding as
> that worked in all environments.   We just need to be sure we are not
> creating problems for people with the change back.
>
>
> John B.
>
> On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>
>
>
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
>>
>> Nat and I hashed out the pro's and cons of JSON requests.
>>
>> If we POST or PUT a JSON object we need to be specific as there rare
>> several ways to do it that may work better or worse depending on the
>> receiver.
>> This needs to be looked over and one picked.
>
>
> Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is
> just POSTing JSON, must be missing something. -T
>
>>
>>
>> In the other thread about the server returning the update URI and being
>> able to encode the client in that if it needs to takes care of Servers that
>> need that info in query parameters or the path to do the routing.
>>
>> The use of structure can be used to enhance readability and parsing of the
>> input, and output.
>>
>> However we need to temper our urge to apply structure to everything.
>>
>> IT needs to be applied carefully otherwise we start looking like crazies.
>>
>> If we do it cautiously I am in favour of JSON as input.
>>
>> John B.
>>
>> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's
>> concern here as well:
>>
>> It's an increasingly well known pattern that has reasonable support on the
>> server side. For PHP, I was able to find the above example via the top hit
>> on Stack Overflow. In Ruby, it's a matter of something like:
>>
>> JSON.parse(request.body.read)
>>
>> depending on the web app framework. On Java/Spring, it's a matter of
>> injecting the entity body as a string and handing it to a parser (Gson in
>> this case):
>>
>> public String doApi(@RequestBody String jsonString) { JsonObject json =
>> new JsonParser().parse(jsonString).getAsJsonObject();
>>
>> It's a similar read/parse setup in Node.js as well.
>>
>> It's true that in all of these cases you don't get to make use of the
>> routing or data binding facilities (though in Spring you can do that for
>> simpler domain objects using a ModelBinding), so you don't get niceities
>> like the $_POST array in PHP handed to you. This is why I don't think it's a

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Like bunch of people expressed their opinion in the Thursday's OpenID
call, I honestly do not understand why you think this is complex.
It is JSON.
It is not a surprise.

Compare

obj = {
  "registration_access_url":"http://example.com/";
};

obj = {
  "_links":{"self":{"href":"http://example.com/"}}
};

In the former case, the client accesses it as obj.registration_access_url.
In the later case, the client accesses it as obj._links.self.href.

As far as programming easiness is concerned, they are more or less the same.

Now, introduce other link relationships.
Say you want to store the link/rel metadata in one table and other
data in another table.
The flat one (the former) gets significantly harder.

We human being categorizes things into buckets, and we handle those buckets.
If we do not need those categorization power, then why do we use JSON?

One of the beauty of JSON is that while it has the categorization power,
you can just access as if you are in a flat name space when you are
accessing individual items.

So, while you characterize it as "complex", "hard", etc., in fact it
is "simpler" and "easier".

Also, I think you misquote the REST/JSON philosophy.

One of the most fundamental philosophy of REST is to drive the states
through hyper-links and media-types.
As a result, it also asks for a uniform interface. JSON lacks this
hyper-link and uniform interface capability.
Proposals like HAL/OAuth-meta and JSON Hyper-Schema are attempts to
address this shortcoming.
It is trying to provide a uniform interface over hyper-links.
Ad-hoc variable like registration_access_url fails this test because
it is only useable in this particular instance.
(I dislike the name as well as it does not represent the resource
representation that it returns, but that is another issue.)


2013/2/13 Mike Jones :
> Part of the REST/JSON philosophy is that interfaces should be as simple and 
> developer-friendly as possible.  XML was rejected by developers, in part, 
> because of the self-describing nature of the structure, which required extra 
> syntax that was often not useful in practice.  Trying to re-impose that 
> structure using extra JSON syntax conventions is just asking developers to 
> have an allergic reaction to our specs upon encountering them.  The syntactic 
> complexity and *surprise factor* isn't worth the limited semantic benefits of 
> using "_links".
>
> Since you bring up privacy policy and terms of service, I'll note that the 
> OAuth Dynamic Registration spec already has these fields to address those:
> policy_url
> tos_url
>
> Those have been working fine for OpenID Connect too.  There's no need to 
> likewise convolve them to add the extra syntax that you describe below.

As John said, and as I said in the private email yesterday, they are
totally different.

>
> (BTW, in a private thread, John Bradley pointed out that what the two of you 
> talked about in person was actually the possibility of adding privacy policy 
> and terms of service declarations at *discovery time*, rather than 
> registration time.  That's a different topic, which we should discuss 
> separately, if you want to pursue that.)

No, that is not right, as John's previous mail indicates. There are
ones for discovery and the ones in registration responses.

Nat

>
> Best wishes,
> -- Mike
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
> Sakimura
> Sent: Tuesday, February 12, 2013 9:11 AM
> To: Justin Richer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
>
> Actually, if it is to return it in the HTTP header, then it should also use 
> the RFC5988 Web Linking format.
> Now, that is nice to have, but for many JSON programmers, I agree that it 
> would be a hassle to obtain the header and store them in addition to the 
> JSON. So, it is nicer to have it in JSON body.
>
> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
>
> I do not think so. Accessing a flat top level parameter such as 
> registration_access_url and _links.self.href does not make any difference 
> from a client programmers point of view. That's a beauty of JSON. Both can be 
> treated as a parameter name. Doing a group operation on the links makes 
> difference though: the structured one is easier since you can just operate on 
> _links while in case of the top level parameters, you have to have an 
> explicit list of them and do the matches. (See below for the necessity for 
> the grouping).
>
> I and John discussed this for at least half an hour F2F last week, both 
> technically and from operation/legal point of view, for OpenID Connect 
> Registration.
> Similar points could be made to OAuth dyn reg.
>
> Here is what we have discussed:
>
> When dynamically registering the client to the server, the server probably 
> needs to return the following:

Re: [OAUTH-WG] Registration: JSON Encoded Input

I am OK with that language.

On 2013-02-12, at 5:16 PM, Justin Richer  wrote:

> I would then request that people come up with a real example of where it 
> *won't* work. I've seen workable solutions, and even some automagic ones, on 
> several major platforms in which one would write a web server/AS: PHP, Java 
> (Spring and raw servlets), Ruby (rails and sinatra), and Node.js can all do 
> it.
> 
> I would suggest the following text (adapted from what's in -05 right now) to 
> address this:
> 
>The Client sends an HTTP POST to the Client Registration Endpoint
>with a content type of "application/json". The HTTP Entity Payload is
>a JSON document consisting of a JSON object and all parameters as top-
>level members of that JSON object.
> 
> (Would have to be tweaked for the PUT/PATCH verbs but it's effectively the 
> same.)
> 
> 
>  -- Justin
> 
> On 02/12/2013 03:07 PM, John Bradley wrote:
>> I am fine with that as long as all the IdP tools have access to the entity 
>> body in some reasonable way.   That seems like the most sensible thing.
>> 
>> However given the number of people talking about encoding it in a form to 
>> get access to it,  we should check that it works for everyone.
>> 
>> John B.
>> On 2013-02-12, at 4:59 PM, Justin Richer  wrote:
>> 
>>> If that's the question, then my proposal is the Content-type is 
>>> "application/json" and the HTTP Entity Body is the JSON document. No form 
>>> posts or parameter names to be had here.
>>> 
>>>  -- Justin
>>> 
>>> On 02/12/2013 02:58 PM, John Bradley wrote:
 Some people apparently encode the JSON as the key in a form POST,  some 
 people do a form POST with a special key and the JSON as the value. 
 
 There appear to be a number of theories in the wild.   I am not an expert 
 I just looked up code examples from several sources stack overflow and the 
 like.
 
 We probably need to get input from developers who have experience working 
 with different frameworks.   I think the differences have to do with 
 decoding it at the receiver.
 
 We originally had registration posting JSON but we changed form encoding 
 as that worked in all environments.   We just need to be sure we are not 
 creating problems for people with the change back.
 
 
 John B.
 
 On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
 
> 
> 
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
> Nat and I hashed out the pro's and cons of JSON requests.  
> 
> If we POST or PUT a JSON object we need to be specific as there rare 
> several ways to do it that may work better or worse depending on the 
> receiver.
> This needs to be looked over and one picked.
> 
> Hm?  Not following on “several ways”, I’d have thought that POSTing JSON 
> is just POSTing JSON, must be missing something. -T
>  
> 
> In the other thread about the server returning the update URI and being 
> able to encode the client in that if it needs to takes care of Servers 
> that need that info in query parameters or the path to do the routing.
> 
> The use of structure can be used to enhance readability and parsing of 
> the input, and output.
> 
> However we need to temper our urge to apply structure to everything.  
> 
> IT needs to be applied carefully otherwise we start looking like crazies.
> 
> If we do it cautiously I am in favour of JSON as input.
> 
> John B.
> 
> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
> 
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
>> concern here as well:
>> It's an increasingly well known pattern that has reasonable support on 
>> the server side. For PHP, I was able to find the above example via the 
>> top hit on Stack Overflow. In Ruby, it's a matter of something like:
>> 
>> JSON.parse(request.body.read)
>> 
>> depending on the web app framework. On Java/Spring, it's a matter of 
>> injecting the entity body as a string and handing it to a parser (Gson 
>> in this case):
>> 
>> public String doApi(@RequestBody String jsonString) { JsonObject json = 
>> new JsonParser().parse(jsonString).getAsJsonObject();
>> 
>> It's a similar read/parse setup in Node.js as well.
>> 
>> It's true that in all of these cases you don't get to make use of the 
>> routing or data binding facilities (though in Spring you can do that for 
>> simpler domain objects using a ModelBinding), so you don't get niceities 
>> like the $_POST array in PHP handed to you. This is why I don't think 
>> it's a good idea at all to switch functionality based on the contents of 
>> the JSON object. It should be a domain object only, which is what it 
>> would be in this case.
>> 
>> I think that the positives of using JSON from the client's perspective 
>> and the

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Let me explain a bit more.

A trust framework may supply several ToS and Privacy Policy options
much like CC licenses.
If we want to really automate the things, you really need it.
Otherwise, the service's owner need to go read the ToS and Privacy
Policy in person and makes the dynamic registration not so dynamic.
Those option should be available through Discovery.

In Discovery, the server may provide multiple options,
out of which the client picks one. Think of something like Basic and
Premium service. In the Registration response, then, should be
the one that was picked by the client / assigned by the server.

(The notion is closely related to the implicit consent model for the
end users, which is in active discussion in bunch of places, by the way.)

Nat

2013/2/13 Justin Richer :
> I agree with the previous statement that the AS's privacy/TOS would be
> better handled through discovery, since it's not likely to change per client
> instance.
>
>  -- Justin
>
>
> On 02/12/2013 03:04 PM, John Bradley wrote:
>>
>> There are two TOS and privacy policies.
>>
>> One for the AS that the client is agreeing to by registering.  Will it
>> hold up in court?  don't know Facebook is doing this.
>> The link would be a reference to a human readable file that the client
>> (RP) can have someone look over before using the connection.
>> This policy may relate to how long the client can cache info etc.
>>
>> The other is the privacy policy of the client that may be presented as a
>> click through from the Authorization server.  In general the user is not
>> explicitly accepting this, only implicitly accepting it by continuing to the
>> RP after having been given a chance to look at it if they want.
>>
>> These are very US fuse on privacy but ignoring them is probably a mistake.
>>
>> John B.
>> On 2013-02-12, at 4:56 PM, Justin Richer  wrote:
>>
>>> One question though: How exactly would the client, a software
>>> application, agree to the TOS? Is it supposed to fetch the content of the
>>> tos_url and do some processing on it? I wasn't under the impression that the
>>> tos_url contents were machine readable. Is it supposed to present that to
>>> the user somehow? It seems that's a better thing for the server to do at
>>> Authorization time, since it's got the user's attention.
>>>
>>> Remember, this is meant to be for *automated* registration. The developer
>>> of the Client has no say at this stage of the game.
>>>
>>> So, I think this is a bit of a red herring, to be honest.
>>>
>>> -- Justin
>>>
>>> On 02/12/2013 02:52 PM, John Bradley wrote:

 The current privacy policy and TOS URL in registration are the ones for
 the Client.

 Nat and I discussed adding ones for the Authorization server that the
 client agrees to as separate from ones that the user is agreeing to.

 The Authorization servers TOS would be in discovery and perhaps in the
 registration response to indicate what the client is agreeing to.

 As there rare standard relationships that cover this links Nat was
 speculating that they could be part of the _links object.

 That aside confirming the terms of service that the client has agreed to
 in some way is probably a good thing in the registration response.

 John B.

 On 2013-02-12, at 4:25 PM, Mike Jones 
 wrote:

> Part of the REST/JSON philosophy is that interfaces should be as simple
> and developer-friendly as possible.  XML was rejected by developers, in
> part, because of the self-describing nature of the structure, which 
> required
> extra syntax that was often not useful in practice.  Trying to re-impose
> that structure using extra JSON syntax conventions is just asking 
> developers
> to have an allergic reaction to our specs upon encountering them.  The
> syntactic complexity and *surprise factor* isn't worth the limited 
> semantic
> benefits of using "_links".
>
> Since you bring up privacy policy and terms of service, I'll note that
> the OAuth Dynamic Registration spec already has these fields to address
> those:
> policy_url
> tos_url
>
> Those have been working fine for OpenID Connect too.  There's no need
> to likewise convolve them to add the extra syntax that you describe below.
>
> (BTW, in a private thread, John Bradley pointed out that what the two
> of you talked about in person was actually the possibility of adding 
> privacy
> policy and terms of service declarations at *discovery time*, rather than
> registration time.  That's a different topic, which we should discuss
> separately, if you want to pursue that.)
>
> Best wishes,
> -- Mike
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Nat Sakimura
> Sent: Tuesday,

Re: [OAUTH-WG] Registration: JSON Encoded Input

I would then request that people come up with a real example of where it 
*won't* work. I've seen workable solutions, and even some automagic 
ones, on several major platforms in which one would write a web 
server/AS: PHP, Java (Spring and raw servlets), Ruby (rails and 
sinatra), and Node.js can all do it.


I would suggest the following text (adapted from what's in -05 right 
now) to address this:


   The Client sends an HTTP POST to the Client Registration Endpoint
   with a content type of "application/json". The HTTP Entity Payload is
   a JSON document consisting of a JSON object and all parameters as top-
   level members of that JSON object.


(Would have to be tweaked for the PUT/PATCH verbs but it's effectively 
the same.)



 -- Justin

On 02/12/2013 03:07 PM, John Bradley wrote:
I am fine with that as long as all the IdP tools have access to the 
entity body in some reasonable way.   That seems like the most 
sensible thing.


However given the number of people talking about encoding it in a form 
to get access to it,  we should check that it works for everyone.


John B.
On 2013-02-12, at 4:59 PM, Justin Richer > wrote:


If that's the question, then my proposal is the Content-type is 
"application/json" and the HTTP Entity Body is the JSON document. No 
form posts or parameter names to be had here.


 -- Justin

On 02/12/2013 02:58 PM, John Bradley wrote:
Some people apparently encode the JSON as the key in a form POST, 
 some people do a form POST with a special key and the JSON as the 
value.


There appear to be a number of theories in the wild.   I am not an 
expert I just looked up code examples from several sources stack 
overflow and the like.


We probably need to get input from developers who have experience 
working with different frameworks.   I think the differences have to 
do with decoding it at the receiver.


We originally had registration posting JSON but we changed form 
encoding as that worked in all environments.   We just need to be 
sure we are not creating problems for people with the change back.



John B.

On 2013-02-12, at 4:48 PM, Tim Bray > wrote:





On Tue, Feb 12, 2013 at 11:44 AM, John Bradley > wrote:


Nat and I hashed out the pro's and cons of JSON requests.

If we POST or PUT a JSON object we need to be specific as there
rare several ways to do it that may work better or worse
depending on the receiver.
This needs to be looked over and one picked.


Hm?  Not following on “several ways”, I’d have thought that POSTing 
JSON is just POSTing JSON, must be missing something. -T



In the other thread about the server returning the update URI
and being able to encode the client in that if it needs to
takes care of Servers that need that info in query parameters
or the path to do the routing.

The use of structure can be used to enhance readability and
parsing of the input, and output.

However we need to temper our urge to apply structure to
everything.

IT needs to be applied carefully otherwise we start looking
like crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer mailto:jric...@mitre.org>> wrote:


Thanks for forwarding that, Mike. I'll paste in my response to
Nat's concern here as well:

It's an increasingly well known pattern that has
reasonable support on the server side. For PHP, I was able
to find the above example via the top hit on Stack
Overflow. In Ruby, it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a
matter of injecting the entity body as a string and
handing it to a parser (Gson in this case):

public String doApi(@RequestBody String jsonString) {
JsonObject json = new
JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make
use of the routing or data binding facilities (though in
Spring you can do that for simpler domain objects using a
ModelBinding), so you don't get niceities like the $_POST
array in PHP handed to you. This is why I don't think it's
a good idea at all to switch functionality based on the
contents of the JSON object. It should be a domain object
only, which is what it would be in this case.

I think that the positives of using JSON from the client's
perspective and the overall protocol design far outweigh
the slightly increased implementation cost at the server.



 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:


FYI, this issue is also being discussed as an OpenID Connect
issue at https://bitbucket.org/openid/connect/issue

Re: [OAUTH-WG] Registration: JSON Encoded Input

2013-02-12 Thread Brian Campbell

+1 to what Pat and Justin said.




On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer  wrote:

>  If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
>  -- Justin
>
>
> On 02/12/2013 02:58 PM, John Bradley wrote:
>
> Some people apparently encode the JSON as the key in a form POST,  some
> people do a form POST with a special key and the JSON as the value.
>
>  There appear to be a number of theories in the wild.   I am not an
> expert I just looked up code examples from several sources stack overflow
> and the like.
>
>  We probably need to get input from developers who have experience
> working with different frameworks.   I think the differences have to do
> with decoding it at the receiver.
>
>  We originally had registration posting JSON but we changed form encoding
> as that worked in all environments.   We just need to be sure we are not
> creating problems for people with the change back.
>
>
>  John B.
>
>  On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>
>
>
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
>
>> Nat and I hashed out the pro's and cons of JSON requests.
>>
>>  If we POST or PUT a JSON object we need to be specific as there rare
>> several ways to do it that may work better or worse depending on the
>> receiver.
>> This needs to be looked over and one picked.
>>
>
>  Hm?  Not following on “several ways”, I’d have thought that POSTing JSON
> is just POSTing JSON, must be missing something. -T
>
>
>>
>>  In the other thread about the server returning the update URI and being
>> able to encode the client in that if it needs to takes care of Servers that
>> need that info in query parameters or the path to do the routing.
>>
>>  The use of structure can be used to enhance readability and parsing of
>> the input, and output.
>>
>>  However we need to temper our urge to apply structure to everything.
>>
>>  IT needs to be applied carefully otherwise we start looking like
>> crazies.
>>
>>  If we do it cautiously I am in favour of JSON as input.
>>
>>  John B.
>>
>>  On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>
>>  Thanks for forwarding that, Mike. I'll paste in my response to Nat's
>> concern here as well:
>>
>> It's an increasingly well known pattern that has reasonable support on
>> the server side. For PHP, I was able to find the above example via the top
>> hit on Stack Overflow. In Ruby, it's a matter of something like:
>>
>> JSON.parse(request.body.read)
>>
>> depending on the web app framework. On Java/Spring, it's a matter of
>> injecting the entity body as a string and handing it to a parser (Gson in
>> this case):
>>
>> public String doApi(@RequestBody String jsonString) { JsonObject json =
>> new JsonParser().parse(jsonString).getAsJsonObject();
>>
>> It's a similar read/parse setup in Node.js as well.
>>
>> It's true that in all of these cases you don't get to make use of the
>> routing or data binding facilities (though in Spring you can do that for
>> simpler domain objects using a ModelBinding), so you don't get niceities
>> like the $_POST array in PHP handed to you. This is why I don't think it's
>> a good idea at all to switch functionality based on the contents of the
>> JSON object. It should be a domain object only, which is what it would be
>> in this case.
>>
>> I think that the positives of using JSON from the client's perspective
>> and the overall protocol design far outweigh the slightly increased
>> implementation cost at the server.
>>
>>
>>
>>  -- Justin
>>
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>
>>  FYI, this issue is also being discussed as an OpenID Connect issue at
>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's
>> recent comment there bears repeating on this list:
>>
>>
>>
>> Nat Sakimura:
>>
>>
>>
>> Not so sure. For example, PHP cannot get the JSON object form
>> application/json POST in $_POST.
>>
>>
>>
>> It is OK to have a parameter like "request" that holds JSON. Then, you
>> can get to it from $_POST['request']. However, if you POST the JSON as the
>> POST body, then you would have to call a low level function in the form of:
>>
>>
>>
>>
>>
>> ```
>>
>> #!php
>>
>>
>>
>> $file = file_get_contents('php://input'); $x = json_decode($file); ```
>>
>>
>>
>> Not that it is harder, but it is much less known. Many PHP programmers
>> will certainly goes "???".
>>
>>
>>
>> We need to check what would be the cases for other scripting languages
>> before making the final decision.
>>
>>
>>
>> -- Mike
>>
>>
>>
>> -Original Message-
>> From: oauth-boun...@ietf.org 
>> [mailto:oauth-boun...@ietf.org]
>> On Behalf Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>
>>
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from

Re: [OAUTH-WG] Registration: JSON Encoded Input

I am fine with that as long as all the IdP tools have access to the entity body 
in some reasonable way.   That seems like the most sensible thing.

However given the number of people talking about encoding it in a form to get 
access to it,  we should check that it works for everyone.

John B.
On 2013-02-12, at 4:59 PM, Justin Richer  wrote:

> If that's the question, then my proposal is the Content-type is 
> "application/json" and the HTTP Entity Body is the JSON document. No form 
> posts or parameter names to be had here.
> 
>  -- Justin
> 
> On 02/12/2013 02:58 PM, John Bradley wrote:
>> Some people apparently encode the JSON as the key in a form POST,  some 
>> people do a form POST with a special key and the JSON as the value. 
>> 
>> There appear to be a number of theories in the wild.   I am not an expert I 
>> just looked up code examples from several sources stack overflow and the 
>> like.
>> 
>> We probably need to get input from developers who have experience working 
>> with different frameworks.   I think the differences have to do with 
>> decoding it at the receiver.
>> 
>> We originally had registration posting JSON but we changed form encoding as 
>> that worked in all environments.   We just need to be sure we are not 
>> creating problems for people with the change back.
>> 
>> 
>> John B.
>> 
>> On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>> 
>>> 
>>> 
>>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
>>> Nat and I hashed out the pro's and cons of JSON requests.  
>>> 
>>> If we POST or PUT a JSON object we need to be specific as there rare 
>>> several ways to do it that may work better or worse depending on the 
>>> receiver.
>>> This needs to be looked over and one picked.
>>> 
>>> Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is 
>>> just POSTing JSON, must be missing something. -T
>>>  
>>> 
>>> In the other thread about the server returning the update URI and being 
>>> able to encode the client in that if it needs to takes care of Servers that 
>>> need that info in query parameters or the path to do the routing.
>>> 
>>> The use of structure can be used to enhance readability and parsing of the 
>>> input, and output.
>>> 
>>> However we need to temper our urge to apply structure to everything.  
>>> 
>>> IT needs to be applied carefully otherwise we start looking like crazies.
>>> 
>>> If we do it cautiously I am in favour of JSON as input.
>>> 
>>> John B.
>>> 
>>> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>> 
 Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
 concern here as well:
 It's an increasingly well known pattern that has reasonable support on the 
 server side. For PHP, I was able to find the above example via the top hit 
 on Stack Overflow. In Ruby, it's a matter of something like:
 
 JSON.parse(request.body.read)
 
 depending on the web app framework. On Java/Spring, it's a matter of 
 injecting the entity body as a string and handing it to a parser (Gson in 
 this case):
 
 public String doApi(@RequestBody String jsonString) { JsonObject json = 
 new JsonParser().parse(jsonString).getAsJsonObject();
 
 It's a similar read/parse setup in Node.js as well.
 
 It's true that in all of these cases you don't get to make use of the 
 routing or data binding facilities (though in Spring you can do that for 
 simpler domain objects using a ModelBinding), so you don't get niceities 
 like the $_POST array in PHP handed to you. This is why I don't think it's 
 a good idea at all to switch functionality based on the contents of the 
 JSON object. It should be a domain object only, which is what it would be 
 in this case.
 
 I think that the positives of using JSON from the client's perspective and 
 the overall protocol design far outweigh the slightly increased 
 implementation cost at the server.
 
 
  -- Justin
 
 On 02/12/2013 02:11 PM, Mike Jones wrote:
> FYI, this issue is also being discussed as an OpenID Connect issue at 
> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's 
> recent comment there bears repeating on this list:
> 
>  
> Nat Sakimura:
> 
>  
> Not so sure. For example, PHP cannot get the JSON object form 
> application/json POST in $_POST.
> 
>  
> It is OK to have a parameter like "request" that holds JSON. Then, you 
> can get to it from $_POST['request']. However, if you POST the JSON as 
> the POST body, then you would have to call a low level function in the 
> form of:
> 
>  
>  
> ```
> 
> #!php
> 
>  
> $file = file_get_contents('php://input'); $x = json_decode($file); ```
> 
>  
> Not that it is harder, but it is much less known. Many PHP programmers 
> will certainly goes "???".
> 
>  
> We need to che

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

I agree with the previous statement that the AS's privacy/TOS would be 
better handled through discovery, since it's not likely to change per 
client instance.


 -- Justin

On 02/12/2013 03:04 PM, John Bradley wrote:

There are two TOS and privacy policies.

One for the AS that the client is agreeing to by registering.  Will it hold up 
in court?  don't know Facebook is doing this.
The link would be a reference to a human readable file that the client (RP) can 
have someone look over before using the connection.
This policy may relate to how long the client can cache info etc.

The other is the privacy policy of the client that may be presented as a click 
through from the Authorization server.  In general the user is not explicitly 
accepting this, only implicitly accepting it by continuing to the RP after 
having been given a chance to look at it if they want.

These are very US fuse on privacy but ignoring them is probably a mistake.

John B.
On 2013-02-12, at 4:56 PM, Justin Richer  wrote:


One question though: How exactly would the client, a software application, 
agree to the TOS? Is it supposed to fetch the content of the tos_url and do 
some processing on it? I wasn't under the impression that the tos_url contents 
were machine readable. Is it supposed to present that to the user somehow? It 
seems that's a better thing for the server to do at Authorization time, since 
it's got the user's attention.

Remember, this is meant to be for *automated* registration. The developer of 
the Client has no say at this stage of the game.

So, I think this is a bit of a red herring, to be honest.

-- Justin

On 02/12/2013 02:52 PM, John Bradley wrote:

The current privacy policy and TOS URL in registration are the ones for the 
Client.

Nat and I discussed adding ones for the Authorization server that the client 
agrees to as separate from ones that the user is agreeing to.

The Authorization servers TOS would be in discovery and perhaps in the 
registration response to indicate what the client is agreeing to.

As there rare standard relationships that cover this links Nat was speculating 
that they could be part of the _links object.

That aside confirming the terms of service that the client has agreed to in 
some way is probably a good thing in the registration response.

John B.

On 2013-02-12, at 4:25 PM, Mike Jones  wrote:


Part of the REST/JSON philosophy is that interfaces should be as simple and 
developer-friendly as possible.  XML was rejected by developers, in part, because of the 
self-describing nature of the structure, which required extra syntax that was often not 
useful in practice.  Trying to re-impose that structure using extra JSON syntax 
conventions is just asking developers to have an allergic reaction to our specs upon 
encountering them.  The syntactic complexity and *surprise factor* isn't worth the 
limited semantic benefits of using "_links".

Since you bring up privacy policy and terms of service, I'll note that the 
OAuth Dynamic Registration spec already has these fields to address those:
policy_url
tos_url

Those have been working fine for OpenID Connect too.  There's no need to 
likewise convolve them to add the extra syntax that you describe below.

(BTW, in a private thread, John Bradley pointed out that what the two of you 
talked about in person was actually the possibility of adding privacy policy 
and terms of service declarations at *discovery time*, rather than registration 
time.  That's a different topic, which we should discuss separately, if you 
want to pursue that.)

Best wishes,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Actually, if it is to return it in the HTTP header, then it should also use the 
RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it would 
be a hassle to obtain the header and store them in addition to the JSON. So, it 
is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such as 
registration_access_url and _links.self.href does not make any difference from 
a client programmers point of view. That's a beauty of JSON. Both can be 
treated as a parameter name. Doing a group operation on the links makes 
difference though: the structured one is easier since you can just operate on 
_links while in case of the top level parameters, you have to have an explicit 
list of them and do the matches. (See below for the necessity for the grouping).

I and John discussed this for at least half an hour F2F last week, both 
technically and from operation/legal point of view, for OpenID

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

There are two TOS and privacy policies.

One for the AS that the client is agreeing to by registering.  Will it hold up 
in court?  don't know Facebook is doing this.
The link would be a reference to a human readable file that the client (RP) can 
have someone look over before using the connection.
This policy may relate to how long the client can cache info etc.

The other is the privacy policy of the client that may be presented as a click 
through from the Authorization server.  In general the user is not explicitly 
accepting this, only implicitly accepting it by continuing to the RP after 
having been given a chance to look at it if they want.

These are very US fuse on privacy but ignoring them is probably a mistake.

John B.
On 2013-02-12, at 4:56 PM, Justin Richer  wrote:

> One question though: How exactly would the client, a software application, 
> agree to the TOS? Is it supposed to fetch the content of the tos_url and do 
> some processing on it? I wasn't under the impression that the tos_url 
> contents were machine readable. Is it supposed to present that to the user 
> somehow? It seems that's a better thing for the server to do at Authorization 
> time, since it's got the user's attention.
> 
> Remember, this is meant to be for *automated* registration. The developer of 
> the Client has no say at this stage of the game.
> 
> So, I think this is a bit of a red herring, to be honest.
> 
> -- Justin
> 
> On 02/12/2013 02:52 PM, John Bradley wrote:
>> The current privacy policy and TOS URL in registration are the ones for the 
>> Client.
>> 
>> Nat and I discussed adding ones for the Authorization server that the client 
>> agrees to as separate from ones that the user is agreeing to.
>> 
>> The Authorization servers TOS would be in discovery and perhaps in the 
>> registration response to indicate what the client is agreeing to.
>> 
>> As there rare standard relationships that cover this links Nat was 
>> speculating that they could be part of the _links object.
>> 
>> That aside confirming the terms of service that the client has agreed to in 
>> some way is probably a good thing in the registration response.
>> 
>> John B.
>> 
>> On 2013-02-12, at 4:25 PM, Mike Jones  wrote:
>> 
>>> Part of the REST/JSON philosophy is that interfaces should be as simple and 
>>> developer-friendly as possible.  XML was rejected by developers, in part, 
>>> because of the self-describing nature of the structure, which required 
>>> extra syntax that was often not useful in practice.  Trying to re-impose 
>>> that structure using extra JSON syntax conventions is just asking 
>>> developers to have an allergic reaction to our specs upon encountering 
>>> them.  The syntactic complexity and *surprise factor* isn't worth the 
>>> limited semantic benefits of using "_links".
>>> 
>>> Since you bring up privacy policy and terms of service, I'll note that the 
>>> OAuth Dynamic Registration spec already has these fields to address those:
>>> policy_url
>>> tos_url
>>> 
>>> Those have been working fine for OpenID Connect too.  There's no need to 
>>> likewise convolve them to add the extra syntax that you describe below.
>>> 
>>> (BTW, in a private thread, John Bradley pointed out that what the two of 
>>> you talked about in person was actually the possibility of adding privacy 
>>> policy and terms of service declarations at *discovery time*, rather than 
>>> registration time.  That's a different topic, which we should discuss 
>>> separately, if you want to pursue that.)
>>> 
>>> Best wishes,
>>> -- Mike
>>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>>> Nat Sakimura
>>> Sent: Tuesday, February 12, 2013 9:11 AM
>>> To: Justin Richer; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client 
>>> self-URL
>>> 
>>> Actually, if it is to return it in the HTTP header, then it should also use 
>>> the RFC5988 Web Linking format.
>>> Now, that is nice to have, but for many JSON programmers, I agree that it 
>>> would be a hassle to obtain the header and store them in addition to the 
>>> JSON. So, it is nicer to have it in JSON body.
>>> 
>>> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
>>> 
>>> I do not think so. Accessing a flat top level parameter such as 
>>> registration_access_url and _links.self.href does not make any difference 
>>> from a client programmers point of view. That's a beauty of JSON. Both can 
>>> be treated as a parameter name. Doing a group operation on the links makes 
>>> difference though: the structured one is easier since you can just operate 
>>> on _links while in case of the top level parameters, you have to have an 
>>> explicit list of them and do the matches. (See below for the necessity for 
>>> the grouping).
>>> 
>>> I and John discussed this for at least half an hour F2F last week, both 
>>

Re: [OAUTH-WG] Registration: JSON Encoded Input

2013-02-12 Thread Pat Patterson

Just POST the JSON as the HTTP payload with mime-type application/json:

$ curl -v -H "Content-Type: application/json" -X POST -d '{"Hello": "World"}' 
http://requestb.in/19qit4u1
* About to connect() to requestb.in port 80 (#0)
*   Trying 107.20.236.186... connected
* Connected to requestb.in (107.20.236.186) port 80 (#0)
> POST /19qit4u1 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 
> OpenSSL/0.9.8r zlib/1.2.3
> Host: requestb.in
> Accept: */*
> Content-Type: application/json
> Content-Length: 18
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Date: Tue, 12 Feb 2013 20:03:39 GMT
< Content-Length: 3
< Connection: keep-alive
<
ok
* Connection #0 to host requestb.in left intact
* Closing connection #0

Cheers,

Pat
--
Pat Patterson | Principal Developer Evangelist | 408-849-4681 | 
http://about.me/patpatterson

On Feb 12, 2013, at 11:58 AM, John Bradley wrote:

Some people apparently encode the JSON as the key in a form POST,  some people 
do a form POST with a special key and the JSON as the value.

There appear to be a number of theories in the wild.   I am not an expert I 
just looked up code examples from several sources stack overflow and the like.

We probably need to get input from developers who have experience working with 
different frameworks.   I think the differences have to do with decoding it at 
the receiver.

We originally had registration posting JSON but we changed form encoding as 
that worked in all environments.   We just need to be sure we are not creating 
problems for people with the change back.

John B.

On 2013-02-12, at 4:48 PM, Tim Bray 
mailto:twb...@google.com>> wrote:

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Nat and I hashed out the pro's and cons of JSON requests.

If we POST or PUT a JSON object we need to be specific as there rare several 
ways to do it that may work better or worse depending on the receiver.
This needs to be looked over and one picked.

Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is 
just POSTing JSON, must be missing something. -T

In the other thread about the server returning the update URI and being able to 
encode the client in that if it needs to takes care of Servers that need that 
info in query parameters or the path to do the routing.

The use of structure can be used to enhance readability and parsing of the 
input, and output.

However we need to temper our urge to apply structure to everything.

IT needs to be applied carefully otherwise we start looking like crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer 
mailto:jric...@mitre.org>> wrote:

Thanks for forwarding that, Mike. I'll paste in my response to Nat's concern 
here as well:
It's an increasingly well known pattern that has reasonable support on the 
server side. For PHP, I was able to find the above example via the top hit on 
Stack Overflow. In Ruby, it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a matter of injecting 
the entity body as a string and handing it to a parser (Gson in this case):

public String doApi(@RequestBody String jsonString) { JsonObject json = new 
JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make use of the routing 
or data binding facilities (though in Spring you can do that for simpler domain 
objects using a ModelBinding), so you don't get niceities like the $_POST array 
in PHP handed to you. This is why I don't think it's a good idea at all to 
switch functionality based on the contents of the JSON object. It should be a 
domain object only, which is what it would be in this case.

I think that the positives of using JSON from the client's perspective and the 
overall protocol design far outweigh the slightly increased implementation cost 
at the server.

 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:

FYI, this issue is also being discussed as an OpenID Connect issue at 
https://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent 
comment there bears repeating on this list:

Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form application/json 
POST in $_POST.

It is OK to have a parameter like "request" that holds JSON. Then, you can get 
to it from $_POST['request']. However, if you POST the JSON as the POST body, 
then you would have to call a low level function in the form of:

```

#!php

$file = file_get_contents('php://input'); $x = json_decode($file); ```

Not that it is harder, but it is much less known. Many PHP programmers will 
certainly goes "???".

We need to check what would be the cases for other scripting languages before 
making the final decision.

Re: [OAUTH-WG] Registration: JSON Encoded Input

If that's the question, then my proposal is the Content-type is 
"application/json" and the HTTP Entity Body is the JSON document. No 
form posts or parameter names to be had here.


 -- Justin

On 02/12/2013 02:58 PM, John Bradley wrote:
Some people apparently encode the JSON as the key in a form POST, 
 some people do a form POST with a special key and the JSON as the value.


There appear to be a number of theories in the wild.   I am not an 
expert I just looked up code examples from several sources stack 
overflow and the like.


We probably need to get input from developers who have experience 
working with different frameworks.   I think the differences have to 
do with decoding it at the receiver.


We originally had registration posting JSON but we changed form 
encoding as that worked in all environments.   We just need to be sure 
we are not creating problems for people with the change back.



John B.

On 2013-02-12, at 4:48 PM, Tim Bray > wrote:





On Tue, Feb 12, 2013 at 11:44 AM, John Bradley > wrote:


Nat and I hashed out the pro's and cons of JSON requests.

If we POST or PUT a JSON object we need to be specific as there
rare several ways to do it that may work better or worse
depending on the receiver.
This needs to be looked over and one picked.


Hm?  Not following on “several ways”, I’d have thought that POSTing 
JSON is just POSTing JSON, must be missing something. -T



In the other thread about the server returning the update URI and
being able to encode the client in that if it needs to takes care
of Servers that need that info in query parameters or the path to
do the routing.

The use of structure can be used to enhance readability and
parsing of the input, and output.

However we need to temper our urge to apply structure to everything.

IT needs to be applied carefully otherwise we start looking like
crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer mailto:jric...@mitre.org>> wrote:


Thanks for forwarding that, Mike. I'll paste in my response to
Nat's concern here as well:

It's an increasingly well known pattern that has reasonable
support on the server side. For PHP, I was able to find the
above example via the top hit on Stack Overflow. In Ruby,
it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a
matter of injecting the entity body as a string and handing
it to a parser (Gson in this case):

public String doApi(@RequestBody String jsonString) {
JsonObject json = new
JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make
use of the routing or data binding facilities (though in
Spring you can do that for simpler domain objects using a
ModelBinding), so you don't get niceities like the $_POST
array in PHP handed to you. This is why I don't think it's a
good idea at all to switch functionality based on the
contents of the JSON object. It should be a domain object
only, which is what it would be in this case.

I think that the positives of using JSON from the client's
perspective and the overall protocol design far outweigh the
slightly increased implementation cost at the server.



 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:


FYI, this issue is also being discussed as an OpenID Connect
issue at https://bitbucket.org/openid/connect/issue/747. I
think that Nat's recent comment there bears repeating on this list:

Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form
application/json POST in $_POST.

It is OK to have a parameter like "request" that holds JSON.
Then, you can get to it from $_POST['request']. However, if you
POST the JSON as the POST body, then you would have to call a
low level function in the form of:

```

#!php

$file = file_get_contents('php://input'); $x =
json_decode($file); ```

Not that it is harder, but it is much less known. Many PHP
programmers will certainly goes "???".

We need to check what would be the cases for other scripting
languages before making the final decision.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org 
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1] switched
from a form-encoded input that ha

Re: [OAUTH-WG] Registration: JSON Encoded Input

Some people apparently encode the JSON as the key in a form POST,  some people 
do a form POST with a special key and the JSON as the value. 

There appear to be a number of theories in the wild.   I am not an expert I 
just looked up code examples from several sources stack overflow and the like.

We probably need to get input from developers who have experience working with 
different frameworks.   I think the differences have to do with decoding it at 
the receiver.

We originally had registration posting JSON but we changed form encoding as 
that worked in all environments.   We just need to be sure we are not creating 
problems for people with the change back.


John B.

On 2013-02-12, at 4:48 PM, Tim Bray  wrote:

> 
> 
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
> Nat and I hashed out the pro's and cons of JSON requests.  
> 
> If we POST or PUT a JSON object we need to be specific as there rare several 
> ways to do it that may work better or worse depending on the receiver.
> This needs to be looked over and one picked.
> 
> Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is 
> just POSTing JSON, must be missing something. -T
>  
> 
> In the other thread about the server returning the update URI and being able 
> to encode the client in that if it needs to takes care of Servers that need 
> that info in query parameters or the path to do the routing.
> 
> The use of structure can be used to enhance readability and parsing of the 
> input, and output.
> 
> However we need to temper our urge to apply structure to everything.  
> 
> IT needs to be applied carefully otherwise we start looking like crazies.
> 
> If we do it cautiously I am in favour of JSON as input.
> 
> John B.
> 
> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
> 
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's concern 
>> here as well:
>> It's an increasingly well known pattern that has reasonable support on the 
>> server side. For PHP, I was able to find the above example via the top hit 
>> on Stack Overflow. In Ruby, it's a matter of something like:
>> 
>> JSON.parse(request.body.read)
>> 
>> depending on the web app framework. On Java/Spring, it's a matter of 
>> injecting the entity body as a string and handing it to a parser (Gson in 
>> this case):
>> 
>> public String doApi(@RequestBody String jsonString) { JsonObject json = new 
>> JsonParser().parse(jsonString).getAsJsonObject();
>> 
>> It's a similar read/parse setup in Node.js as well.
>> 
>> It's true that in all of these cases you don't get to make use of the 
>> routing or data binding facilities (though in Spring you can do that for 
>> simpler domain objects using a ModelBinding), so you don't get niceities 
>> like the $_POST array in PHP handed to you. This is why I don't think it's a 
>> good idea at all to switch functionality based on the contents of the JSON 
>> object. It should be a domain object only, which is what it would be in this 
>> case.
>> 
>> I think that the positives of using JSON from the client's perspective and 
>> the overall protocol design far outweigh the slightly increased 
>> implementation cost at the server.
>> 
>> 
>>  -- Justin
>> 
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>> FYI, this issue is also being discussed as an OpenID Connect issue at 
>>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent 
>>> comment there bears repeating on this list:
>>> 
>>>  
>>> 
>>> Nat Sakimura:
>>> 
>>>  
>>> 
>>> Not so sure. For example, PHP cannot get the JSON object form 
>>> application/json POST in $_POST.
>>> 
>>>  
>>> 
>>> It is OK to have a parameter like "request" that holds JSON. Then, you can 
>>> get to it from $_POST['request']. However, if you POST the JSON as the POST 
>>> body, then you would have to call a low level function in the form of:
>>> 
>>>  
>>> 
>>>  
>>> 
>>> ```
>>> 
>>> #!php
>>> 
>>>  
>>> 
>>> $file = file_get_contents('php://input'); $x = json_decode($file); ```
>>> 
>>>  
>>> 
>>> Not that it is harder, but it is much less known. Many PHP programmers will 
>>> certainly goes "???".
>>> 
>>>  
>>> 
>>> We need to check what would be the cases for other scripting languages 
>>> before making the final decision.
>>> 
>>>  
>>> 
>>> -- Mike
>>> 
>>>  
>>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>>> Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>> 
>>>  
>>> 
>>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
>>> form-encoded input that had been used by drafts -01 through -04 to a JSON 
>>> encoded input that was used originally in -00. Note that all versions keep 
>>> JSON-encoded output from all operations.
>>> 
>>>  
>>> 
>>> Pro:
>>> 
>>>   - JSON gives us a rich data structure s

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

One question though: How exactly would the client, a software 
application, agree to the TOS? Is it supposed to fetch the content of 
the tos_url and do some processing on it? I wasn't under the impression 
that the tos_url contents were machine readable. Is it supposed to 
present that to the user somehow? It seems that's a better thing for the 
server to do at Authorization time, since it's got the user's attention.


Remember, this is meant to be for *automated* registration. The 
developer of the Client has no say at this stage of the game.


So, I think this is a bit of a red herring, to be honest.

 -- Justin

On 02/12/2013 02:52 PM, John Bradley wrote:

The current privacy policy and TOS URL in registration are the ones for the 
Client.

Nat and I discussed adding ones for the Authorization server that the client 
agrees to as separate from ones that the user is agreeing to.

The Authorization servers TOS would be in discovery and perhaps in the 
registration response to indicate what the client is agreeing to.

As there rare standard relationships that cover this links Nat was speculating 
that they could be part of the _links object.

That aside confirming the terms of service that the client has agreed to in 
some way is probably a good thing in the registration response.

John B.

On 2013-02-12, at 4:25 PM, Mike Jones  wrote:


Part of the REST/JSON philosophy is that interfaces should be as simple and 
developer-friendly as possible.  XML was rejected by developers, in part, because of the 
self-describing nature of the structure, which required extra syntax that was often not 
useful in practice.  Trying to re-impose that structure using extra JSON syntax 
conventions is just asking developers to have an allergic reaction to our specs upon 
encountering them.  The syntactic complexity and *surprise factor* isn't worth the 
limited semantic benefits of using "_links".

Since you bring up privacy policy and terms of service, I'll note that the 
OAuth Dynamic Registration spec already has these fields to address those:
policy_url
tos_url

Those have been working fine for OpenID Connect too.  There's no need to 
likewise convolve them to add the extra syntax that you describe below.

(BTW, in a private thread, John Bradley pointed out that what the two of you 
talked about in person was actually the possibility of adding privacy policy 
and terms of service declarations at *discovery time*, rather than registration 
time.  That's a different topic, which we should discuss separately, if you 
want to pursue that.)

Best wishes,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Actually, if it is to return it in the HTTP header, then it should also use the 
RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it would 
be a hassle to obtain the header and store them in addition to the JSON. So, it 
is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such as 
registration_access_url and _links.self.href does not make any difference from 
a client programmers point of view. That's a beauty of JSON. Both can be 
treated as a parameter name. Doing a group operation on the links makes 
difference though: the structured one is easier since you can just operate on 
_links while in case of the top level parameters, you have to have an explicit 
list of them and do the matches. (See below for the necessity for the grouping).

I and John discussed this for at least half an hour F2F last week, both 
technically and from operation/legal point of view, for OpenID Connect 
Registration.
Similar points could be made to OAuth dyn reg.

Here is what we have discussed:

When dynamically registering the client to the server, the server probably 
needs to return the following:

  * terms-of-service (terms of service of the server to the client)
  * privacy-policy (privacy policy of the server to the client)

Both are defined in RFC5988/IANA Link Relations registry.


They should be returned together with

  * self.href

which is also defined in RFC5988/IANA Link Relations registry.

There are several ways to do it.

  * Return these using RFC5988 (HTTP Header)
  * Return these in entity body
  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

Returning it in the entity body has several advantage over HTTP header:

  * They can be captured in one call;
  * They are protocol agnostic;

We determined that these advantages outweighs the disadvantage of creating a 
new standard.

The question becomes then whether to:

Re: [OAUTH-WG] Registration: JSON Encoded Input

In this case, I believe that it really is a fairly straightforward case 
of replacing the form-based key-value hash with a JSON-based key-value 
hash. So all the existing parameters are converted into top-level JSON 
objects, and the parameter values become the values of those members. 
This is the exact same form that the JSON output from the endpoint 
already was. The data model remains essentially identical between the 
two. Is there another reasonable way to do this? I haven't seen another 
proposal put forward, yet, though I'm sure we could dream up all kinds 
of unreasonable ones. :)


The only extra structured in the discussion draft (-05) are most of the 
lists, like redirect_uri and grant_type. An extension would want to use 
JSON numbers or booleans where it makes sense. Note that the "scope" 
parameter is still defined as a space-separated list of strings, a 
definition taken directly from OAuth Core. This is largely from feedback 
I got in regard to the Introspection draft, which tried to add JSON list 
structure to "scope" and confused folks.


 -- Justin

On 02/12/2013 02:44 PM, John Bradley wrote:

Nat and I hashed out the pro's and cons of JSON requests.

If we POST or PUT a JSON object we need to be specific as there rare 
several ways to do it that may work better or worse depending on the 
receiver.

This needs to be looked over and one picked.

In the other thread about the server returning the update URI and 
being able to encode the client in that if it needs to takes care of 
Servers that need that info in query parameters or the path to do the 
routing.


The use of structure can be used to enhance readability and parsing of 
the input, and output.


However we need to temper our urge to apply structure to everything.

IT needs to be applied carefully otherwise we start looking like crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer > wrote:


Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
concern here as well:


It's an increasingly well known pattern that has reasonable
support on the server side. For PHP, I was able to find the above
example via the top hit on Stack Overflow. In Ruby, it's a matter
of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a matter
of injecting the entity body as a string and handing it to a
parser (Gson in this case):

public String doApi(@RequestBody String jsonString) { JsonObject
json = new JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make use of
the routing or data binding facilities (though in Spring you can
do that for simpler domain objects using a ModelBinding), so you
don't get niceities like the $_POST array in PHP handed to you.
This is why I don't think it's a good idea at all to switch
functionality based on the contents of the JSON object. It should
be a domain object only, which is what it would be in this case.

I think that the positives of using JSON from the client's
perspective and the overall protocol design far outweigh the
slightly increased implementation cost at the server.



 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:


FYI, this issue is also being discussed as an OpenID Connect issue 
at https://bitbucket.org/openid/connect/issue/747. I think that 
Nat's recent comment there bears repeating on this list:


Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form 
application/json POST in $_POST.


It is OK to have a parameter like "request" that holds JSON. Then, 
you can get to it from $_POST['request']. However, if you POST the 
JSON as the POST body, then you would have to call a low level 
function in the form of:


```

#!php

$file = file_get_contents('php://input' ); $x = 
json_decode($file); ```


Not that it is harder, but it is much less known. Many PHP 
programmers will certainly goes "???".


We need to check what would be the cases for other scripting 
languages before making the final decision.


-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
Behalf Of Justin Richer

Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
form-encoded input that had been used by drafts -01 through -04 to a 
JSON encoded input that was used originally in -00. Note that all 
versions keep JSON-encoded output from all operations.


Pro:

  - JSON gives us a rich data structure so that things such as 
lists, numbers, nulls, and objects can be represented natively


  - Allows for parallelism between the input to the endpoint and 
output from the endpoint, reducing

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

The current privacy policy and TOS URL in registration are the ones for the 
Client.

Nat and I discussed adding ones for the Authorization server that the client 
agrees to as separate from ones that the user is agreeing to.

The Authorization servers TOS would be in discovery and perhaps in the 
registration response to indicate what the client is agreeing to.

As there rare standard relationships that cover this links Nat was speculating 
that they could be part of the _links object. 

That aside confirming the terms of service that the client has agreed to in 
some way is probably a good thing in the registration response.

John B.

On 2013-02-12, at 4:25 PM, Mike Jones  wrote:

> Part of the REST/JSON philosophy is that interfaces should be as simple and 
> developer-friendly as possible.  XML was rejected by developers, in part, 
> because of the self-describing nature of the structure, which required extra 
> syntax that was often not useful in practice.  Trying to re-impose that 
> structure using extra JSON syntax conventions is just asking developers to 
> have an allergic reaction to our specs upon encountering them.  The syntactic 
> complexity and *surprise factor* isn't worth the limited semantic benefits of 
> using "_links".
> 
> Since you bring up privacy policy and terms of service, I'll note that the 
> OAuth Dynamic Registration spec already has these fields to address those:
>   policy_url
>   tos_url
> 
> Those have been working fine for OpenID Connect too.  There's no need to 
> likewise convolve them to add the extra syntax that you describe below.
> 
> (BTW, in a private thread, John Bradley pointed out that what the two of you 
> talked about in person was actually the possibility of adding privacy policy 
> and terms of service declarations at *discovery time*, rather than 
> registration time.  That's a different topic, which we should discuss 
> separately, if you want to pursue that.)
> 
>   Best wishes,
>   -- Mike
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
> Sakimura
> Sent: Tuesday, February 12, 2013 9:11 AM
> To: Justin Richer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
> 
> Actually, if it is to return it in the HTTP header, then it should also use 
> the RFC5988 Web Linking format.
> Now, that is nice to have, but for many JSON programmers, I agree that it 
> would be a hassle to obtain the header and store them in addition to the 
> JSON. So, it is nicer to have it in JSON body.
> 
> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
> 
> I do not think so. Accessing a flat top level parameter such as 
> registration_access_url and _links.self.href does not make any difference 
> from a client programmers point of view. That's a beauty of JSON. Both can be 
> treated as a parameter name. Doing a group operation on the links makes 
> difference though: the structured one is easier since you can just operate on 
> _links while in case of the top level parameters, you have to have an 
> explicit list of them and do the matches. (See below for the necessity for 
> the grouping).
> 
> I and John discussed this for at least half an hour F2F last week, both 
> technically and from operation/legal point of view, for OpenID Connect 
> Registration.
> Similar points could be made to OAuth dyn reg.
> 
> Here is what we have discussed:
> 
> When dynamically registering the client to the server, the server probably 
> needs to return the following:
> 
>  * terms-of-service (terms of service of the server to the client)
>  * privacy-policy (privacy policy of the server to the client)
> 
> Both are defined in RFC5988/IANA Link Relations registry.
> 
> 
> They should be returned together with
> 
>  * self.href
> 
> which is also defined in RFC5988/IANA Link Relations registry.
> 
> There are several ways to do it.
> 
>  * Return these using RFC5988 (HTTP Header)
>  * Return these in entity body
>  * Use HAL (or OAuth-meta)/JSON Schema
>  * Use something else (e.g., a top level items)
> 
> Returning it in the entity body has several advantage over HTTP header:
> 
>  * They can be captured in one call;
>  * They are protocol agnostic;
> 
> We determined that these advantages outweighs the disadvantage of creating a 
> new standard.
> 
> The question becomes then whether to:
> 
>  * Use HAL (or OAuth-meta)/JSON Schema
>  * Use something else (e.g., a top level items)
> 
> First, we have to consider what needs to be returned in the link/relationship 
> category. If it were just _links.self.href, then grouping probably does not 
> make sense. However, since we have terms-of-service and privacy-policy as 
> well already, it may well make sense.
> 
> Moreover, when we think of a multi-tenant authorization server that may want 
> to use different OAuth authz and token endpoints f

Re: [OAUTH-WG] Registration: JSON Encoded Input

2013-02-12 Thread Tim Bray

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:

> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked over and one picked.
>

Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is
just POSTing JSON, must be missing something. -T


>
> In the other thread about the server returning the update URI and being
> able to encode the client in that if it needs to takes care of Servers that
> need that info in query parameters or the path to do the routing.
>
> The use of structure can be used to enhance readability and parsing of the
> input, and output.
>
> However we need to temper our urge to apply structure to everything.
>
> IT needs to be applied carefully otherwise we start looking like crazies.
>
> If we do it cautiously I am in favour of JSON as input.
>
> John B.
>
> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>
>  Thanks for forwarding that, Mike. I'll paste in my response to Nat's
> concern here as well:
>
> It's an increasingly well known pattern that has reasonable support on the
> server side. For PHP, I was able to find the above example via the top hit
> on Stack Overflow. In Ruby, it's a matter of something like:
>
> JSON.parse(request.body.read)
>
> depending on the web app framework. On Java/Spring, it's a matter of
> injecting the entity body as a string and handing it to a parser (Gson in
> this case):
>
> public String doApi(@RequestBody String jsonString) { JsonObject json =
> new JsonParser().parse(jsonString).getAsJsonObject();
>
> It's a similar read/parse setup in Node.js as well.
>
> It's true that in all of these cases you don't get to make use of the
> routing or data binding facilities (though in Spring you can do that for
> simpler domain objects using a ModelBinding), so you don't get niceities
> like the $_POST array in PHP handed to you. This is why I don't think it's
> a good idea at all to switch functionality based on the contents of the
> JSON object. It should be a domain object only, which is what it would be
> in this case.
>
> I think that the positives of using JSON from the client's perspective and
> the overall protocol design far outweigh the slightly increased
> implementation cost at the server.
>
>
>
>  -- Justin
>
> On 02/12/2013 02:11 PM, Mike Jones wrote:
>
> FYI, this issue is also being discussed as an OpenID Connect issue at
> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's
> recent comment there bears repeating on this list:
>
> ** **
>
> Nat Sakimura:
>
> ** **
>
> Not so sure. For example, PHP cannot get the JSON object form
> application/json POST in $_POST. 
>
> ** **
>
> It is OK to have a parameter like "request" that holds JSON. Then, you can
> get to it from $_POST['request']. However, if you POST the JSON as the POST
> body, then you would have to call a low level function in the form of: ***
> *
>
> ** **
>
> ** **
>
> ```
>
> #!php
>
> ** **
>
> $file = file_get_contents('php://input'); $x = json_decode($file); ```
>
> ** **
>
> Not that it is harder, but it is much less known. Many PHP programmers
> will certainly goes "???". 
>
> ** **
>
> We need to check what would be the cases for other scripting languages
> before making the final decision.
>
> ** **
>
> -- Mike
>
> ** **
>
> -Original Message-
> From: oauth-boun...@ietf.org 
> [mailto:oauth-boun...@ietf.org]
> On Behalf Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>
> ** **
>
> Draft -05 of OAuth Dynamic Client Registration [1] switched from a
> form-encoded input that had been used by drafts -01 through -04 to a JSON
> encoded input that was used originally in -00. Note that all versions keep
> JSON-encoded output from all operations.
>
> ** **
>
> Pro:
>
>   - JSON gives us a rich data structure so that things such as lists,
> numbers, nulls, and objects can be represented natively
>
>   - Allows for parallelism between the input to the endpoint and output
> from the endpoint, reducing possible translation errors between the two***
> *
>
>   - JSON specifies UTF8 encoding for all strings, forms may have many
> different encodings
>
>   - JSON has minimal character escaping required for most strings, forms
> require escaping for common characters such as space, slash, comma, etc.**
> **
>
> ** **
>
> Con:
>
>   - the rest of OAuth is form-in/JSON-out
>
>   - nothing else in OAuth requires the Client to create a JSON object,
> merely to parse one
>
>   - form-in/JSON-out is a very widely established pattern on the web today
> 
>
>   - Client information (client_name, client_id, etc.) is conflated with
> access information (regist

Re: [OAUTH-WG] Registration: JSON Encoded Input

Nat and I hashed out the pro's and cons of JSON requests.  

If we POST or PUT a JSON object we need to be specific as there rare several 
ways to do it that may work better or worse depending on the receiver.
This needs to be looked over and one picked.

In the other thread about the server returning the update URI and being able to 
encode the client in that if it needs to takes care of Servers that need that 
info in query parameters or the path to do the routing.

The use of structure can be used to enhance readability and parsing of the 
input, and output.

However we need to temper our urge to apply structure to everything.  

IT needs to be applied carefully otherwise we start looking like crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer  wrote:

> Thanks for forwarding that, Mike. I'll paste in my response to Nat's concern 
> here as well:
> It's an increasingly well known pattern that has reasonable support on the 
> server side. For PHP, I was able to find the above example via the top hit on 
> Stack Overflow. In Ruby, it's a matter of something like:
> 
> JSON.parse(request.body.read)
> 
> depending on the web app framework. On Java/Spring, it's a matter of 
> injecting the entity body as a string and handing it to a parser (Gson in 
> this case):
> 
> public String doApi(@RequestBody String jsonString) { JsonObject json = new 
> JsonParser().parse(jsonString).getAsJsonObject();
> 
> It's a similar read/parse setup in Node.js as well.
> 
> It's true that in all of these cases you don't get to make use of the routing 
> or data binding facilities (though in Spring you can do that for simpler 
> domain objects using a ModelBinding), so you don't get niceities like the 
> $_POST array in PHP handed to you. This is why I don't think it's a good idea 
> at all to switch functionality based on the contents of the JSON object. It 
> should be a domain object only, which is what it would be in this case.
> 
> I think that the positives of using JSON from the client's perspective and 
> the overall protocol design far outweigh the slightly increased 
> implementation cost at the server.
> 
> 
>  -- Justin
> 
> On 02/12/2013 02:11 PM, Mike Jones wrote:
>> FYI, this issue is also being discussed as an OpenID Connect issue at 
>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent 
>> comment there bears repeating on this list:
>>  
>> Nat Sakimura:
>>  
>> Not so sure. For example, PHP cannot get the JSON object form 
>> application/json POST in $_POST.
>>  
>> It is OK to have a parameter like "request" that holds JSON. Then, you can 
>> get to it from $_POST['request']. However, if you POST the JSON as the POST 
>> body, then you would have to call a low level function in the form of:
>>  
>>  
>> ```
>> #!php
>>  
>> $file = file_get_contents('php://input'); $x = json_decode($file); ```
>>  
>> Not that it is harder, but it is much less known. Many PHP programmers will 
>> certainly goes "???".
>>  
>> We need to check what would be the cases for other scripting languages 
>> before making the final decision.
>>  
>> -- Mike
>>  
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>  
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
>> form-encoded input that had been used by drafts -01 through -04 to a JSON 
>> encoded input that was used originally in -00. Note that all versions keep 
>> JSON-encoded output from all operations.
>>  
>> Pro:
>>   - JSON gives us a rich data structure so that things such as lists, 
>> numbers, nulls, and objects can be represented natively
>>   - Allows for parallelism between the input to the endpoint and output from 
>> the endpoint, reducing possible translation errors between the two
>>   - JSON specifies UTF8 encoding for all strings, forms may have many 
>> different encodings
>>   - JSON has minimal character escaping required for most strings, forms 
>> require escaping for common characters such as space, slash, comma, etc.
>>  
>> Con:
>>   - the rest of OAuth is form-in/JSON-out
>>   - nothing else in OAuth requires the Client to create a JSON object, 
>> merely to parse one
>>   - form-in/JSON-out is a very widely established pattern on the web today
>>   - Client information (client_name, client_id, etc.) is conflated with 
>> access information (registration_access_token, _links, expires_at, etc.) in 
>> root level of the same JSON object, leaving the client to decide what needs 
>> to (can?) be sent back to the server for update operations.
>>  
>>  
>> Alternatives include any number of data encoding schemes, including form 
>> (like the old drafts), XML, ASN.1, etc.
>>  
>>  
>>   -- Justin

Re: [OAUTH-WG] Registration: JSON Encoded Input

Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
concern here as well:


   It's an increasingly well known pattern that has reasonable support
   on the server side. For PHP, I was able to find the above example
   via the top hit on Stack Overflow. In Ruby, it's a matter of
   something like:

   JSON.parse(request.body.read)

   depending on the web app framework. On Java/Spring, it's a matter of
   injecting the entity body as a string and handing it to a parser
   (Gson in this case):

   public String doApi(@RequestBody String jsonString) { JsonObject
   json = new JsonParser().parse(jsonString).getAsJsonObject();

   It's a similar read/parse setup in Node.js as well.

   It's true that in all of these cases you don't get to make use of
   the routing or data binding facilities (though in Spring you can do
   that for simpler domain objects using a ModelBinding), so you don't
   get niceities like the $_POST array in PHP handed to you. This is
   why I don't think it's a good idea at all to switch functionality
   based on the contents of the JSON object. It should be a domain
   object only, which is what it would be in this case.

   I think that the positives of using JSON from the client's
   perspective and the overall protocol design far outweigh the
   slightly increased implementation cost at the server.



 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:


FYI, this issue is also being discussed as an OpenID Connect issue at 
https://bitbucket.org/openid/connect/issue/747. I think that Nat's 
recent comment there bears repeating on this list:


Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form 
application/json POST in $_POST.


It is OK to have a parameter like "request" that holds JSON. Then, you 
can get to it from $_POST['request']. However, if you POST the JSON as 
the POST body, then you would have to call a low level function in the 
form of:


```

#!php

$file = file_get_contents('php://input'); $x = json_decode($file); ```

Not that it is harder, but it is much less known. Many PHP programmers 
will certainly goes "???".


We need to check what would be the cases for other scripting languages 
before making the final decision.


-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf 
Of Justin Richer

Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
form-encoded input that had been used by drafts -01 through -04 to a 
JSON encoded input that was used originally in -00. Note that all 
versions keep JSON-encoded output from all operations.


Pro:

  - JSON gives us a rich data structure so that things such as lists, 
numbers, nulls, and objects can be represented natively


  - Allows for parallelism between the input to the endpoint and 
output from the endpoint, reducing possible translation errors between 
the two


  - JSON specifies UTF8 encoding for all strings, forms may have many 
different encodings


  - JSON has minimal character escaping required for most strings, 
forms require escaping for common characters such as space, slash, 
comma, etc.


Con:

  - the rest of OAuth is form-in/JSON-out

  - nothing else in OAuth requires the Client to create a JSON object, 
merely to parse one


  - form-in/JSON-out is a very widely established pattern on the web today

  - Client information (client_name, client_id, etc.) is conflated 
with access information (registration_access_token, _links, 
expires_at, etc.) in root level of the same JSON object, leaving the 
client to decide what needs to (can?) be sent back to the server for 
update operations.


Alternatives include any number of data encoding schemes, including 
form (like the old drafts), XML, ASN.1, etc.


  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

___

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

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Part of the REST/JSON philosophy is that interfaces should be as simple and 
developer-friendly as possible.  XML was rejected by developers, in part, 
because of the self-describing nature of the structure, which required extra 
syntax that was often not useful in practice.  Trying to re-impose that 
structure using extra JSON syntax conventions is just asking developers to have 
an allergic reaction to our specs upon encountering them.  The syntactic 
complexity and *surprise factor* isn't worth the limited semantic benefits of 
using "_links".

Since you bring up privacy policy and terms of service, I'll note that the 
OAuth Dynamic Registration spec already has these fields to address those:
policy_url
tos_url

Those have been working fine for OpenID Connect too.  There's no need to 
likewise convolve them to add the extra syntax that you describe below.

(BTW, in a private thread, John Bradley pointed out that what the two of you 
talked about in person was actually the possibility of adding privacy policy 
and terms of service declarations at *discovery time*, rather than registration 
time.  That's a different topic, which we should discuss separately, if you 
want to pursue that.)

Best wishes,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Actually, if it is to return it in the HTTP header, then it should also use the 
RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it would 
be a hassle to obtain the header and store them in addition to the JSON. So, it 
is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such as 
registration_access_url and _links.self.href does not make any difference from 
a client programmers point of view. That's a beauty of JSON. Both can be 
treated as a parameter name. Doing a group operation on the links makes 
difference though: the structured one is easier since you can just operate on 
_links while in case of the top level parameters, you have to have an explicit 
list of them and do the matches. (See below for the necessity for the grouping).

I and John discussed this for at least half an hour F2F last week, both 
technically and from operation/legal point of view, for OpenID Connect 
Registration.
Similar points could be made to OAuth dyn reg.

Here is what we have discussed:

When dynamically registering the client to the server, the server probably 
needs to return the following:

  * terms-of-service (terms of service of the server to the client)
  * privacy-policy (privacy policy of the server to the client)

Both are defined in RFC5988/IANA Link Relations registry.


They should be returned together with

  * self.href

which is also defined in RFC5988/IANA Link Relations registry.

There are several ways to do it.

  * Return these using RFC5988 (HTTP Header)
  * Return these in entity body
  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

Returning it in the entity body has several advantage over HTTP header:

  * They can be captured in one call;
  * They are protocol agnostic;

We determined that these advantages outweighs the disadvantage of creating a 
new standard.

The question becomes then whether to:

  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

First, we have to consider what needs to be returned in the link/relationship 
category. If it were just _links.self.href, then grouping probably does not 
make sense. However, since we have terms-of-service and privacy-policy as well 
already, it may well make sense.

Moreover, when we think of a multi-tenant authorization server that may want to 
use different OAuth authz and token endpoints for different tennants, it would 
be better to be able to return those in the registration response. Then, it 
would make sense to register OAuth authz and token endpoints as rel type in the 
IANA registry (like Bill Mills is trying to
do) and use them in a uniform manner. Note: these per tenant endpoints may 
support different scopes etc. as well. Then, these has to be coupled with the 
URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of just 
having the URL as the value of the parameter. The semantic relationship would 
often have an associated URI, and other parameters that goes with it.

e.g.:

{
"_links": {
"terms-of-service": {
"href": "https: //server.example.com/tos"
},
"privacy-policy": {
"href": "https: //server.example.com/pp"
},
"self": {
"href": "https

Re: [OAUTH-WG] Registration: JSON Encoded Input

FYI, this issue is also being discussed as an OpenID Connect issue at 
https://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent 
comment there bears repeating on this list:



Nat Sakimura:



Not so sure. For example, PHP cannot get the JSON object form application/json 
POST in $_POST.



It is OK to have a parameter like "request" that holds JSON. Then, you can get 
to it from $_POST['request']. However, if you POST the JSON as the POST body, 
then you would have to call a low level function in the form of:





```

#!php



$file = file_get_contents('php://input'); $x = json_decode($file); ```



Not that it is harder, but it is much less known. Many PHP programmers will 
certainly goes "???".



We need to check what would be the cases for other scripting languages before 
making the final decision.



-- Mike



-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input



Draft -05 of OAuth Dynamic Client Registration [1] switched from a form-encoded 
input that had been used by drafts -01 through -04 to a JSON encoded input that 
was used originally in -00. Note that all versions keep JSON-encoded output 
from all operations.



Pro:

  - JSON gives us a rich data structure so that things such as lists, numbers, 
nulls, and objects can be represented natively

  - Allows for parallelism between the input to the endpoint and output from 
the endpoint, reducing possible translation errors between the two

  - JSON specifies UTF8 encoding for all strings, forms may have many different 
encodings

  - JSON has minimal character escaping required for most strings, forms 
require escaping for common characters such as space, slash, comma, etc.



Con:

  - the rest of OAuth is form-in/JSON-out

  - nothing else in OAuth requires the Client to create a JSON object, merely 
to parse one

  - form-in/JSON-out is a very widely established pattern on the web today

  - Client information (client_name, client_id, etc.) is conflated with access 
information (registration_access_token, _links, expires_at, etc.) in root level 
of the same JSON object, leaving the client to decide what needs to (can?) be 
sent back to the server for update operations.





Alternatives include any number of data encoding schemes, including form (like 
the old drafts), XML, ASN.1, etc.





  -- Justin



[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

___

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

Re: [OAUTH-WG] Registration: RESTful client lifecycle management


On 2013-02-12, at 1:39 PM, Justin Richer  wrote:

> 
> On 02/12/2013 11:30 AM, John Bradley wrote:
>> To some extent we want the server to have the flexibility it needs.
>> 
>> If the server knows it is going to need client_id for GET it needs to encode 
>> it in the resource URI ether as part of the path or as a query parameter 
>> (that is up to the server)
>> 
>> When doing updates the client MUST include the client_id as an additional 
>> integrity check.  Some servers may switch on that but that is up to them.
> So if by this you mean that the client still simply follows whatever update 
> url the server hands it (which may or may not include the client_id in some 
> form, but the client doesn't care), and that the client MUST include its 
> client_id in the request body (top-level member of a JSON object, at the 
> moment) when doing a PUT (or POST/PATCH? see below) for the update action, 
> then I'm totally fine with that. Is this what you're suggesting?

Yes but It is a suggestion others may still hate it.
> 
>> If we want incremental replace (not resetting claims not sent to there 
>> defaults) then we need POST for update.
>> I think if you want to do the REST thing and be pure about PUT it needs to 
>> reset all values not sent to there defaults.
> 
> I agree with this argument in terms of the purity, and as I would rather see 
> the different verb used for different actions, I am willing to give up the 
> semantics of the not-resetting-claims that's in there right now for this 
> action. There's actually another HTTP verb, PATCH, that isn't used much but 
> is meant for partial updates, and we could transfer the not-resetting-claims 
> action to this instead.

Yes PATCH would represent the incremental update but we are getting further 
from the beaten path here. 

> 
>> I suppose we could have both but two ways of doing it leads to confusion.
> 
> I agree that we can't do both PUT and POST, and we can't have both partial 
> and complete replacement on the same verb/endpoint combination. We need to 
> pick one combination and have it be clear.
> 
> -- Justin
> 
>> On 2013-02-12, at 11:52 AM, Justin Richer  wrote:
>> 
>>> The problem that I have with "always including the client_id" is *where* to 
>>> include it. Are we talking a query parameter, URI template, or somewhere in 
>>> the request body? The latter will only work for POST and PUT, so it's out 
>>> of the question to support GET and DELETE using that semantic. I think we 
>>> should support all operations using parallel syntax -- that's just good API 
>>> design.
>>> 
>>> I *really* don't like the idea of switching the action solely based on 
>>> whether or not the client_id is present in the request body of a POST. This 
>>> is a side-effectful mode switch, and it will only lead to pain and misery. 
>>> Additionally, if the input is JSON (separate discussion), then a server 
>>> would have to parse the JSON body before knowing where to route the 
>>> request. In most web development frameworks that I've used, this is 
>>> impossible. A query parameter or URL pattern, on the other hand, is doable.
>>> 
>>> As it stands right now, a server is free to include the client_id in the 
>>> "update/management" URL that it returns as part of the _link structure 
>>> (separate discussion). The current text goes as far as recommending that 
>>> practice, but doesn't take the step of requiring it in any form, and 
>>> leaving it up to the server to decide what form it takes. If a server can 
>>> route better with a query parameter, it'll return a URL to the client that 
>>> has a client_id= query parameter. If a server would rather use a path 
>>> component with the client_id, it can do that, too. If it wants to put 
>>> everything on one URL and differentiate through the request body or 
>>> presence/absence of the registration_access_token, it can always return the 
>>> same URL to every client. I think that's nuts, but you can do it. 
>>> Interoperability is preserved because the client simply follows the 
>>> returned URL to do its bits and pieces, and it doesn't ever have to create 
>>> or compose this URL from component parts.
>>> 
>>> I want to continue to distinguish between the POST and PUT operations for 
>>> create and update, respectively. This is a common pattern and the one 
>>> described in the original REST thesis that described the architectural 
>>> style. I'll also bring up that the semantics of PUT are intended to be 
>>> "replace all", which is what you had originally argued for in the update 
>>> case as well. I not convinced that developers of today can't handle HTTP 
>>> verbs like PUT if they want to do fancier operations like updates. Note 
>>> that the core operations, create and read, remain as POST and GET, which 
>>> would be well within the grasp of every library and web developer today.
>>> 
>>> -- Justin
>>> 
>>> On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
 +1 for always including the client_id
 
>>>

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

I agree, and the "must include client_id" gels with the other discussion 
of doing a full-replace for the PUT operation for updates from another 
thread.


 -- Justin

On 02/12/2013 01:37 PM, Mike Jones wrote:

Then I think we've reached an acceptable resolution on this one.  By having the 
server return the registration_access_url upon create and having the client be 
required to include the client_id upon update, servers are free to manage their 
registration endpoint(s) as they see fit and clients always do the same thing.

Thanks all,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 9:15 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

2013/2/13 Justin Richer :

On 02/12/2013 11:30 AM, John Bradley wrote:

To some extent we want the server to have the flexibility it needs.

If the server knows it is going to need client_id for GET it needs to
encode it in the resource URI ether as part of the path or as a query
parameter (that is up to the server)

When doing updates the client MUST include the client_id as an
additional integrity check.  Some servers may switch on that but that is up to 
them.

So if by this you mean that the client still simply follows whatever
update url the server hands it (which may or may not include the
client_id in some form, but the client doesn't care), and that the
client MUST include its client_id in the request body (top-level
member of a JSON object, at the
moment) when doing a PUT (or POST/PATCH? see below) for the update
action, then I'm totally fine with that. Is this what you're suggesting?

As far as I understand, yes. That is what we discussed last Thursday face to 
face.


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

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

Then I think we've reached an acceptable resolution on this one.  By having the 
server return the registration_access_url upon create and having the client be 
required to include the client_id upon update, servers are free to manage their 
registration endpoint(s) as they see fit and clients always do the same thing.

Thanks all,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 9:15 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

2013/2/13 Justin Richer :
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>>
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to 
>> encode it in the resource URI ether as part of the path or as a query 
>> parameter (that is up to the server)
>>
>> When doing updates the client MUST include the client_id as an 
>> additional integrity check.  Some servers may switch on that but that is up 
>> to them.
>
> So if by this you mean that the client still simply follows whatever 
> update url the server hands it (which may or may not include the 
> client_id in some form, but the client doesn't care), and that the 
> client MUST include its client_id in the request body (top-level 
> member of a JSON object, at the
> moment) when doing a PUT (or POST/PATCH? see below) for the update 
> action, then I'm totally fine with that. Is this what you're suggesting?

As far as I understand, yes. That is what we discussed last Thursday face to 
face.


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

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

2013-02-12 Thread Torsten Lodderstedt


Am 12.02.2013 um 15:57 schrieb Justin Richer :

> 
> I think that's a very important difference.

I fully agree.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Client secret rotation

+1


From: John Bradley
Sent: 2/12/2013 8:20 AM
To: Justin Richer
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Client secret rotation

Yes, that agrees with my thoughts on it.

John B.
On 2013-02-12, at 11:29 AM, Justin Richer  wrote:

> This is actually the approach that I favor now as well -- let the server do 
> the secret rotation if it wants to, and have the client be prepared to 
> receive a new client_secret or registration_access_token on any read or 
> update request.
>
> This would necessitate changing the returned values, essentially collapsing 
> the returns from the read/update and rotate actions into one structure that's 
> closer to the one returned from initial registration. This has the added 
> benefit of parallelizing the responses for these three actions, which I like 
> as well.
>
> -- Justin
>
> On 02/11/2013 08:42 PM, John Bradley wrote:
>> OAuth doesn't say anything about client secrets other than they are 
>> provisioned in a magic realm outside the OAuth spec (Getting in the mood for 
>> the next IETF).
>>
>> Rotating client secrets was something I made up for connect because it 
>> seemed like a good idea at the time given that someone breaking in to the 
>> registration endpoint could take over a connection.
>>
>> We later separated the authentication to the token endpoint from the 
>> registration endpoint,in what I think was a good move.
>>
>> It is sort of up to the authorization server to make decisions about 
>> rotating client secrets, I expect that in the real world a client would try 
>> access ing the token endpoint and get back a invalid_client error response 
>> and then heck it's registration to see if the client_secret has changed.
>>
>> I suppose that a client could request rotating its secret if it thinks it 
>> has been compromised,  however the compromiser is more likely to quickly 
>> change the secret to lock out the legitimate clients before the good one 
>> notices.I think the client wanting to rotate is enough of a edge case 
>> that it could deal with it out of band.
>>
>> Letting the server rotate the client secret according to what ever policy it 
>> decides is best is probably safest.
>>
>> We didn't have anything for rotating the access token.  I suspect that 
>> rotating it under the clients control is going to create as many problems as 
>> it solves.
>>
>> If you want to rotate it,  make it a refresh token that is issues and use 
>> OAuth to provide access tokens from the token endpoint.   Creating a new 
>> endpoint to duplicate existing OAuth functionality is overkill.
>>
>> John B.
>> On 2013-02-11, at 10:18 PM, Mike Jones  wrote:
>>
>>> The rotate_secret operation was added to OpenID Connect Registration as a 
>>> workaround to the fact that registration updates used to be authenticated 
>>> using the client secret, so it seemed overly dangerous to have an update 
>>> operation potentially return an updated secret and have the secret be lost 
>>> due to communication problems - leaving the client stranded.  Since then, 
>>> registration was changed to use a bearer token to authenticate update 
>>> operations, and so this failure mode can't occur anymore.  It was an 
>>> omission not to have deleted the unneeded operation then.
>>>
>>> It's been deleted from OpenID Connect Registration and should likewise be 
>>> deleted from OAuth registration, since it is unneeded.  If a new client 
>>> secret is needed, there's nothing stopping the registration server from 
>>> returning it in the result of an update operation.
>>>
>>>  -- Mike
>>>
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>>> Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the 
>>> client requesting a new client_secret (if applicable) and a new 
>>> registration_access_token. Client secrets MAY expire after some period of 
>>> time, and this method allows for a refresh of that secret. Draft -00 
>>> defined no such operation, drafts -01 through -04 defined this operation in 
>>> terms of the operation=rotate_secret parameter, and draft -05 defines it 
>>> through a secondary endpoint, the Client Secret Rotation Endpoint.
>>> This raises several questions:
>>>
>>>  - Should the client be allowed to request rotation of its secret?
>>>  - Would a client ever take this action of its own accord?
>>>  - Can a server rotate the secret of the client without the client asking? 
>>> (This seems to be an obvious "yes")
>>>
>>> Alternatives that keep this functionality include defining the 
>>> rotate_secret operation in terms of an HTTP verb, a query parameter, or 
>>> separate endpoint. Alternatively, we could drop the rotate_secret operation 
>>> all together. If we do this, we h

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

That's my reading of it as well, Phil, thanks for providing the 
clarification. One motivator behind using a JSON-based token is to be 
able to re-use some of the great work that the JOSE group is doing but 
apply it to an HTTP payload.


What neither of us want is a token type that requires stuffing all 
query, header, and other parameters *into* the JSON object itself, which 
would be a more SOAPy approach.


 -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:

Clarification.  I think Justin and I were in agreement that we don't want to 
see a format that requires JSON payloads.  We are both interested in a JSON 
token used in the authorization header that could be based on a computed 
signature of some combination of http headers and body if possible.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:


Here are my notes.

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes:

My slides are available here: 
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls.

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a starting point 
because it does not re-use any of the work done in the JOSE working group and 
in particular all the libraries that are available today. He mentioned that 
earlier attempts to write the MAC Token code lead to problems for implementers.

Justin responded that he does not agree with using JSON as a transport 
mechanism since this would replicate a SOAP style.

Phil noted that he wants to send JSON but the signature shall be computed over 
the HTTP header field.

-- Flexibility for the keyed message digest computation

 From earlier discussion it was clear that the conference call participants 
wanted more flexibility regarding the keyed message digest computation. For 
this purpose Hannes presented the DKIM based approach, which allows selective 
header fields to be included in the digest. This is shown in slide #4.

After some discussion the conference call participants thought that this would 
meet their needs. Further investigations would still be useful to determine the 
degree of failed HMAC calculations due to HTTP proxies modifying the content.

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. 
Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
the preferred style. Justin and others didn't see the need to decide on one 
mechanism - they wanted to keep the choice open. Derek indicated that this will 
not be an acceptable approach. Since the resource server and the authorization 
server may, in the OAuth 2.0 framework, be entities produced by different 
vendors there is an interoperability need. Justin responded that he disagrees 
and that the resource server needs to understand the access token and referred 
to the recent draft submission for the token introspection endpoint. Derek 
indicated that the resource server has to understand the content of the access 
token and the token introspection endpoint just pushes the problem around: the 
resource server has to send the access token to the authorization server and 
then the resource server gets the result back (which he the

n

   a

gain needs to understand) in order to make a meaningful authorization decision.

Everyone agreed that the client must receive the session key from the 
authorization server and that this approach has to be standardized. It was also 
agreed that this is a common approach among all three key distribution 
mechanisms.

Hannes asked the participants to think about their preference.

The questions regarding key naming and the indication for the intended resource 
server the client wants to talk to have been postponed.

Ciao
Hannes


___
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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread Phil Hunt

Clarification.  I think Justin and I were in agreement that we don't want to 
see a format that requires JSON payloads.  We are both interested in a JSON 
token used in the authorization header that could be based on a computed 
signature of some combination of http headers and body if possible.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:

> Here are my notes. 
> 
> Participants:
> 
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
> 
> Notes: 
> 
> My slides are available here: 
> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> 
> Slide #2 summarizes earlier discussions during the conference calls. 
> 
> -- HTTP vs. JSON
> 
> Phil noted that he does not like to use the MAC Token draft as a starting 
> point because it does not re-use any of the work done in the JOSE working 
> group and in particular all the libraries that are available today. He 
> mentioned that earlier attempts to write the MAC Token code lead to problems 
> for implementers. 
> 
> Justin responded that he does not agree with using JSON as a transport 
> mechanism since this would replicate a SOAP style. 
> 
> Phil noted that he wants to send JSON but the signature shall be computed 
> over the HTTP header field. 
> 
> -- Flexibility for the keyed message digest computation
> 
> From earlier discussion it was clear that the conference call participants 
> wanted more flexibility regarding the keyed message digest computation. For 
> this purpose Hannes presented the DKIM based approach, which allows selective 
> header fields to be included in the digest. This is shown in slide #4. 
> 
> After some discussion the conference call participants thought that this 
> would meet their needs. Further investigations would still be useful to 
> determine the degree of failed HMAC calculations due to HTTP proxies 
> modifying the content. 
> 
> -- Key Distribution
> 
> Hannes presented the open issue regarding the choice of key distribution. 
> Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
> the preferred style. Justin and others didn't see the need to decide on one 
> mechanism - they wanted to keep the choice open. Derek indicated that this 
> will not be an acceptable approach. Since the resource server and the 
> authorization server may, in the OAuth 2.0 framework, be entities produced by 
> different vendors there is an interoperability need. Justin responded that he 
> disagrees and that the resource server needs to understand the access token 
> and referred to the recent draft submission for the token introspection 
> endpoint. Derek indicated that the resource server has to understand the 
> content of the access token and the token introspection endpoint just pushes 
> the problem around: the resource server has to send the access token to the 
> authorization server and then the resource server gets the result back (which 
> he then
  a
> gain needs to understand) in order to make a meaningful authorization 
> decision. 
> 
> Everyone agreed that the client must receive the session key from the 
> authorization server and that this approach has to be standardized. It was 
> also agreed that this is a common approach among all three key distribution 
> mechanisms.
> 
> Hannes asked the participants to think about their preference. 
> 
> The questions regarding key naming and the indication for the intended 
> resource server the client wants to talk to have been postponed. 
> 
> Ciao
> Hannes
> 
> 
> ___
> 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-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-02.txt

This is the second rev of the metadata spec that we discussed at IETF
85 OAuth WG and subsequently the chairs asked for the draft.

Nat

-- Forwarded message --
From:  
Date: 2013/2/13
Subject: New Version Notification for draft-sakimura-oauth-meta-02.txt
To: sakim...@gmail.com
Cc: m...@stateless.co

A new version of I-D, draft-sakimura-oauth-meta-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:draft-sakimura-oauth-meta
Revision:02
Title:   JSON Metadata for OAuth Responses 1.0
Creation date:   2013-02-12
WG ID:   Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-02.txt
Status:  http://datatracker.ietf.org/doc/draft-sakimura-oauth-meta
Htmlized:http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
Diff:http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-02

Abstract:
   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_links"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.

The IETF Secretariat

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

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

2013/2/13 Justin Richer :
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>>
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to
>> encode it in the resource URI ether as part of the path or as a query
>> parameter (that is up to the server)
>>
>> When doing updates the client MUST include the client_id as an additional
>> integrity check.  Some servers may switch on that but that is up to them.
>
> So if by this you mean that the client still simply follows whatever update
> url the server hands it (which may or may not include the client_id in some
> form, but the client doesn't care), and that the client MUST include its
> client_id in the request body (top-level member of a JSON object, at the
> moment) when doing a PUT (or POST/PATCH? see below) for the update action,
> then I'm totally fine with that. Is this what you're suggesting?

As far as I understand, yes. That is what we discussed last Thursday
face to face.


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

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Actually, if it is to return it in the HTTP header, then it should
also use the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that
it would be a hassle to obtain the header and store them in addition
to the JSON. So, it is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such
as registration_access_url and _links.self.href does not make any
difference from a
client programmers point of view. That's a beauty of JSON. Both can be
treated as a parameter name. Doing a group operation on the links makes
difference though: the structured one is easier since you can just operate
on _links while in case of the top level parameters, you have to have an
explicit list of them and do the matches. (See below for the necessity
for the grouping).

I and John discussed this for at least half an hour F2F last week, both
technically and from operation/legal point of view, for OpenID Connect
Registration.
Similar points could be made to OAuth dyn reg.

Here is what we have discussed:

When dynamically registering the client to the server,
the server probably needs to return the following:

  * terms-of-service (terms of service of the server to the client)
  * privacy-policy (privacy policy of the server to the client)

Both are defined in RFC5988/IANA Link Relations registry.


They should be returned together with

  * self.href

which is also defined in RFC5988/IANA Link Relations registry.

There are several ways to do it.

  * Return these using RFC5988 (HTTP Header)
  * Return these in entity body
  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

Returning it in the entity body has several advantage over HTTP header:

  * They can be captured in one call;
  * They are protocol agnostic;

We determined that these advantages outweighs the disadvantage of creating
a new standard.

The question becomes then whether to:

  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

First, we have to consider what needs to be returned in the
link/relationship category. If it were just _links.self.href, then grouping
probably does not make sense. However, since we have terms-of-service and
privacy-policy as well already, it may well make sense.

Moreover, when we think of a multi-tenant authorization server that may
want to use different OAuth authz and token endpoints for different
tennants, it would be better to be able to return those in the registration
response. Then, it would make sense to register OAuth authz and token
endpoints as rel type in the IANA registry (like Bill Mills is trying to
do) and use them in a uniform manner. Note: these per tenant endpoints may
support different scopes etc. as well. Then, these has to be coupled with
the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of
just having the URL as the value of the parameter. The semantic
relationship would often have an associated URI, and other parameters that
goes with it.

e.g.:

{
"_links": {
"terms-of-service": {
"href": "https: //server.example.com/tos"
},
"privacy-policy": {
"href": "https: //server.example.com/pp"
},
"self": {
"href": "https: //server.example.com/clients/1234",
"authorize": "Bearer"
},
"oauth_authz": {
"href": "https: //server.example.com/authz",
"scopes": "openid profile email",
"response_types": [
"token id_token",
"code id_token",
"token",
"code"
]
},
"oauth_token": {
"href": "https: //server.example.com/token",
"authorize": "Basic"
}
}
}

In short, there are bunch of link relations that needs to be returned
with additional parameters.
Grouping them seems to make sense.

Considering all these, John and I came to the conclusion that the HAL type
syntax would probably make more sense.
(Note: JSON Schema syntax does not make the parameter access as easy as HAL.)

In fact, Mike Kelly (the author of HAL) and I have just submit
a new version of draft-sakimura-oauth-meta

   http://tools.ietf.org/html/draft-sakimura-oauth-meta-02

The proposal was discussed at IETF 85 OAuth WG and the chairs asked to
submit the draft.
The -00 appeared in December, and this -02 has some simplification and
the addition
of the "operations" inspired by
https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
It is arguably a subset of HAL plus some OAuth specifics.
I have not added Discovery response example,
but adding them would makes even more sense, I think.

Cheers,

Nat


2013/2/13 Justin Richer 
>
> Agreed - I didn't think that header-only was the proposal, but let's be 
> explicit about the returned body always contain

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

The token may or may not need to be encrypted on top of being signed.  All 
tokens red to be signed.

If the Key is asymmetric or using DH key agreement it would not need to be 
encrypted. 
If it is a symmetric key then yes you need to use encrypted key transport.   
The JOSE working group is working on a clean method of using JOSE fro Key 
transport.
We should align with that.

In some ways ECDH-ES would be perfect for this, but I am realistic about 
adoption.

If we fall back to regular DH then if RS's have a way of communicating there DH 
info to the AS then when the client requests a token providing it's DH info the 
server can place that in the token and return the RS's info in a separate 
parameter to the client and the key is never sent over the wire, so no 
encryption needed.  

One problem is that who the intended RS is may be a touch vague in OAuth. (This 
affects both key transport and agreement.)  so the AS may not know what the RS 
is if it is not explicit in the scope.

That may lead us to make asymmetric keys (including the public key of the 
client)  as the default as that is the only one that works with both known and 
unknown RS.

You could design a DH floe to work where the RS on request failures provides 
its DH info and then the client passes that and it's info to the AS in the 
token request.
That works but sort of messes up the flow.

John B.



On 2013-02-12, at 7:06 AM, William Mills  wrote:

> For key exchange that's true for symmetric key, but no key exchange is 
> required for public key signing by the client.
> 
> There's so many possibilities here, but I think the best is that the key 
> materiel is conveyed in the token.  The key could be included directly, or 
> another way to implement would be that a salt is included in the token and 
> then the secret is some crypto hash of the token contents and a shared secret 
> between the AS and the PR.  
> 
> If we we must pick one I'd say include the signing key as part of the 
> encrypted token itself.  Completely self contained then.
> 
> From: Hannes Tschofenig 
> To: William Mills  
> Cc: Hannes Tschofenig ; IETF oauth WG 
>  
> Sent: Tuesday, February 12, 2013 1:44 AM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
> 11th February 2013
> 
> Hi Bill, 
> 
> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
> 
> > Is key distribution how AS and PR share keys  for token 
> > encryption/decryption or specifically about the keys for the HOK tokens?
> > 
> In order for the client to compute the keyed message digest it needs to have 
> the session key. This session key is sent from the authorization server to 
> the client and everyone on the call agreed that this has to be standardized. 
> 
> The resource server who receives the message from the client also needs to 
> have the session key to verify the message. How the resource server obtains 
> this session key was subject for some discussion on the call. I presented 
> three different ways of how the resource server is able to obtain that key. 
> We have to decide on one mandatory-to-implement mechanism. The open issue is 
> which one? 
> 
> > For the MAC token spec, I don't actually care whether we use JSON or now, 
> > but I'm in full agreement that we do NOT duplicate any HTTP info into the 
> > JSON.  Just signatures of that stuff.
> > 
> I believe the folks on the call also agreed with you on that aspect that the 
> content of the HTTP message should not be replicated in the JSON payload 
> itself. 
> 
> Ciao
> Hannes
> 
> > From: Hannes Tschofenig 
> > To: IETF oauth WG  
> > Sent: Tuesday, February 12, 2013 1:10 AM
> > Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
> > 11th February 2013
> > 
> > Here are my notes. 
> > 
> > Participants:
> > 
> > * John Bradley
> > * Derek Atkins
> > * Phil Hunt
> > * Prateek Mishra
> > * Hannes Tschofenig
> > * Mike Jones
> > * Antonio Sanso
> > * Justin Richer
> > 
> > Notes: 
> > 
> > My slides are available here: 
> > http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> > 
> > Slide #2 summarizes earlier discussions during the conference calls. 
> > 
> > -- HTTP vs. JSON
> > 
> > Phil noted that he does not like to use the MAC Token draft as a starting 
> > point because it does not re-use any of the work done in the JOSE working 
> > group and in particular all the libraries that are available today. He 
> > mentioned that earlier attempts to write the MAC Token code lead to 
> > problems for implementers. 
> > 
> > Justin responded that he does not agree with using JSON as a transport 
> > mechanism since this would replicate a SOAP style. 
> > 
> > Phil noted that he wants to send JSON but the signature shall be computed 
> > over the HTTP header field. 
> > 
> > -- Flexibility for the keyed message digest computation
> > 
> > From earlier discussion it was clear that the conference call participants 
> > wanted more flexibility regarding the keyed message digest c

Re: [OAUTH-WG] Registration: RESTful client lifecycle management



On 02/12/2013 11:30 AM, John Bradley wrote:

To some extent we want the server to have the flexibility it needs.

If the server knows it is going to need client_id for GET it needs to encode it 
in the resource URI ether as part of the path or as a query parameter (that is 
up to the server)

When doing updates the client MUST include the client_id as an additional 
integrity check.  Some servers may switch on that but that is up to them.
So if by this you mean that the client still simply follows whatever 
update url the server hands it (which may or may not include the 
client_id in some form, but the client doesn't care), and that the 
client MUST include its client_id in the request body (top-level member 
of a JSON object, at the moment) when doing a PUT (or POST/PATCH? see 
below) for the update action, then I'm totally fine with that. Is this 
what you're suggesting?



If we want incremental replace (not resetting claims not sent to there 
defaults) then we need POST for update.
I think if you want to do the REST thing and be pure about PUT it needs to 
reset all values not sent to there defaults.


I agree with this argument in terms of the purity, and as I would rather 
see the different verb used for different actions, I am willing to give 
up the semantics of the not-resetting-claims that's in there right now 
for this action. There's actually another HTTP verb, PATCH, that isn't 
used much but is meant for partial updates, and we could transfer the 
not-resetting-claims action to this instead.



I suppose we could have both but two ways of doing it leads to confusion.


I agree that we can't do both PUT and POST, and we can't have both 
partial and complete replacement on the same verb/endpoint combination. 
We need to pick one combination and have it be clear.


 -- Justin


On 2013-02-12, at 11:52 AM, Justin Richer  wrote:


The problem that I have with "always including the client_id" is *where* to 
include it. Are we talking a query parameter, URI template, or somewhere in the request 
body? The latter will only work for POST and PUT, so it's out of the question to support 
GET and DELETE using that semantic. I think we should support all operations using 
parallel syntax -- that's just good API design.

I *really* don't like the idea of switching the action solely based on whether 
or not the client_id is present in the request body of a POST. This is a 
side-effectful mode switch, and it will only lead to pain and misery. 
Additionally, if the input is JSON (separate discussion), then a server would 
have to parse the JSON body before knowing where to route the request. In most 
web development frameworks that I've used, this is impossible. A query 
parameter or URL pattern, on the other hand, is doable.

As it stands right now, a server is free to include the client_id in the 
"update/management" URL that it returns as part of the _link structure 
(separate discussion). The current text goes as far as recommending that practice, but 
doesn't take the step of requiring it in any form, and leaving it up to the server to 
decide what form it takes. If a server can route better with a query parameter, it'll 
return a URL to the client that has a client_id= query parameter. If a server would 
rather use a path component with the client_id, it can do that, too. If it wants to put 
everything on one URL and differentiate through the request body or presence/absence of 
the registration_access_token, it can always return the same URL to every client. I think 
that's nuts, but you can do it. Interoperability is preserved because the client simply 
follows the returned URL to do its bits and pieces, and it doesn't ever have to create or 
compose this URL from component parts.

I want to continue to distinguish between the POST and PUT operations for create and 
update, respectively. This is a common pattern and the one described in the original REST 
thesis that described the architectural style. I'll also bring up that the semantics of 
PUT are intended to be "replace all", which is what you had originally argued 
for in the update case as well. I not convinced that developers of today can't handle 
HTTP verbs like PUT if they want to do fancier operations like updates. Note that the 
core operations, create and read, remain as POST and GET, which would be well within the 
grasp of every library and web developer today.

-- Justin

On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:

+1 for always including the client_id

As John pointed out, there could be different entities updating client data. 
Then one has to distinguish the resource and the credential.

Am 12.02.2013 um 02:51 schrieb John Bradley :


I would always include the client_id on update.

I think it is also us full to have other tokens used at the update endpoint.  I 
can see the master token used to update all the clients it has registered as 
part of API management.
Relying on the registration_access_token is probably a desig

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

To some extent we want the server to have the flexibility it needs.

If the server knows it is going to need client_id for GET it needs to encode it 
in the resource URI ether as part of the path or as a query parameter (that is 
up to the server)

When doing updates the client MUST include the client_id as an additional 
integrity check.  Some servers may switch on that but that is up to them.

If we want incremental replace (not resetting claims not sent to there 
defaults) then we need POST for update.  
I think if you want to do the REST thing and be pure about PUT it needs to 
reset all values not sent to there defaults.

I suppose we could have both but two ways of doing it leads to confusion.

John B.

On 2013-02-12, at 11:52 AM, Justin Richer  wrote:

> The problem that I have with "always including the client_id" is *where* to 
> include it. Are we talking a query parameter, URI template, or somewhere in 
> the request body? The latter will only work for POST and PUT, so it's out of 
> the question to support GET and DELETE using that semantic. I think we should 
> support all operations using parallel syntax -- that's just good API design.
> 
> I *really* don't like the idea of switching the action solely based on 
> whether or not the client_id is present in the request body of a POST. This 
> is a side-effectful mode switch, and it will only lead to pain and misery. 
> Additionally, if the input is JSON (separate discussion), then a server would 
> have to parse the JSON body before knowing where to route the request. In 
> most web development frameworks that I've used, this is impossible. A query 
> parameter or URL pattern, on the other hand, is doable.
> 
> As it stands right now, a server is free to include the client_id in the 
> "update/management" URL that it returns as part of the _link structure 
> (separate discussion). The current text goes as far as recommending that 
> practice, but doesn't take the step of requiring it in any form, and leaving 
> it up to the server to decide what form it takes. If a server can route 
> better with a query parameter, it'll return a URL to the client that has a 
> client_id= query parameter. If a server would rather use a path component 
> with the client_id, it can do that, too. If it wants to put everything on one 
> URL and differentiate through the request body or presence/absence of the 
> registration_access_token, it can always return the same URL to every client. 
> I think that's nuts, but you can do it. Interoperability is preserved because 
> the client simply follows the returned URL to do its bits and pieces, and it 
> doesn't ever have to create or compose this URL from component parts.
> 
> I want to continue to distinguish between the POST and PUT operations for 
> create and update, respectively. This is a common pattern and the one 
> described in the original REST thesis that described the architectural style. 
> I'll also bring up that the semantics of PUT are intended to be "replace 
> all", which is what you had originally argued for in the update case as well. 
> I not convinced that developers of today can't handle HTTP verbs like PUT if 
> they want to do fancier operations like updates. Note that the core 
> operations, create and read, remain as POST and GET, which would be well 
> within the grasp of every library and web developer today.
> 
> -- Justin
> 
> On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
>> +1 for always including the client_id
>> 
>> As John pointed out, there could be different entities updating client data. 
>> Then one has to distinguish the resource and the credential.
>> 
>> Am 12.02.2013 um 02:51 schrieb John Bradley :
>> 
>>> I would always include the client_id on update.
>>> 
>>> I think it is also us full to have other tokens used at the update 
>>> endpoint.  I can see the master token used to update all the clients it has 
>>> registered as part of API management.
>>> Relying on the registration_access_token is probably a design that will 
>>> cause trouble down the road.
>>> 
>>> I think GET and POST are relatively clear.   I don't know about expelling 
>>> PUT to developers.  I think POST with a client_id to a (separate 
>>> discussion) update_uri works without restricting it to PUT.
>>> 
>>> I think DELETE needs to be better understood.   I think a status that can 
>>> be set for client lifecycle is better than letting a client delete a entry.
>>> In some cases there will be more than one instance of a client and letting 
>>> them know they have been turned off for a reason is better than making 
>>> there registration disappear.
>>> So for the moment I would levee out DELETE.
>>> 
>>> John B.
>>> 
>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>> 
 Draft -05 of OAuth Dynamic Client Registration [1] defines several 
 operations that the client can take on its behalf as part of the 
 registration process. These boil down to the basic CRUD operations that 
 you f

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Agreed - I didn't think that header-only was the proposal, but let's be 
explicit about the returned body always containing the URL. The way I 
read the 201 definition, it suggests (SHOULD) that you use the location 
header, but also says that the entity should refer to the new resource. 
It was my assumption that the returned JSON would still have some form 
of client-entity management URL (whether it's the HAL _links structure 
or registration_management_url or something else is still up for debate).


 -- Justin


On 02/12/2013 10:28 AM, John Bradley wrote:
Returning a location header in the 201 ids fine as long as we also 
have the same info as a claim.


I think most clients will want to process the JSON and store all the 
parameters together.  Making them fish out a header makes the W3C 
happy and is the correct thing to do but taking it from a claim is 
what developers are more comfortable with.


John B.

On 2013-02-12, at 11:25 AM, Justin Richer > wrote:


I'd be fine with the return from a creation request being a 201 
instead of a 200.


 -- Justin

On 02/11/2013 06:33 PM, Richard Harrington wrote:
Since the request is an HTTP POST and a resource is created 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the 
response should be an HTTP 201 Created 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) 
which is supposed to include the location of the newly created resource.


This is a good pattern to follow since, as you say, it does provide 
flexibility.




On Feb 11, 2013, at 1:14 PM, Justin Richer > wrote:


Draft -05 of OAuth Dynamic Client Registration [1] returns a URL 
pointer for the client to perform update and secret rotation 
actions. This functionality arose from discussions on the list 
about moving towards a more RESTful pattern, and Nat Sakimura 
proposed this approach in the OpenID Connect Working Group. This 
URL may be distinct from the Client Registration Endpoint URL, but 
draft -05 makes no promises as to its content, form, or structure, 
though it does contain implementor's notes on possible methods.


Two questions arise from this change:
- The semantics of returning the client manipulation URL
- The syntax (derived from HAL for JSON [2], an individual I-D 
submission)


On semantics:

Pro:
- The server has flexibility on how to define the "update" 
endpoint, sending all clients to one URL, sending different clients 
to different URLs, or sending clients to a URL with a baked-in 
query parameter
- The client can take the URL as-is and use it for all management 
operations (ie, it doesn't have to generate or compose the URL 
based on component parts)


Con:
- The client must remember one more piece of information from the 
server at runtime if it wants to do manipulation and management of 
itself at the server (in addition to client_id, client_secret, 
registration_access_token, and others)


Alternatives include specifying a URL pattern for the server to use 
and all clients to follow, specifying a query parameter for the 
update action, and specifying a separate endpoint entirely and 
using the presence of items such as client_id and the registration 
access token to differentiate the requests. Note that *all* of 
these alternatives can be accommodated using the semantics 
described above, with the same actions on the client's part.



On syntax:

Pro:
- Follows the designs of RFC5988 for link relations
- The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
- Allows for full use of the JSON object to specify advanced 
operations on the returned endpoint if desired


Con:
- The rest of OAuth doesn't follow link relation guidelines (though 
it's been brought up)
- The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
- The HAL-JSON document is an expired individual I-D, and it's 
unclear what wider adoption looks like right now


Alternatives include returning the URL as a separate data member 
(registration_update_url), using HTTP headers, or using JSON Schema.


-- Justin



[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
___
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

Re: [OAUTH-WG] Registration: Client secret rotation

Yes, that agrees with my thoughts on it.

John B.
On 2013-02-12, at 11:29 AM, Justin Richer  wrote:

> This is actually the approach that I favor now as well -- let the server do 
> the secret rotation if it wants to, and have the client be prepared to 
> receive a new client_secret or registration_access_token on any read or 
> update request.
> 
> This would necessitate changing the returned values, essentially collapsing 
> the returns from the read/update and rotate actions into one structure that's 
> closer to the one returned from initial registration. This has the added 
> benefit of parallelizing the responses for these three actions, which I like 
> as well.
> 
> -- Justin
> 
> On 02/11/2013 08:42 PM, John Bradley wrote:
>> OAuth doesn't say anything about client secrets other than they are 
>> provisioned in a magic realm outside the OAuth spec (Getting in the mood for 
>> the next IETF).
>> 
>> Rotating client secrets was something I made up for connect because it 
>> seemed like a good idea at the time given that someone breaking in to the 
>> registration endpoint could take over a connection.
>> 
>> We later separated the authentication to the token endpoint from the 
>> registration endpoint,in what I think was a good move.
>> 
>> It is sort of up to the authorization server to make decisions about 
>> rotating client secrets, I expect that in the real world a client would try 
>> access ing the token endpoint and get back a invalid_client error response 
>> and then heck it's registration to see if the client_secret has changed.
>> 
>> I suppose that a client could request rotating its secret if it thinks it 
>> has been compromised,  however the compromiser is more likely to quickly 
>> change the secret to lock out the legitimate clients before the good one 
>> notices.I think the client wanting to rotate is enough of a edge case 
>> that it could deal with it out of band.
>> 
>> Letting the server rotate the client secret according to what ever policy it 
>> decides is best is probably safest.
>> 
>> We didn't have anything for rotating the access token.  I suspect that 
>> rotating it under the clients control is going to create as many problems as 
>> it solves.
>> 
>> If you want to rotate it,  make it a refresh token that is issues and use 
>> OAuth to provide access tokens from the token endpoint.   Creating a new 
>> endpoint to duplicate existing OAuth functionality is overkill.
>> 
>> John B.
>> On 2013-02-11, at 10:18 PM, Mike Jones  wrote:
>> 
>>> The rotate_secret operation was added to OpenID Connect Registration as a 
>>> workaround to the fact that registration updates used to be authenticated 
>>> using the client secret, so it seemed overly dangerous to have an update 
>>> operation potentially return an updated secret and have the secret be lost 
>>> due to communication problems - leaving the client stranded.  Since then, 
>>> registration was changed to use a bearer token to authenticate update 
>>> operations, and so this failure mode can't occur anymore.  It was an 
>>> omission not to have deleted the unneeded operation then.
>>> 
>>> It's been deleted from OpenID Connect Registration and should likewise be 
>>> deleted from OAuth registration, since it is unneeded.  If a new client 
>>> secret is needed, there's nothing stopping the registration server from 
>>> returning it in the result of an update operation.
>>> 
>>> -- Mike
>>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>>> Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>> 
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the 
>>> client requesting a new client_secret (if applicable) and a new 
>>> registration_access_token. Client secrets MAY expire after some period of 
>>> time, and this method allows for a refresh of that secret. Draft -00 
>>> defined no such operation, drafts -01 through -04 defined this operation in 
>>> terms of the operation=rotate_secret parameter, and draft -05 defines it 
>>> through a secondary endpoint, the Client Secret Rotation Endpoint.
>>> This raises several questions:
>>> 
>>>  - Should the client be allowed to request rotation of its secret?
>>>  - Would a client ever take this action of its own accord?
>>>  - Can a server rotate the secret of the client without the client asking? 
>>> (This seems to be an obvious "yes")
>>> 
>>> Alternatives that keep this functionality include defining the 
>>> rotate_secret operation in terms of an HTTP verb, a query parameter, or 
>>> separate endpoint. Alternatively, we could drop the rotate_secret operation 
>>> all together. If we do this, we have to decide if the client secret can 
>>> still expire. If it can, then we need a way for the client to get this new 
>>> secret through a means that doesn't require it to

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

2013-02-12 Thread Prabath Siriwardena

Hi Justin,

I doubt whether valid_token would make a difference..?

My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..

If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:

>  OK, I can see the wisdom in changing this term.
>
> I picked "valid" because I wanted a simple "boolean" value that would
> require no additional parsing or string-matching on the client's behalf,
> and I'd like to stick with that. OAuth is built with the assumption that
> clients need to be able to recover from invalid tokens at any stage, so I
> think a simple yes/no is the right step here.
>
> That said, I think you're both right that "valid" seems to have caused a
> bit of confusion. I don't want to go with "revoked" because I'd rather have
> the "token is OK" be the positive boolean value.
>
> Would "valid_token" be more clear? Or do we need a different adjective all
> together?
>
>  -- Justin
>
>
> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>
> Have you considered "status" instead of "valid"?  It could have values
> like "active", "expired", and "revoked".
>
>  Is it worthwhile including the status of the client also?  For example,
> a client application could be disabled, temporarily or permanently, and
> thus disabling its access tokens as well.
>
>
> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  wrote:
>
>  I guess confusion is with 'valid' parameter is in the response..
>
>  I thought this will be helpful to standardize the communication between
> Resource Server and the Authorization Server..
>
>  I would suggest we completely remove "valid" from the response - or
> define it much clearly..
>
>  May be can add "revoked" with a boolean attribute..
>
>  Thanks & regards,
> -Prabath
>
> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:
>
>>
>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>
>> Hi Justin,
>>
>>  I have couple of questions related to "valid" parameter...
>>
>>  This endpoint can be invoked by the Resource Server in runtime...
>>
>>
>> That's correct.
>>
>>
>>
>>  In that case what is exactly meant by the "resource_id" in request ?
>>
>>
>>  The resource_id field is a service-specific string that basically lets
>> the resource server provide some context to the request to the auth server.
>> There have been some other suggestions like client IP address, but I wanted
>> to put this one in because it seemed to be a common theme. The client is
>> trying to do *something* with the token, after all, and the rights,
>> permissions, and metadata associated with the token could change based on
>> that. Since the Introspection endpoint is all about getting that metadata
>> back to the PR, this seemed like a good idea.
>>
>>
>>
>>  IMO a token to be valid depends on set of criteria based on it's type..
>>
>>  For a Bearer token..
>>
>>  1. Token should not be expired
>> 2. Token should not be revoked.
>> 3. The scope the token issued should match with the scope required for
>> the resource.
>>
>>  For a MAC token...
>>
>>  1. Token not expired (mac id)
>> 2. Token should not be revoked
>> 3. The scope the token issued should match with the scope required for
>> the resource.
>> 4. HMAC check should be valid
>>
>>  There are similar conditions for SAML bearer too..
>>
>>
>>  This isn't really true. The SAML bearer token is fully self-contained
>> and doesn't change based on other parameters in the message, unlike MAC.
>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>> given *everything* the server needs to check that token's validity and use.
>>
>> MAC signatures change with every message, and they're done across several
>> components of the HTTP message. Therefor, the HMAC check for MAC style
>> tokens will still need to be done by the protected resource. Introspection
>> would help in the case that the signature validated just fine, but the
>> token might have expired. Or you need to know what scopes apply.
>> Introspection isn't to fully validate the call to the protected resource --
>> if that were the case, the PR would have to send some kind of encapsulated
>> version of the original request. Otherwise, the AS won't have all of the
>> information it needs to check the MAC.
>>
>>
>> I think what you're describing is ultimately *not* what the introspection
>> endpoint is intended to do. If that's unclear from the document, can you
>> please suggest text that would help clear the use case up? I wouldn't want
>> it to be ambiguous.
>>
>>  -- Justin
>>
>>
>>
>>  Thanks & regards,
>> -Prabath
>>
>>
>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:
>>
>>>  It validates the token, which would be either the token itself in the
>>> case of Bearer or the token "id" part of something more complex like MAC.
>>> It doesn't directly validate the usage of the token, that's still up to the
>>

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread William Mills

One of the things I do not like about a MTI key transport mechanism if we put 
it in the token is that there will be some systems that already have a per user 
secret provisioned and we'll be forcing data duplication.  If if the encrypted 
token already includes any random component that could easily be used as part 
of the signing key.  So I feel like this will fatten up the token, potentially 
a lot.

If we don't put it in the token this problem is WAY harder.



 From: Hannes Tschofenig 
To: Antonio Sanso  
Cc: Hannes Tschofenig ; William Mills 
; IETF oauth WG  
Sent: Tuesday, February 12, 2013 3:06 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013
 
The transport of the session key from the authorization server is described in 
Section 5.1 and is called "mac_key". 

The mechanism to transport the session key from the authorization server to the 
resource server is not yet described in the document. This has historical 
reasons: OAuth 1.0 did not separate the authorization server from the resource 
server in the way OAuth 2.0 does.

Ciao
Hannes

On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:

> Hi Hannes,
> 
> how this session key "differs" from the key described in the current draft 
> [0]?
> 
> Thanks and regards
> 
> Antonio
> 
> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
> 
> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
> 
>> Hi Bill, 
>> 
>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>> 
>>> Is key distribution how AS and PR share keys  for token 
>>> encryption/decryption or specifically about the keys for the HOK tokens?
>>> 
>> In order for the client to compute the keyed message digest it needs to have 
>> the session key. This session key is sent from the authorization server to 
>> the client and everyone on the call agreed that this has to be standardized. 
>> 
>> The resource server who receives the message from the client also needs to 
>> have the session key to verify the message. How the resource server obtains 
>> this session key was subject for some discussion on the call. I presented 
>> three different ways of how the resource server is able to obtain that key. 
>> We have to decide on one mandatory-to-implement mechanism. The open issue is 
>> which one? 
>> 
>>> For the MAC token spec, I don't actually care whether we use JSON or now, 
>>> but I'm in full agreement that we do NOT duplicate any HTTP info into the 
>>> JSON.  Just signatures of that stuff.
>>> 
>> I believe the folks on the call also agreed with you on that aspect that the 
>> content of the HTTP message should not be replicated in the JSON payload 
>> itself. 
>> 
>> Ciao
>> Hannes
>> 
>>> From: Hannes Tschofenig 
>>> To: IETF oauth WG  
>>> Sent: Tuesday, February 12, 2013 1:10 AM
>>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>>> 11th February 2013
>>> 
>>> Here are my notes. 
>>> 
>>> Participants:
>>> 
>>> * John Bradley
>>> * Derek Atkins
>>> * Phil Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig
>>> * Mike Jones
>>> * Antonio Sanso
>>> * Justin Richer
>>> 
>>> Notes: 
>>> 
>>> My slides are available here: 
>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>> 
>>> Slide #2 summarizes earlier discussions during the conference calls. 
>>> 
>>> -- HTTP vs. JSON
>>> 
>>> Phil noted that he does not like to use the MAC Token draft as a starting 
>>> point because it does not re-use any of the work done in the JOSE working 
>>> group and in particular all the libraries that are available today. He 
>>> mentioned that earlier attempts to write the MAC Token code lead to 
>>> problems for implementers. 
>>> 
>>> Justin responded that he does not agree with using JSON as a transport 
>>> mechanism since this would replicate a SOAP style. 
>>> 
>>> Phil noted that he wants to send JSON but the signature shall be computed 
>>> over the HTTP header field. 
>>> 
>>> -- Flexibility for the keyed message digest computation
>>> 
>>> From earlier discussion it was clear that the conference call participants 
>>> wanted more flexibility regarding the keyed message digest computation. For 
>>> this purpose Hannes presented the DKIM based approach, which allows 
>>> selective header fields to be included in the digest. This is shown in 
>>> slide #4. 
>>> 
>>> After some discussion the conference call participants thought that this 
>>> would meet their needs. Further investigations would still be useful to 
>>> determine the degree of failed HMAC calculations due to HTTP proxies 
>>> modifying the content. 
>>> 
>>> -- Key Distribution
>>> 
>>> Hannes presented the open issue regarding the choice of key distribution. 
>>> Slides #6-#8 present three techniques and Hannes asked for feedback 
>>> regarding the preferred style. Justin and others didn't see the need to 
>>> decide on one mechanism - they wanted to keep the choice open. Derek 
>>> indicated that

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Returning a location header in the 201 ids fine as long as we also have the 
same info as a claim.

I think most clients will want to process the JSON and store all the parameters 
together.  Making them fish out a header makes the W3C happy and is the correct 
thing to do but taking it from a claim is what developers are more comfortable 
with.

John B.

On 2013-02-12, at 11:25 AM, Justin Richer  wrote:

> I'd be fine with the return from a creation request being a 201 instead of a 
> 200. 
> 
>  -- Justin
> 
> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>> Since the request is an HTTP POST and a resource is created 
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response 
>> should be an HTTP 201 Created 
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is 
>> supposed to include the location of the newly created resource.
>> 
>> This is a good pattern to follow since, as you say, it does provide 
>> flexibility.
>> 
>> 
>> 
>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>> 
>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer 
>>> for the client to perform update and secret rotation actions. This 
>>> functionality arose from discussions on the list about moving towards a 
>>> more RESTful pattern, and Nat Sakimura proposed this approach in the OpenID 
>>> Connect Working Group. This URL may be distinct from the Client 
>>> Registration Endpoint URL, but draft -05 makes no promises as to its 
>>> content, form, or structure, though it does contain implementor's notes on 
>>> possible methods.
>>> 
>>> Two questions arise from this change:
>>> - The semantics of returning the client manipulation URL
>>> - The syntax (derived from HAL for JSON [2], an individual I-D submission)
>>> 
>>> On semantics:
>>> 
>>> Pro:
>>> - The server has flexibility on how to define the "update" endpoint, 
>>> sending all clients to one URL, sending different clients to different 
>>> URLs, or sending clients to a URL with a baked-in query parameter
>>> - The client can take the URL as-is and use it for all management 
>>> operations (ie, it doesn't have to generate or compose the URL based on 
>>> component parts)
>>> 
>>> Con:
>>> - The client must remember one more piece of information from the server at 
>>> runtime if it wants to do manipulation and management of itself at the 
>>> server (in addition to client_id, client_secret, registration_access_token, 
>>> and others)
>>> 
>>> Alternatives include specifying a URL pattern for the server to use and all 
>>> clients to follow, specifying a query parameter for the update action, and 
>>> specifying a separate endpoint entirely and using the presence of items 
>>> such as client_id and the registration access token to differentiate the 
>>> requests. Note that *all* of these alternatives can be accommodated using 
>>> the semantics described above, with the same actions on the client's part.
>>> 
>>> 
>>> On syntax:
>>> 
>>> Pro:
>>> - Follows the designs of RFC5988 for link relations
>>> - The HAL format is general, and allows for all kinds of other information 
>>> to be placed inside the _links structure
>>> - Allows for full use of the JSON object to specify advanced operations on 
>>> the returned endpoint if desired
>>> 
>>> Con:
>>> - The rest of OAuth doesn't follow link relation guidelines (though it's 
>>> been brought up)
>>> - The HAL format is general, and allows for all kinds of other information 
>>> to be placed inside the _links structure
>>> - The HAL-JSON document is an expired individual I-D, and it's unclear what 
>>> wider adoption looks like right now
>>> 
>>> Alternatives include returning the URL as a separate data member 
>>> (registration_update_url), using HTTP headers, or using JSON Schema.
>>> 
>>> -- Justin
>>> 
>>> 
>>> 
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>> ___
>>> 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

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

I would be OK with the change to registration_access_url or something 
similar to that. The main argument against it is that we'd be inventing 
a bespoke field for something that's already covered out there by the 
HTTP Linked Data world. Nat did a good job of trying to generalize 
concepts of linked OAuth metadata with


   http://tools.ietf.org/html/draft-sakimura-oauth-meta-01

I don't think it's inherently silly to try and generalize the problem, 
but I can appreciate the argument that such generalization could be 
overkill in this instance.


 -- Justin

On 02/11/2013 08:12 PM, Mike Jones wrote:

It seems like significant overkill, bordering on silliness, to use the syntax
   _links: {
 "self": {
   "href":
   "https://server.example.com/register/s6BhdRkqt3";
   }
   }
to represent a value that could be more straightforwardly represented as:
   "registration_access_url": "https://server.example.com/register/s6BhdRkqt3";

Even some of the advocates for it have called it "pedantic".  I believe that 
most developers would have less charitable things to say about it, and would wonder why 
we're trying to foist needless complexity on them.

I'll also point out that this syntax is based upon an expired individual 
submission draft http://tools.ietf.org/html/draft-kelly-json-hal-03 that is not 
in any working group.  I don't believe we should take a dependence on this 
draft or this syntax.

Occam's razor says that this isn't needed.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer for 
the client to perform update and secret rotation actions. This functionality 
arose from discussions on the list about moving towards a more RESTful pattern, 
and Nat Sakimura proposed this approach in the OpenID Connect Working Group. 
This URL may be distinct from the Client Registration Endpoint URL, but draft 
-05 makes no promises as to its content, form, or structure, though it does 
contain implementor's notes on possible methods.

Two questions arise from this change:
   - The semantics of returning the client manipulation URL
   - The syntax (derived from HAL for JSON [2], an individual I-D
submission)

On semantics:

Pro:
   - The server has flexibility on how to define the "update" endpoint, sending 
all clients to one URL, sending different clients to different URLs, or sending clients 
to a URL with a baked-in query parameter
   - The client can take the URL as-is and use it for all management operations 
(ie, it doesn't have to generate or compose the URL based on component parts)

Con:
   - The client must remember one more piece of information from the server at 
runtime if it wants to do manipulation and management of itself at the server 
(in addition to client_id, client_secret, registration_access_token, and others)

Alternatives include specifying a URL pattern for the server to use and all 
clients to follow, specifying a query parameter for the update action, and 
specifying a separate endpoint entirely and using the presence of items such as 
client_id and the registration access token to differentiate the requests. Note 
that *all* of these alternatives can be accommodated using the semantics 
described above, with the same actions on the client's part.


On syntax:

Pro:
   - Follows the designs of RFC5988 for link relations
   - The HAL format is general, and allows for all kinds of other information 
to be placed inside the _links structure
   - Allows for full use of the JSON object to specify advanced operations on 
the returned endpoint if desired

Con:
   - The rest of OAuth doesn't follow link relation guidelines (though it's 
been brought up)
   - The HAL format is general, and allows for all kinds of other information 
to be placed inside the _links structure
   - The HAL-JSON document is an expired individual I-D, and it's unclear what 
wider adoption looks like right now

Alternatives include returning the URL as a separate data member 
(registration_update_url), using HTTP headers, or using JSON Schema.

   -- Justin



[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
___
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

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

So, I think we agree in general, but to be explicit: I want a server to 
be free to include the client_id as an input parameter if it wants to, 
but I would rather not have the client be required to compose that 
parameter onto the base registration URL on its own. This is to preserve 
the flexibility on the server side to deploy things as you describe 
below, but also to have URL path components as the identifier (common in 
REST frameworks) if it so chooses. The client shouldn't ever care which 
pattern the server wants to use. This is the motivation behind providing 
the client management URL as part of the response (separate discussion).


Also, for the record, OAuth 2.0 does not use the same endpoint for 
different things in the way you describe. To refresh a token, you send a 
request to the token endpoint with grant_type=refresh_token (section 6). 
The "grant_type" parameter is explicitly designed as a mode-switch 
parameter (for instance, see the discussion in section 4.5) and the 
refresh token flow is no different. Some early drafts of the OAuth 2.0 
core document even called out refresh token as a parallel "flow" with 
the rest of them, like authorization_code and implicit, but that seemed 
to confuse people more than it helped, so Eran pulled it into a separate 
section entirely. Nevertheless, the structure and syntax remains parallel.


 -- Justin



On 02/11/2013 08:26 PM, Mike Jones wrote:

At most, there should be two endpoints - creation and management - for a client, but the protocol 
should be structured such that they *can* be at the same URL, if the server so chooses.  A simple 
way to accomplish this is to require that the client_id value be provided as an input parameter on 
update operations.  Then for implementations that use a single endpoint, they can distinguish 
"create" and "update" operations on the management endpoint by the presence or 
absence of the client_id value.

If you want to have separate endpoints and don't need the client_id because you 
have somehow encoded it into the management endpoint URL, that's fine.  It 
still can serve as a useful cross-check that the client (or an attacker) is 
requesting a change to a client that matches the bearer token used.  But 
including it is necessary for implementations that want to use a single 
registration endpoint, rather than having a proliferation of per-client 
endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access 
token requests and requests for refreshed access tokens - with the operations 
being distinguished by whether a refresh_token parameter is present.  So 
there's a useful OAuth precedent for doing things this way.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can 
undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be 
differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the 
"register" operation, drafts -01 through -04 made use of an "operation" parameter on a 
single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate 
design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint 
and instead opted for separating the base functionality into three different endpoints.

Pro:
   - Closer to RESTful semantics of having one URL for creation and another URL 
for management of an item (eg, most REST APIs use /object for creation and 
/object/object_id for manipulation)
   - The rest of OAuth (and its extensions) defines separate endpoints for 
different actions (Authorization, Token, Revocation, Introspection) as opposed 
to a single endpoint with a mode-switch parameter
   - Client doesn't have to generate a URL string for different endpoints by 
combining parameters with a base URL

Con:
   - Not quite exactly RESTful as the spec doesn't dictate the client_id
be part of the update or rotate URL (though and implementor's note
suggests this)
   - Client has to track different URLs for different actions
   - Server must be able to differentiate actions based on these
different URLs.

Alternatives include using different HTTP verbs (see other thread) or
defining an operational switch parameter, like older drafts, on a single
endpoint URL. Another suggested alternative is to look for the presence
of certain parameters, such as client_id or the registration access
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the others.
It ha

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

2013-02-12 Thread Sergey Beryozkin


On 12/02/13 14:43, Tim Bray wrote:

?! /foo and /foo/bar are obviously distinct endpoints.


definitely yes from the client's  point of view, at the implementation 
level - it is the internal detail, right ?


Cheers, Sergey



On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" mailto:sberyoz...@gmail.com>> wrote:

Hi Mike,
On 12/02/13 01:26, Mike Jones wrote:

At most, there should be two endpoints - creation and management
- for a client, but the protocol should be structured such that
they *can* be at the same URL, if the server so chooses.  A
simple way to accomplish this is to require that the client_id
value be provided as an input parameter on update operations.
  Then for implementations that use a single endpoint, they can
distinguish "create" and "update" operations on the management
endpoint by the presence or absence of the client_id value.

Perhaps the text can be relaxed somehow to not refer to

/register
and
/register/{client_id}

as two different endpoints ? I think it is a single endpoint from
the implementation point of view :-).

Or may be the spec can indeed be relaxed a bit and allow for a PUT
form payload be sent directly to /register

Cheers, Sergey

If you want to have separate endpoints and don't need the
client_id because you have somehow encoded it into the
management endpoint URL, that's fine.  It still can serve as a
useful cross-check that the client (or an attacker) is
requesting a change to a client that matches the bearer token
used.  But including it is necessary for implementations that
want to use a single registration endpoint, rather than having a
proliferation of per-client endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for
initial access token requests and requests for refreshed access
tokens - with the operations being distinguished by whether a
refresh_token parameter is present.  So there's a useful OAuth
precedent for doing things this way.

 -- Mike

-Original Message-
From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org
__] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org 
Subject: [OAUTH-WG] Registration: Endpoint Definition (&
  operation parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three
fundamental operations that a client can undertake: Client
Registration, Client Update, and Secret Rotation. Each of these
actions needs to be differentiated *somehow* by the client and
server as part of the protocol. Draft -00 defined only the
"register" operation, drafts -01 through -04 made use of an
"operation" parameter on a single endpoint, which brought up a
long discussion on the list on whether or not that was an
appropriate design. Draft -05 did away with the definition of
the "operation" parameter on a single endpoint and instead opted
for separating the base functionality into three different
endpoints.

Pro:
- Closer to RESTful semantics of having one URL for creation
and another URL for management of an item (eg, most REST APIs
use /object for creation and /object/object_id for manipulation)
- The rest of OAuth (and its extensions) defines separate
endpoints for different actions (Authorization, Token,
Revocation, Introspection) as opposed to a single endpoint with
a mode-switch parameter
- Client doesn't have to generate a URL string for different
endpoints by combining parameters with a base URL

Con:
- Not quite exactly RESTful as the spec doesn't dictate the
client_id
be part of the update or rotate URL (though and implementor's note
suggests this)
- Client has to track different URLs for different actions
- Server must be able to differentiate actions based on these
different URLs.

Alternatives include using different HTTP verbs (see other
thread) or
defining an operational switch parameter, like older drafts, on
a single
endpoint URL. Another suggested alternative is to look for the
presence
of certain parameters, such as client_id or the registration access
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the
others.
It has been suggested off-list that the secret rotation

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

It can be argued that /foo  and /foo?provider=abc  are different URI resources.

Nat and I were recommending that the registration return a update URI that can 
be unique per client.

In the Apps for domains or Salesforce case the hosting client could be encoded 
into the path or a parameter if required, or it could even be a different host 
name if some client's data needed to be kept in a particular jurisdiction like 
Canada. (honestly there are laws to prevent you hosing data in the US) 

The update URI returned may also be exactly the same as the original create URI 
that should be left up to the Registration server.

Allowing the Registration server to set the update URI is the most flexible for 
supporting multi tenant and other use-cases.  

the only downside is that the client needs to remember what it is.  As the 
client needs to remember a secret and the locations of the endpoint's I don't 
think that is a large burden.

In reality the only clients possibly having a issue with that are going to be 
native clients, but they are generally registered and managed by a developer 
and not by individual client instances.

The problem is a native client is not going to keep it's secret for updating 
safe.   It would work if client instances create their own unique client_id, 
but at that point managing another parameter is the least of your worries.

John B.


On 2013-02-12, at 11:43 AM, Tim Bray  wrote:

> ?! /foo and /foo/bar are obviously distinct endpoints.
> 
> On Feb 12, 2013 3:25 AM, "Sergey Beryozkin"  wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
> At most, there should be two endpoints - creation and management - for a 
> client, but the protocol should be structured such that they *can* be at the 
> same URL, if the server so chooses.  A simple way to accomplish this is to 
> require that the client_id value be provided as an input parameter on update 
> operations.  Then for implementations that use a single endpoint, they can 
> distinguish "create" and "update" operations on the management endpoint by 
> the presence or absence of the client_id value.
> 
> Perhaps the text can be relaxed somehow to not refer to
> 
> /register
> and
> /register/{client_id}
> 
> as two different endpoints ? I think it is a single endpoint from the 
> implementation point of view :-).
> 
> Or may be the spec can indeed be relaxed a bit and allow for a PUT form 
> payload be sent directly to /register
> 
> Cheers, Sergey
> 
> If you want to have separate endpoints and don't need the client_id because 
> you have somehow encoded it into the management endpoint URL, that's fine.  
> It still can serve as a useful cross-check that the client (or an attacker) 
> is requesting a change to a client that matches the bearer token used.  But 
> including it is necessary for implementations that want to use a single 
> registration endpoint, rather than having a proliferation of per-client 
> endpoints.
> 
> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access 
> token requests and requests for refreshed access tokens - with the operations 
> being distinguished by whether a refresh_token parameter is present.  So 
> there's a useful OAuth precedent for doing things this way.
> 
> -- Mike
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation parameter)
> 
> Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental 
> operations that a client can undertake: Client Registration, Client Update, 
> and Secret Rotation. Each of these actions needs to be differentiated 
> *somehow* by the client and server as part of the protocol. Draft -00 defined 
> only the "register" operation, drafts -01 through -04 made use of an 
> "operation" parameter on a single endpoint, which brought up a long 
> discussion on the list on whether or not that was an appropriate design. 
> Draft -05 did away with the definition of the "operation" parameter on a 
> single endpoint and instead opted for separating the base functionality into 
> three different endpoints.
> 
> Pro:
>- Closer to RESTful semantics of having one URL for creation and another 
> URL for management of an item (eg, most REST APIs use /object for creation 
> and /object/object_id for manipulation)
>- The rest of OAuth (and its extensions) defines separate endpoints for 
> different actions (Authorization, Token, Revocation, Introspection) as 
> opposed to a single endpoint with a mode-switch parameter
>- Client doesn't have to generate a URL string for different endpoints by 
> combining parameters with a base URL
> 
> Con:
>- Not quite exactly RESTful as the spec doesn't dictate the client_id
> be part of the update or rotate URL (though and implementor's note
> suggests this

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)


Technically you could have your auth endpoint be:

/oauth?method=authorization

and your token endpoint be:

/oauth?method=token

and they're syntactically being served by the same URL. It's a 
deep-in-the-weeds argument of little value whether or not you consider 
these to be "separate endpoints" from the server perspective. You could 
also, if you so choose, define your endpoints to be the same URL and 
switch in a side-effectful fashion on parameters like response_type and 
grant_type. I think you'd be a bit nuts to do it that way, but you could 
pull it off.


The important thing is that because they're defined in the spec as 
"separate endpoints", all clients expect there to be one URL for authz 
and one for tokens, and so all clients have two slots for them. Clients 
are not expected to take one URL and add a parameter to *make* the other 
URL, they're expected to be given two URLs.


I think that's a very important difference.

 -- Justin

On 02/12/2013 02:17 AM, Torsten Lodderstedt wrote:

Hi Mike,

why do you think the protocol should allow to have two endpoints on the same 
URL? Even the core spec does not allow to map tokens and authorization endpoint 
to the same URL.

Regards,
Torsten.

Am 12.02.2013 um 02:26 schrieb Mike Jones :


At most, there should be two endpoints - creation and management - for a client, but the protocol 
should be structured such that they *can* be at the same URL, if the server so chooses.  A simple 
way to accomplish this is to require that the client_id value be provided as an input parameter on 
update operations.  Then for implementations that use a single endpoint, they can distinguish 
"create" and "update" operations on the management endpoint by the presence or 
absence of the client_id value.

If you want to have separate endpoints and don't need the client_id because you 
have somehow encoded it into the management endpoint URL, that's fine.  It 
still can serve as a useful cross-check that the client (or an attacker) is 
requesting a change to a client that matches the bearer token used.  But 
including it is necessary for implementations that want to use a single 
registration endpoint, rather than having a proliferation of per-client 
endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access 
token requests and requests for refreshed access tokens - with the operations 
being distinguished by whether a refresh_token parameter is present.  So 
there's a useful OAuth precedent for doing things this way.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can 
undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be 
differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the 
"register" operation, drafts -01 through -04 made use of an "operation" parameter on a 
single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate 
design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint 
and instead opted for separating the base functionality into three different endpoints.

Pro:
  - Closer to RESTful semantics of having one URL for creation and another URL 
for management of an item (eg, most REST APIs use /object for creation and 
/object/object_id for manipulation)
  - The rest of OAuth (and its extensions) defines separate endpoints for 
different actions (Authorization, Token, Revocation, Introspection) as opposed 
to a single endpoint with a mode-switch parameter
  - Client doesn't have to generate a URL string for different endpoints by 
combining parameters with a base URL

Con:
  - Not quite exactly RESTful as the spec doesn't dictate the client_id
be part of the update or rotate URL (though and implementor's note
suggests this)
  - Client has to track different URLs for different actions
  - Server must be able to differentiate actions based on these
different URLs.

Alternatives include using different HTTP verbs (see other thread) or
defining an operational switch parameter, like older drafts, on a single
endpoint URL. Another suggested alternative is to look for the presence
of certain parameters, such as client_id or the registration access
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the others.
It has been suggested off-list that the secret rotation should never be
initiated by the Client but instead the client should simply request its
latest secret from the server through the upd

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

The problem that I have with "always including the client_id" is *where*
to include it. Are we talking a query parameter, URI template, or
somewhere in the request body? The latter will only work for POST and
PUT, so it's out of the question to support GET and DELETE using that
semantic. I think we should support all operations using parallel syntax
-- that's just good API design.

I *really* don't like the idea of switching the action solely based on
whether or not the client_id is present in the request body of a POST.
This is a side-effectful mode switch, and it will only lead to pain and
misery. Additionally, if the input is JSON (separate discussion), then a
server would have to parse the JSON body before knowing where to route
the request. In most web development frameworks that I've used, this is
impossible. A query parameter or URL pattern, on the other hand, is doable.

As it stands right now, a server is free to include the client_id in the
"update/management" URL that it returns as part of the _link structure
(separate discussion). The current text goes as far as recommending that
practice, but doesn't take the step of requiring it in any form, and
leaving it up to the server to decide what form it takes. If a server
can route better with a query parameter, it'll return a URL to the
client that has a client_id= query parameter. If a server would rather
use a path component with the client_id, it can do that, too. If it
wants to put everything on one URL and differentiate through the request
body or presence/absence of the registration_access_token, it can always
return the same URL to every client. I think that's nuts, but you can do
it. Interoperability is preserved because the client simply follows the
returned URL to do its bits and pieces, and it doesn't ever have to
create or compose this URL from component parts.

I want to continue to distinguish between the POST and PUT operations
for create and update, respectively. This is a common pattern and the
one described in the original REST thesis that described the
architectural style. I'll also bring up that the semantics of PUT are
intended to be "replace all", which is what you had originally argued
for in the update case as well. I not convinced that developers of today
can't handle HTTP verbs like PUT if they want to do fancier operations
like updates. Note that the core operations, create and read, remain as
POST and GET, which would be well within the grasp of every library and
web developer today.

-- Justin

On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:

+1 for always including the client_id

As John pointed out, there could be different entities updating client data.
Then one has to distinguish the resource and the credential.

Am 12.02.2013 um 02:51 schrieb John Bradley :

I would always include the client_id on update.

I think it is also us full to have other tokens used at the update endpoint. I
can see the master token used to update all the clients it has registered as
part of API management.
Relying on the registration_access_token is probably a design that will cause
trouble down the road.

I think GET and POST are relatively clear. I don't know about expelling PUT
to developers. I think POST with a client_id to a (separate discussion)
update_uri works without restricting it to PUT.

I think DELETE needs to be better understood. I think a status that can be
set for client lifecycle is better than letting a client delete a entry.
In some cases there will be more than one instance of a client and letting them
know they have been turned off for a reason is better than making there
registration disappear.
So for the moment I would levee out DELETE.

John B.

On 2013-02-11, at 6:14 PM, Justin Richer wrote:

Draft -05 of OAuth Dynamic Client Registration [1] defines several operations that the client can take on its
behalf as part of the registration process. These boil down to the basic CRUD operations that you find in
many APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" operation, draft -01
through -04 added the "Update" operation, switched using the "operation=" parameter.

Following several suggestions to do so on the list, the -05 draft defines these
operations in terms of a RESTful API for the client. Namely:

- HTTP POST to registration endpoint => Create (register) a new client
- HTTP PUT to update endpoint (with registration_access_token) => Update the
registered information for this client
- HTTP GET to update endpoint (with registration_access_token) => read the
registered information for this client
- HTTP DELETE to update endpoint (with registration_access_token) => Delete
(unregister/de-provision) this client

The two main issues at stake here are: the addition of the READ and DELETE
methods, and the use of HTTP verbs following a RESTful design philosophy.

Pro:
- RESTful APIs (with HTTP verbs to differentiate functionality) a

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

2013-02-12 Thread Tim Bray

?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin"  wrote:

> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they *can* be at
>> the same URL, if the server so chooses.  A simple way to accomplish this is
>> to require that the client_id value be provided as an input parameter on
>> update operations.  Then for implementations that use a single endpoint,
>> they can distinguish "create" and "update" operations on the management
>> endpoint by the presence or absence of the client_id value.
>>
>>  Perhaps the text can be relaxed somehow to not refer to
>
> /register
> and
> /register/{client_id}
>
> as two different endpoints ? I think it is a single endpoint from the
> implementation point of view :-).
>
> Or may be the spec can indeed be relaxed a bit and allow for a PUT form
> payload be sent directly to /register
>
> Cheers, Sergey
>
>  If you want to have separate endpoints and don't need the client_id
>> because you have somehow encoded it into the management endpoint URL,
>> that's fine.  It still can serve as a useful cross-check that the client
>> (or an attacker) is requesting a change to a client that matches the bearer
>> token used.  But including it is necessary for implementations that want to
>> use a single registration endpoint, rather than having a proliferation of
>> per-client endpoints.
>>
>> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial
>> access token requests and requests for refreshed access tokens - with the
>> operations being distinguished by whether a refresh_token parameter is
>> present.  So there's a useful OAuth precedent for doing things this way.
>>
>> -- Mike
>>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org**] On Behalf
>> Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation
>> parameter)
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] defines three
>> fundamental operations that a client can undertake: Client Registration,
>> Client Update, and Secret Rotation. Each of these actions needs to be
>> differentiated *somehow* by the client and server as part of the protocol.
>> Draft -00 defined only the "register" operation, drafts -01 through -04
>> made use of an "operation" parameter on a single endpoint, which brought up
>> a long discussion on the list on whether or not that was an appropriate
>> design. Draft -05 did away with the definition of the "operation" parameter
>> on a single endpoint and instead opted for separating the base
>> functionality into three different endpoints.
>>
>> Pro:
>>- Closer to RESTful semantics of having one URL for creation and
>> another URL for management of an item (eg, most REST APIs use /object for
>> creation and /object/object_id for manipulation)
>>- The rest of OAuth (and its extensions) defines separate endpoints
>> for different actions (Authorization, Token, Revocation, Introspection) as
>> opposed to a single endpoint with a mode-switch parameter
>>- Client doesn't have to generate a URL string for different endpoints
>> by combining parameters with a base URL
>>
>> Con:
>>- Not quite exactly RESTful as the spec doesn't dictate the client_id
>> be part of the update or rotate URL (though and implementor's note
>> suggests this)
>>- Client has to track different URLs for different actions
>>- Server must be able to differentiate actions based on these
>> different URLs.
>>
>> Alternatives include using different HTTP verbs (see other thread) or
>> defining an operational switch parameter, like older drafts, on a single
>> endpoint URL. Another suggested alternative is to look for the presence
>> of certain parameters, such as client_id or the registration access
>> token, to indicate that a different operation is requested.
>>
>> There's also question of whether the Secret Rotation action needs to
>> have its own endpoint, or if it can be collapsed into one of the others.
>> It has been suggested off-list that the secret rotation should never be
>> initiated by the Client but instead the client should simply request its
>> latest secret from the server through the update (or read) semantics.
>>
>>-- Justin
>>
>> [1] 
>> http://tools.ietf.org/html/**draft-ietf-oauth-dyn-reg-05
>> __**_
>> 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
>>
>
>

Re: [OAUTH-WG] Registration: Client secret rotation

This is actually the approach that I favor now as well -- let the server 
do the secret rotation if it wants to, and have the client be prepared 
to receive a new client_secret or registration_access_token on any read 
or update request.


This would necessitate changing the returned values, essentially 
collapsing the returns from the read/update and rotate actions into one 
structure that's closer to the one returned from initial registration. 
This has the added benefit of parallelizing the responses for these 
three actions, which I like as well.


 -- Justin

On 02/11/2013 08:42 PM, John Bradley wrote:

OAuth doesn't say anything about client secrets other than they are provisioned 
in a magic realm outside the OAuth spec (Getting in the mood for the next IETF).

Rotating client secrets was something I made up for connect because it seemed 
like a good idea at the time given that someone breaking in to the registration 
endpoint could take over a connection.

We later separated the authentication to the token endpoint from the 
registration endpoint,in what I think was a good move.

It is sort of up to the authorization server to make decisions about rotating 
client secrets, I expect that in the real world a client would try access ing 
the token endpoint and get back a invalid_client error response and then heck 
it's registration to see if the client_secret has changed.

I suppose that a client could request rotating its secret if it thinks it has 
been compromised,  however the compromiser is more likely to quickly change the 
secret to lock out the legitimate clients before the good one notices.I 
think the client wanting to rotate is enough of a edge case that it could deal 
with it out of band.

Letting the server rotate the client secret according to what ever policy it 
decides is best is probably safest.

We didn't have anything for rotating the access token.  I suspect that rotating 
it under the clients control is going to create as many problems as it solves.

If you want to rotate it,  make it a refresh token that is issues and use OAuth 
to provide access tokens from the token endpoint.   Creating a new endpoint to 
duplicate existing OAuth functionality is overkill.

John B.
On 2013-02-11, at 10:18 PM, Mike Jones  wrote:


The rotate_secret operation was added to OpenID Connect Registration as a 
workaround to the fact that registration updates used to be authenticated using 
the client secret, so it seemed overly dangerous to have an update operation 
potentially return an updated secret and have the secret be lost due to 
communication problems - leaving the client stranded.  Since then, registration 
was changed to use a bearer token to authenticate update operations, and so 
this failure mode can't occur anymore.  It was an omission not to have deleted 
the unneeded operation then.

It's been deleted from OpenID Connect Registration and should likewise be 
deleted from OAuth registration, since it is unneeded.  If a new client secret 
is needed, there's nothing stopping the registration server from returning it 
in the result of an update operation.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Client secret rotation

Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the 
client requesting a new client_secret (if applicable) and a new 
registration_access_token. Client secrets MAY expire after some period of time, 
and this method allows for a refresh of that secret. Draft -00 defined no such 
operation, drafts -01 through -04 defined this operation in terms of the 
operation=rotate_secret parameter, and draft -05 defines it through a secondary 
endpoint, the Client Secret Rotation Endpoint.
This raises several questions:

  - Should the client be allowed to request rotation of its secret?
  - Would a client ever take this action of its own accord?
  - Can a server rotate the secret of the client without the client asking? (This seems 
to be an obvious "yes")

Alternatives that keep this functionality include defining the rotate_secret 
operation in terms of an HTTP verb, a query parameter, or separate endpoint. 
Alternatively, we could drop the rotate_secret operation all together. If we do 
this, we have to decide if the client secret can still expire. If it can, then 
we need a way for the client to get this new secret through a means that 
doesn't require it to request a change in secret, such as sending it back as 
part of the client READ operation (see other thread on RESTful verbs).

  -- Justin


[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

I'd be fine with the return from a creation request being a 201 instead 
of a 200.


 -- Justin

On 02/11/2013 06:33 PM, Richard Harrington wrote:
Since the request is an HTTP POST and a resource is created 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the 
response should be an HTTP 201 Created 
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) 
which is supposed to include the location of the newly created resource.


This is a good pattern to follow since, as you say, it does provide 
flexibility.




On Feb 11, 2013, at 1:14 PM, Justin Richer > wrote:


Draft -05 of OAuth Dynamic Client Registration [1] returns a URL 
pointer for the client to perform update and secret rotation actions. 
This functionality arose from discussions on the list about moving 
towards a more RESTful pattern, and Nat Sakimura proposed this 
approach in the OpenID Connect Working Group. This URL may be 
distinct from the Client Registration Endpoint URL, but draft -05 
makes no promises as to its content, form, or structure, though it 
does contain implementor's notes on possible methods.


Two questions arise from this change:
- The semantics of returning the client manipulation URL
- The syntax (derived from HAL for JSON [2], an individual I-D 
submission)


On semantics:

Pro:
- The server has flexibility on how to define the "update" endpoint, 
sending all clients to one URL, sending different clients to 
different URLs, or sending clients to a URL with a baked-in query 
parameter
- The client can take the URL as-is and use it for all management 
operations (ie, it doesn't have to generate or compose the URL based 
on component parts)


Con:
- The client must remember one more piece of information from the 
server at runtime if it wants to do manipulation and management of 
itself at the server (in addition to client_id, client_secret, 
registration_access_token, and others)


Alternatives include specifying a URL pattern for the server to use 
and all clients to follow, specifying a query parameter for the 
update action, and specifying a separate endpoint entirely and using 
the presence of items such as client_id and the registration access 
token to differentiate the requests. Note that *all* of these 
alternatives can be accommodated using the semantics described above, 
with the same actions on the client's part.



On syntax:

Pro:
- Follows the designs of RFC5988 for link relations
- The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
- Allows for full use of the JSON object to specify advanced 
operations on the returned endpoint if desired


Con:
- The rest of OAuth doesn't follow link relation guidelines (though 
it's been brought up)
- The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
- The HAL-JSON document is an expired individual I-D, and it's 
unclear what wider adoption looks like right now


Alternatives include returning the URL as a separate data member 
(registration_update_url), using HTTP headers, or using JSON Schema.


-- Justin



[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
___
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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt


OK, I can see the wisdom in changing this term.

I picked "valid" because I wanted a simple "boolean" value that would 
require no additional parsing or string-matching on the client's behalf, 
and I'd like to stick with that. OAuth is built with the assumption that 
clients need to be able to recover from invalid tokens at any stage, so 
I think a simple yes/no is the right step here.


That said, I think you're both right that "valid" seems to have caused a 
bit of confusion. I don't want to go with "revoked" because I'd rather 
have the "token is OK" be the positive boolean value.


Would "valid_token" be more clear? Or do we need a different adjective 
all together?


 -- Justin

On 02/11/2013 08:02 PM, Richard Harrington wrote:
Have you considered "status" instead of "valid"?  It could have values 
like "active", "expired", and "revoked".


Is it worthwhile including the status of the client also?  For 
example, a client application could be disabled, temporarily or 
permanently, and thus disabling its access tokens as well.



On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena > wrote:



I guess confusion is with 'valid' parameter is in the response..

I thought this will be helpful to standardize the communication 
between Resource Server and the Authorization Server..


I would suggest we completely remove "valid" from the response - or 
define it much clearly..


May be can add "revoked" with a boolean attribute..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer > wrote:



On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:

Hi Justin,

I have couple of questions related to "valid" parameter...

This endpoint can be invoked by the Resource Server in runtime...


That's correct.




In that case what is exactly meant by the "resource_id" in request ?


The resource_id field is a service-specific string that basically
lets the resource server provide some context to the request to
the auth server. There have been some other suggestions like
client IP address, but I wanted to put this one in because it
seemed to be a common theme. The client is trying to do
*something* with the token, after all, and the rights,
permissions, and metadata associated with the token could change
based on that. Since the Introspection endpoint is all about
getting that metadata back to the PR, this seemed like a good idea.




IMO a token to be valid depends on set of criteria based on it's
type..

For a Bearer token..

1. Token should not be expired
2. Token should not be revoked.
3. The scope the token issued should match with the scope
required for the resource.

For a MAC token...

1. Token not expired (mac id)
2. Token should not be revoked
3. The scope the token issued should match with the scope
required for the resource.
4. HMAC check should be valid

There are similar conditions for SAML bearer too..


This isn't really true. The SAML bearer token is fully
self-contained and doesn't change based on other parameters in
the message, unlike MAC. Same with JWT. When it hands a SAML or
JWT token to the AS, the PR has given *everything* the server
needs to check that token's validity and use.

MAC signatures change with every message, and they're done across
several components of the HTTP message. Therefor, the HMAC check
for MAC style tokens will still need to be done by the protected
resource. Introspection would help in the case that the signature
validated just fine, but the token might have expired. Or you
need to know what scopes apply. Introspection isn't to fully
validate the call to the protected resource -- if that were the
case, the PR would have to send some kind of encapsulated version
of the original request. Otherwise, the AS won't have all of the
information it needs to check the MAC.


I think what you're describing is ultimately *not* what the
introspection endpoint is intended to do. If that's unclear from
the document, can you please suggest text that would help clear
the use case up? I wouldn't want it to be ambiguous.

 -- Justin




Thanks & regards,
-Prabath


On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
mailto:jric...@mitre.org>> wrote:

It validates the token, which would be either the token
itself in the case of Bearer or the token "id" part of
something more complex like MAC. It doesn't directly
validate the usage of the token, that's still up to the PR
to do that.

I nearly added a "token type" field in this draft, but held
back because there are several kinds of "token type" that
people talk about in OAuth. First, there's "Bearer" vs.
"MAC" vs. "HOK", or what have you. Then within Bearer you
have "JWT" or "SAML" or "unstruct

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread Antonio Sanso

Thanks Hannes

On Feb 12, 2013, at 12:06 PM, Hannes Tschofenig wrote:

> The transport of the session key from the authorization server is described 
> in Section 5.1 and is called "mac_key". 
> 
> The mechanism to transport the session key from the authorization server to 
> the resource server is not yet described in the document. This has historical 
> reasons: OAuth 1.0 did not separate the authorization server from the 
> resource server in the way OAuth 2.0 does.

but why do not we hit this same issue in the JWS case? In this situation there 
is as well a key for sign... And AS and RS can be as well two different 
entities...

Regards

Antonio

> 
> Ciao
> Hannes
> 
> On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:
> 
>> Hi Hannes,
>> 
>> how this session key "differs" from the key described in the current draft 
>> [0]?
>> 
>> Thanks and regards
>> 
>> Antonio
>> 
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>> 
>> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
>> 
>>> Hi Bill, 
>>> 
>>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>>> 
 Is key distribution how AS and PR share keys  for token 
 encryption/decryption or specifically about the keys for the HOK tokens?

>>> In order for the client to compute the keyed message digest it needs to 
>>> have the session key. This session key is sent from the authorization 
>>> server to the client and everyone on the call agreed that this has to be 
>>> standardized. 
>>> 
>>> The resource server who receives the message from the client also needs to 
>>> have the session key to verify the message. How the resource server obtains 
>>> this session key was subject for some discussion on the call. I presented 
>>> three different ways of how the resource server is able to obtain that key. 
>>> We have to decide on one mandatory-to-implement mechanism. The open issue 
>>> is which one? 
>>> 
 For the MAC token spec, I don't actually care whether we use JSON or now, 
 but I'm in full agreement that we do NOT duplicate any HTTP info into the 
 JSON.  Just signatures of that stuff.

>>> I believe the folks on the call also agreed with you on that aspect that 
>>> the content of the HTTP message should not be replicated in the JSON 
>>> payload itself. 
>>> 
>>> Ciao
>>> Hannes
>>> 
 From: Hannes Tschofenig 
 To: IETF oauth WG  
 Sent: Tuesday, February 12, 2013 1:10 AM
 Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
 11th February 2013

 Here are my notes. 

 Participants:

 * John Bradley
 * Derek Atkins
 * Phil Hunt
 * Prateek Mishra
 * Hannes Tschofenig
 * Mike Jones
 * Antonio Sanso
 * Justin Richer

 Notes: 

 My slides are available here: 
 http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

 Slide #2 summarizes earlier discussions during the conference calls. 

 -- HTTP vs. JSON

 Phil noted that he does not like to use the MAC Token draft as a starting 
 point because it does not re-use any of the work done in the JOSE working 
 group and in particular all the libraries that are available today. He 
 mentioned that earlier attempts to write the MAC Token code lead to 
 problems for implementers. 

 Justin responded that he does not agree with using JSON as a transport 
 mechanism since this would replicate a SOAP style. 

 Phil noted that he wants to send JSON but the signature shall be computed 
 over the HTTP header field. 

 -- Flexibility for the keyed message digest computation

 From earlier discussion it was clear that the conference call participants 
 wanted more flexibility regarding the keyed message digest computation. 
 For this purpose Hannes presented the DKIM based approach, which allows 
 selective header fields to be included in the digest. This is shown in 
 slide #4. 

 After some discussion the conference call participants thought that this 
 would meet their needs. Further investigations would still be useful to 
 determine the degree of failed HMAC calculations due to HTTP proxies 
 modifying the content. 

 -- Key Distribution

 Hannes presented the open issue regarding the choice of key distribution. 
 Slides #6-#8 present three techniques and Hannes asked for feedback 
 regarding the preferred style. Justin and others didn't see the need to 
 decide on one mechanism - they wanted to keep the choice open. Derek 
 indicated that this will not be an acceptable approach. Since the resource 
 server and the authorization server may, in the OAuth 2.0 framework, be 
 entities produced by different vendors there is an interoperability need. 
 Justin responded that he disagrees and that the resource server needs to 
 understand the access token and referred to the rec

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

2013-02-12 Thread Sergey Beryozkin


Hi Mike,
On 12/02/13 01:26, Mike Jones wrote:

At most, there should be two endpoints - creation and management - for a client, but the protocol 
should be structured such that they *can* be at the same URL, if the server so chooses.  A simple 
way to accomplish this is to require that the client_id value be provided as an input parameter on 
update operations.  Then for implementations that use a single endpoint, they can distinguish 
"create" and "update" operations on the management endpoint by the presence or 
absence of the client_id value.


Perhaps the text can be relaxed somehow to not refer to

/register
and
/register/{client_id}

as two different endpoints ? I think it is a single endpoint from the 
implementation point of view :-).


Or may be the spec can indeed be relaxed a bit and allow for a PUT form 
payload be sent directly to /register


Cheers, Sergey


If you want to have separate endpoints and don't need the client_id because you 
have somehow encoded it into the management endpoint URL, that's fine.  It 
still can serve as a useful cross-check that the client (or an attacker) is 
requesting a change to a client that matches the bearer token used.  But 
including it is necessary for implementations that want to use a single 
registration endpoint, rather than having a proliferation of per-client 
endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access 
token requests and requests for refreshed access tokens - with the operations 
being distinguished by whether a refresh_token parameter is present.  So 
there's a useful OAuth precedent for doing things this way.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can 
undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be 
differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the 
"register" operation, drafts -01 through -04 made use of an "operation" parameter on a 
single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate 
design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint 
and instead opted for separating the base functionality into three different endpoints.

Pro:
   - Closer to RESTful semantics of having one URL for creation and another URL 
for management of an item (eg, most REST APIs use /object for creation and 
/object/object_id for manipulation)
   - The rest of OAuth (and its extensions) defines separate endpoints for 
different actions (Authorization, Token, Revocation, Introspection) as opposed 
to a single endpoint with a mode-switch parameter
   - Client doesn't have to generate a URL string for different endpoints by 
combining parameters with a base URL

Con:
   - Not quite exactly RESTful as the spec doesn't dictate the client_id
be part of the update or rotate URL (though and implementor's note
suggests this)
   - Client has to track different URLs for different actions
   - Server must be able to differentiate actions based on these
different URLs.

Alternatives include using different HTTP verbs (see other thread) or
defining an operational switch parameter, like older drafts, on a single
endpoint URL. Another suggested alternative is to look for the presence
of certain parameters, such as client_id or the registration access
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the others.
It has been suggested off-list that the secret rotation should never be
initiated by the Client but instead the client should simply request its
latest secret from the server through the update (or read) semantics.

   -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
___
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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

The transport of the session key from the authorization server is described in 
Section 5.1 and is called "mac_key". 

The mechanism to transport the session key from the authorization server to the 
resource server is not yet described in the document. This has historical 
reasons: OAuth 1.0 did not separate the authorization server from the resource 
server in the way OAuth 2.0 does.

Ciao
Hannes

On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:

> Hi Hannes,
> 
> how this session key "differs" from the key described in the current draft 
> [0]?
> 
> Thanks and regards
> 
> Antonio
> 
> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
> 
> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
> 
>> Hi Bill, 
>> 
>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>> 
>>> Is key distribution how AS and PR share keys  for token 
>>> encryption/decryption or specifically about the keys for the HOK tokens?
>>> 
>> In order for the client to compute the keyed message digest it needs to have 
>> the session key. This session key is sent from the authorization server to 
>> the client and everyone on the call agreed that this has to be standardized. 
>> 
>> The resource server who receives the message from the client also needs to 
>> have the session key to verify the message. How the resource server obtains 
>> this session key was subject for some discussion on the call. I presented 
>> three different ways of how the resource server is able to obtain that key. 
>> We have to decide on one mandatory-to-implement mechanism. The open issue is 
>> which one? 
>> 
>>> For the MAC token spec, I don't actually care whether we use JSON or now, 
>>> but I'm in full agreement that we do NOT duplicate any HTTP info into the 
>>> JSON.  Just signatures of that stuff.
>>> 
>> I believe the folks on the call also agreed with you on that aspect that the 
>> content of the HTTP message should not be replicated in the JSON payload 
>> itself. 
>> 
>> Ciao
>> Hannes
>> 
>>> From: Hannes Tschofenig 
>>> To: IETF oauth WG  
>>> Sent: Tuesday, February 12, 2013 1:10 AM
>>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>>> 11th February 2013
>>> 
>>> Here are my notes. 
>>> 
>>> Participants:
>>> 
>>> * John Bradley
>>> * Derek Atkins
>>> * Phil Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig
>>> * Mike Jones
>>> * Antonio Sanso
>>> * Justin Richer
>>> 
>>> Notes: 
>>> 
>>> My slides are available here: 
>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>> 
>>> Slide #2 summarizes earlier discussions during the conference calls. 
>>> 
>>> -- HTTP vs. JSON
>>> 
>>> Phil noted that he does not like to use the MAC Token draft as a starting 
>>> point because it does not re-use any of the work done in the JOSE working 
>>> group and in particular all the libraries that are available today. He 
>>> mentioned that earlier attempts to write the MAC Token code lead to 
>>> problems for implementers. 
>>> 
>>> Justin responded that he does not agree with using JSON as a transport 
>>> mechanism since this would replicate a SOAP style. 
>>> 
>>> Phil noted that he wants to send JSON but the signature shall be computed 
>>> over the HTTP header field. 
>>> 
>>> -- Flexibility for the keyed message digest computation
>>> 
>>> From earlier discussion it was clear that the conference call participants 
>>> wanted more flexibility regarding the keyed message digest computation. For 
>>> this purpose Hannes presented the DKIM based approach, which allows 
>>> selective header fields to be included in the digest. This is shown in 
>>> slide #4. 
>>> 
>>> After some discussion the conference call participants thought that this 
>>> would meet their needs. Further investigations would still be useful to 
>>> determine the degree of failed HMAC calculations due to HTTP proxies 
>>> modifying the content. 
>>> 
>>> -- Key Distribution
>>> 
>>> Hannes presented the open issue regarding the choice of key distribution. 
>>> Slides #6-#8 present three techniques and Hannes asked for feedback 
>>> regarding the preferred style. Justin and others didn't see the need to 
>>> decide on one mechanism - they wanted to keep the choice open. Derek 
>>> indicated that this will not be an acceptable approach. Since the resource 
>>> server and the authorization server may, in the OAuth 2.0 framework, be 
>>> entities produced by different vendors there is an interoperability need. 
>>> Justin responded that he disagrees and that the resource server needs to 
>>> understand the access token and referred to the recent draft submission for 
>>> the token introspection endpoint. Derek indicated that the resource server 
>>> has to understand the content of the access token and the token 
>>> introspection endpoint just pushes the problem around: the resource server 
>>> has to send the access token to the authorization server and then the 
>>> resource server gets the result back (which he th
 en
>> a
>>

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread Sergey Beryozkin


Hi Hannes, All,
On 12/02/13 09:10, Hannes Tschofenig wrote:

Here are my notes.

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes:

My slides are available here: 
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls.

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a starting point 
because it does not re-use any of the work done in the JOSE working group and 
in particular all the libraries that are available today. He mentioned that 
earlier attempts to write the MAC Token code lead to problems for implementers.



I'm concerned that the argument about the arguable absence of utilities 
for processing MAC tokens; it is obvious it is simpler to process MAC 
than more involved tokens and to be honest it is really not a point at 
all as the utility of a given token type should be judged on what it can 
bring to the whole system as opposed to whether it can be simpler or not 
to implement it - apologies if I've misread the above note and/or taken 
it out of context


Thanks, Sergey


Justin responded that he does not agree with using JSON as a transport 
mechanism since this would replicate a SOAP style.

Phil noted that he wants to send JSON but the signature shall be computed over 
the HTTP header field.

-- Flexibility for the keyed message digest computation

 From earlier discussion it was clear that the conference call participants 
wanted more flexibility regarding the keyed message digest computation. For 
this purpose Hannes presented the DKIM based approach, which allows selective 
header fields to be included in the digest. This is shown in slide #4.

After some discussion the conference call participants thought that this would 
meet their needs. Further investigations would still be useful to determine the 
degree of failed HMAC calculations due to HTTP proxies modifying the content.

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. 
Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
the preferred style. Justin and others didn't see the need to decide on one 
mechanism - they wanted to keep the choice open. Derek indicated that this will 
not be an acceptable approach. Since the resource server and the authorization 
server may, in the OAuth 2.0 framework, be entities produced by different 
vendors there is an interoperability need. Justin responded that he disagrees 
and that the resource server needs to understand the access token and referred 
to the recent draft submission for the token introspection endpoint. Derek 
indicated that the resource server has to understand the content of the access 
token and the token introspection endpoint just pushes the problem around: the 
resource server has to send the access token to the authorization server and 
then the resource server gets the result back (which he then

 a

  gain needs to understand) in order to make a meaningful authorization 
decision.

Everyone agreed that the client must receive the session key from the 
authorization server and that this approach has to be standardized. It was also 
agreed that this is a common approach among all three key distribution 
mechanisms.

Hannes asked the participants to think about their preference.

The questions regarding key naming and the indication for the intended resource 
server the client wants to talk to have been postponed.

Ciao
Hannes


___
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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread Antonio Sanso

Hi Hannes,

how this session key "differs" from the key described in the current draft [0]?

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:

> Hi Bill, 
> 
> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
> 
>> Is key distribution how AS and PR share keys  for token 
>> encryption/decryption or specifically about the keys for the HOK tokens?
>> 
> In order for the client to compute the keyed message digest it needs to have 
> the session key. This session key is sent from the authorization server to 
> the client and everyone on the call agreed that this has to be standardized. 
> 
> The resource server who receives the message from the client also needs to 
> have the session key to verify the message. How the resource server obtains 
> this session key was subject for some discussion on the call. I presented 
> three different ways of how the resource server is able to obtain that key. 
> We have to decide on one mandatory-to-implement mechanism. The open issue is 
> which one? 
> 
>> For the MAC token spec, I don't actually care whether we use JSON or now, 
>> but I'm in full agreement that we do NOT duplicate any HTTP info into the 
>> JSON.  Just signatures of that stuff.
>> 
> I believe the folks on the call also agreed with you on that aspect that the 
> content of the HTTP message should not be replicated in the JSON payload 
> itself. 
> 
> Ciao
> Hannes
> 
>> From: Hannes Tschofenig 
>> To: IETF oauth WG  
>> Sent: Tuesday, February 12, 2013 1:10 AM
>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>> 11th February 2013
>> 
>> Here are my notes. 
>> 
>> Participants:
>> 
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>> 
>> Notes: 
>> 
>> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>> 
>> Slide #2 summarizes earlier discussions during the conference calls. 
>> 
>> -- HTTP vs. JSON
>> 
>> Phil noted that he does not like to use the MAC Token draft as a starting 
>> point because it does not re-use any of the work done in the JOSE working 
>> group and in particular all the libraries that are available today. He 
>> mentioned that earlier attempts to write the MAC Token code lead to problems 
>> for implementers. 
>> 
>> Justin responded that he does not agree with using JSON as a transport 
>> mechanism since this would replicate a SOAP style. 
>> 
>> Phil noted that he wants to send JSON but the signature shall be computed 
>> over the HTTP header field. 
>> 
>> -- Flexibility for the keyed message digest computation
>> 
>> From earlier discussion it was clear that the conference call participants 
>> wanted more flexibility regarding the keyed message digest computation. For 
>> this purpose Hannes presented the DKIM based approach, which allows 
>> selective header fields to be included in the digest. This is shown in slide 
>> #4. 
>> 
>> After some discussion the conference call participants thought that this 
>> would meet their needs. Further investigations would still be useful to 
>> determine the degree of failed HMAC calculations due to HTTP proxies 
>> modifying the content. 
>> 
>> -- Key Distribution
>> 
>> Hannes presented the open issue regarding the choice of key distribution. 
>> Slides #6-#8 present three techniques and Hannes asked for feedback 
>> regarding the preferred style. Justin and others didn't see the need to 
>> decide on one mechanism - they wanted to keep the choice open. Derek 
>> indicated that this will not be an acceptable approach. Since the resource 
>> server and the authorization server may, in the OAuth 2.0 framework, be 
>> entities produced by different vendors there is an interoperability need. 
>> Justin responded that he disagrees and that the resource server needs to 
>> understand the access token and referred to the recent draft submission for 
>> the token introspection endpoint. Derek indicated that the resource server 
>> has to understand the content of the access token and the token 
>> introspection endpoint just pushes the problem around: the resource server 
>> has to send the access token to the authorization server and then the 
>> resource server gets the result back (which he the
 n
>  a
>> gain needs to understand) in order to make a meaningful authorization 
>> decision. 
>> 
>> Everyone agreed that the client must receive the session key from the 
>> authorization server and that this approach has to be standardized. It was 
>> also agreed that this is a common approach among all three key distribution 
>> mechanisms.
>> 
>> Hannes asked the participants to think about their preference. 
>> 
>> The questions regarding key naming and the indication for the intended 
>> resource server the client wants to talk to have been postponed. 
>> 
>> Ciao
>> Hannes
>

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread William Mills

For key exchange that's true for symmetric key, but no key exchange is required 
for public key signing by the client.

There's so many possibilities here, but I think the best is that the key 
materiel is conveyed in the token.  The key could be included directly, or 
another way to implement would be that a salt is included in the token and then 
the secret is some crypto hash of the token contents and a shared secret 
between the AS and the PR.  

If we we must pick one I'd say include the signing key as part of the encrypted 
token itself.  Completely self contained then.



 From: Hannes Tschofenig 
To: William Mills  
Cc: Hannes Tschofenig ; IETF oauth WG 
 
Sent: Tuesday, February 12, 2013 1:44 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013
 
Hi Bill, 

On Feb 12, 2013, at 11:27 AM, William Mills wrote:

> Is key distribution how AS and PR share keys  for token encryption/decryption 
> or specifically about the keys for the HOK tokens?
> 
In order for the client to compute the keyed message digest it needs to have 
the session key. This session key is sent from the authorization server to the 
client and everyone on the call agreed that this has to be standardized. 

The resource server who receives the message from the client also needs to have 
the session key to verify the message. How the resource server obtains this 
session key was subject for some discussion on the call. I presented three 
different ways of how the resource server is able to obtain that key. We have 
to decide on one mandatory-to-implement mechanism. The open issue is which one? 

> For the MAC token spec, I don't actually care whether we use JSON or now, but 
> I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.  
> Just signatures of that stuff.
> 
I believe the folks on the call also agreed with you on that aspect that the 
content of the HTTP message should not be replicated in the JSON payload 
itself. 

Ciao
Hannes

> From: Hannes Tschofenig 
> To: IETF oauth WG  
> Sent: Tuesday, February 12, 2013 1:10 AM
> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th 
> February 2013
> 
> Here are my notes. 
> 
> Participants:
> 
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
> 
> Notes: 
> 
> My slides are available here: 
> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> 
> Slide #2 summarizes earlier discussions during the conference calls. 
> 
> -- HTTP vs. JSON
> 
> Phil noted that he does not like to use the MAC Token draft as a starting 
> point because it does not re-use any of the work done in the JOSE working 
> group and in particular all the libraries that are available today. He 
> mentioned that earlier attempts to write the MAC Token code lead to problems 
> for implementers. 
> 
> Justin responded that he does not agree with using JSON as a transport 
> mechanism since this would replicate a SOAP style. 
> 
> Phil noted that he wants to send JSON but the signature shall be computed 
> over the HTTP header field. 
> 
> -- Flexibility for the keyed message digest computation
> 
> From earlier discussion it was clear that the conference call participants 
> wanted more flexibility regarding the keyed message digest computation. For 
> this purpose Hannes presented the DKIM based approach, which allows selective 
> header fields to be included in the digest. This is shown in slide #4. 
> 
> After some discussion the conference call participants thought that this 
> would meet their needs. Further investigations would still be useful to 
> determine the degree of failed HMAC calculations due to HTTP proxies 
> modifying the content. 
> 
> -- Key Distribution
> 
> Hannes presented the open issue regarding the choice of key distribution. 
> Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
> the preferred style. Justin and others didn't see the need to decide on one 
> mechanism - they wanted to keep the choice open. Derek indicated that this 
> will not be an acceptable approach. Since the resource server and the 
> authorization server may, in the OAuth 2.0 framework, be entities produced by 
> different vendors there is an interoperability need. Justin responded that he 
> disagrees and that the resource server needs to understand the access token 
> and referred to the recent draft submission for the token introspection 
> endpoint. Derek indicated that the resource server has to understand the 
> content of the access token and the token introspection endpoint just pushes 
> the problem around: the resource server has to send the access token to the 
> authorization server and then the resource server gets the
 result back (which he then a
> gain needs to understand) in order to make a meaningful authorization 
> decision. 
> 
> Everyone agreed tha

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill, 

On Feb 12, 2013, at 11:27 AM, William Mills wrote:

> Is key distribution how AS and PR share keys  for token encryption/decryption 
> or specifically about the keys for the HOK tokens?
> 
In order for the client to compute the keyed message digest it needs to have 
the session key. This session key is sent from the authorization server to the 
client and everyone on the call agreed that this has to be standardized. 

The resource server who receives the message from the client also needs to have 
the session key to verify the message. How the resource server obtains this 
session key was subject for some discussion on the call. I presented three 
different ways of how the resource server is able to obtain that key. We have 
to decide on one mandatory-to-implement mechanism. The open issue is which one? 
 
> For the MAC token spec, I don't actually care whether we use JSON or now, but 
> I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.  
> Just signatures of that stuff.
> 
I believe the folks on the call also agreed with you on that aspect that the 
content of the HTTP message should not be replicated in the JSON payload 
itself. 

Ciao
Hannes

> From: Hannes Tschofenig 
> To: IETF oauth WG  
> Sent: Tuesday, February 12, 2013 1:10 AM
> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th 
> February 2013
> 
> Here are my notes. 
> 
> Participants:
> 
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
> 
> Notes: 
> 
> My slides are available here: 
> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> 
> Slide #2 summarizes earlier discussions during the conference calls. 
> 
> -- HTTP vs. JSON
> 
> Phil noted that he does not like to use the MAC Token draft as a starting 
> point because it does not re-use any of the work done in the JOSE working 
> group and in particular all the libraries that are available today. He 
> mentioned that earlier attempts to write the MAC Token code lead to problems 
> for implementers. 
> 
> Justin responded that he does not agree with using JSON as a transport 
> mechanism since this would replicate a SOAP style. 
> 
> Phil noted that he wants to send JSON but the signature shall be computed 
> over the HTTP header field. 
> 
> -- Flexibility for the keyed message digest computation
> 
> From earlier discussion it was clear that the conference call participants 
> wanted more flexibility regarding the keyed message digest computation. For 
> this purpose Hannes presented the DKIM based approach, which allows selective 
> header fields to be included in the digest. This is shown in slide #4. 
> 
> After some discussion the conference call participants thought that this 
> would meet their needs. Further investigations would still be useful to 
> determine the degree of failed HMAC calculations due to HTTP proxies 
> modifying the content. 
> 
> -- Key Distribution
> 
> Hannes presented the open issue regarding the choice of key distribution. 
> Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
> the preferred style. Justin and others didn't see the need to decide on one 
> mechanism - they wanted to keep the choice open. Derek indicated that this 
> will not be an acceptable approach. Since the resource server and the 
> authorization server may, in the OAuth 2.0 framework, be entities produced by 
> different vendors there is an interoperability need. Justin responded that he 
> disagrees and that the resource server needs to understand the access token 
> and referred to the recent draft submission for the token introspection 
> endpoint. Derek indicated that the resource server has to understand the 
> content of the access token and the token introspection endpoint just pushes 
> the problem around: the resource server has to send the access token to the 
> authorization server and then the resource server gets the result back (which 
> he then
  a
> gain needs to understand) in order to make a meaningful authorization 
> decision. 
> 
> Everyone agreed that the client must receive the session key from the 
> authorization server and that this approach has to be standardized. It was 
> also agreed that this is a common approach among all three key distribution 
> mechanisms.
> 
> Hannes asked the participants to think about their preference. 
> 
> The questions regarding key naming and the indication for the intended 
> resource server the client wants to talk to have been postponed. 
> 
> Ciao
> Hannes
> 
> 
> ___
> 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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

2013-02-12 Thread William Mills

Is key distribution how AS and PR share keys  for token encryption/decryption 
or specifically about the keys for the HOK tokens?

For the MAC token spec, I don't actually care whether we use JSON or now, but 
I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.  
Just signatures of that stuff.



 From: Hannes Tschofenig 
To: IETF oauth WG  
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th 
February 2013
 
Here are my notes. 

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes: 

My slides are available here: 
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls. 

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a starting point 
because it does not re-use any of the work done in the JOSE working group and 
in particular all the libraries that are available today. He mentioned that 
earlier attempts to write the MAC Token code lead to problems for implementers. 

Justin responded that he does not agree with using JSON as a transport 
mechanism since this would replicate a SOAP style. 

Phil noted that he wants to send JSON but the signature shall be computed over 
the HTTP header field. 

-- Flexibility for the keyed message digest computation

From earlier discussion it was clear that the conference call participants 
wanted more flexibility regarding the keyed message digest computation. For 
this purpose Hannes presented the DKIM based approach, which allows selective 
header fields to be included in the digest. This is shown in slide #4. 

After some discussion the conference call participants thought that this would 
meet their needs. Further investigations would still be useful to determine the 
degree of failed HMAC calculations due to HTTP proxies modifying the content. 

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. 
Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
the preferred style. Justin and others didn't see the need to decide on one 
mechanism - they wanted to keep the choice open. Derek indicated that this will 
not be an acceptable approach. Since the resource server and the authorization 
server may, in the OAuth 2.0 framework, be entities produced by different 
vendors there is an interoperability need. Justin responded that he disagrees 
and that the resource server needs to understand the access token and referred 
to the recent draft submission for the token introspection endpoint. Derek 
indicated that the resource server has to understand the content of the access 
token and the token introspection endpoint just pushes the problem around: the 
resource server has to send the access token to the authorization server and 
then the resource server gets the result
 back (which he then a
gain needs to understand) in order to make a meaningful authorization decision. 

Everyone agreed that the client must receive the session key from the 
authorization server and that this approach has to be standardized. It was also 
agreed that this is a common approach among all three key distribution 
mechanisms.

Hannes asked the participants to think about their preference. 

The questions regarding key naming and the indication for the intended resource 
server the client wants to talk to have been postponed. 

Ciao
Hannes


___
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-WG] Draft IETF#86 Agenda

Hi all, 

I just wanted to let you know that the draft agenda for the upcoming IETF 
meeting is available here:
https://datatracker.ietf.org/meeting/86/agenda.txt

There are two OAuth sessions:

* MONDAY, March 11, 2013
1540-1710  Afternoon Session II

* THURSDAY, March 14, 2013
1740-1840  Afternoon Session III

I was also told that there will be an OpenID Connect gathering on Sunday 
afternoon. 

Additionally, there are various other security-related sessions that you may 
find useful, such as JOSE, TLS, or KITTEN. 

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013