Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0B521F854C for ; Wed, 9 Jan 2013 12:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuL3iO8Ba5+c for ; Wed, 9 Jan 2013 12:12:04 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1859721F8550 for ; Wed, 9 Jan 2013 12:12:04 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A78E1F2966; Wed, 9 Jan 2013 15:12:03 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 572411F2960; Wed, 9 Jan 2013 15:12:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:12:03 -0500 From: "Richer, Justin P." To: Mike Jones Thread-Topic: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration Thread-Index: AQHN7qWWiv3S82ZaCUiTtACVLR6VgA== Date: Wed, 9 Jan 2013 20:12:02 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>, <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394366A095EE@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366A095EE@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.65] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:12:11 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This not true in my own personal implementation experience, which is where = I came up with the DynReg style. -- Justin On Jan 9, 2013, at 3:07 PM, Mike Jones > wrote: Complete replacement is simpler to implement, and has fewer potential error= cases to handle than partial update. Keep it simple. -- Mike From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Wednesday, January 09, 2013 12:05 PM To: John Bradley; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are: OIDC-style: - inclusion of field replaces that field value on the server with the new = value - omission of field deletes that field value on the server DynReg style: - inclusion of field replaces that field value on the server with the new = value - omission of field tells the server to leave its current value alone - inclusion of field with an empty string value deletes/clears that field = value from the server Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." > wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conver= sation will help improve both drafts. I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it = still behaves as expected. Doesn't it? There's nothing in the draft that RE= QUIRES an incomplete POST, it just ALLOWS it to happen and defines what to = do when it does. Furthermore, it makes it *safer* if the client POSTs somet= hing that is incomplete from the *server's* perspective, since the semantic= s are now, explicitly, to leave alone any values that are left out. In othe= r words, it's my view that this actually makes things far simpler for clien= ts wanting to do simple things, and makes more complex things possible. Thi= s is especially in light of the requirement of the server to echo out the a= ctual full state of the client during the transaction. Having implemented t= his myself, it's really not very complex from either side. The server is ma= rginally more complex, but it leaves fewer cases undefined or "up to the se= rver to decide". Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's= assuming that the *server* has the most complete picture of the client's s= tate, not the *client*, which is the assumption made in OIDC and by Mike an= d John's comments below. Let's take this example as a concrete case (format= ting and parameter names are notional and might be off, I'm typing from mem= ory): Client registers with params: client_name=3DFoo token_endpoint_auth_type=3Dclient_secret_basic Server sends back to the client: { client_name: Foo client_secret: super-secret-secret token_endpoint_auth_type: client_secret_basic scope: read open dennis registration_access_token: TOKEN } So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at= least is changing). Even if it did know about this parameter, it didn't as= k for anything in particular in that field, so it now has to keep around so= mething that it doesn't really know what to do with. So with that in mind, = the client decides to change its name and sends back all the parameters tha= t it knows about: client_name=3DBar token_endpoint_auth_type=3Dclient_secret_basic access_token=3DTOKEN Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the request. = But the server really shouldn't do that, should it? You could argue that be= cause it's a server-defaulted parameter and that the server should know to = treat it special. But then the server would have to track which fields are = still in a "defaulted" state, or keep some kind of programming logic that s= ays "a blank on an update actually means something else". Which fields does= this apply to? Neither of those are "simple". In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now = has an unambiguous message when the client omits the "scope" field. With this behavior, though, we do need the equivalent of "set to null" in o= rder to explicitly empty out the value of an existing field. I took the app= roach of using a blank value -- expressed in HTTP forms as an empty string.= I'm open to other suggestions if there's a better/cleaner approach to this= part of it, but this was the best I could come up with. Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :) -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of John Bradley [ve7jtb@= ve7jtb.com] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft= -ietf-oauth-dyn-reg and OpenID Connect Registration We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown= states if a update fails. I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required. However bandwidth is not a significant factor fo= r this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones > wrote: The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-= dyn-reg-03 does something different than the operation upon which it was ba= sed fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. S= pecifically, while the OpenID Connect operation replaces all field values, = the OAuth operation allows only selective fields to be replaced, designatin= g fields to remain unchanged by specifying their value as the empty string = (=93=94). I'm personally not happy with the change to the semantics of client field i= nclusion. Updating some but not all fields is a substantially more complic= ated operation than replacing all fields. Is there some use case that moti= vates this? I don't think it's a substantial burden on the registering par= ty to remember all the field values from the initial registration and then = selectively use them for update operations, when needed. Then the work goe= s to the (I suspect rare) parties that need partial update - not to every s= erver. It complicates the simple case, rather than pushing the complexity = to the rare case, violating the design principle =93make simple things simp= le and make more complicated things possible=94. Is anyone opposed to updating the OAuth Registration semantics to match the= Connect registration semantics? Is so, why? Thanks, -- Mike _______________________________________________ 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 --_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_ Content-Type: text/html; charset="Windows-1252" Content-ID: <96518D96ED7F3A4E8971D2532C402772@imc.mitre.org> Content-Transfer-Encoding: quoted-printable This not true in my own personal implementation experience, which is where = I came up with the DynReg style.

 -- Justin

On Jan 9, 2013, at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Complete replacement is simpler to implement, and has few= er potential error cases to handle than partial update.  Keep it simpl= e.
 
         &nb= sp;            =             &nb= sp;            =             &nb= sp;    -- Mike
 
From:=  Richer, Justin P. [ma= ilto:jricher@mitre.org] 
Sent: Wednesday, J= anuary 09, 2013 12:05 PM
To: John Bradley; = Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration
 
It's been a few days now and I haven't seen any traffic from the group abou= t this at all, so I'll just come out and ask for opinions. The two proposal= s are:
 
OIDC-style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field deletes that field value on the server=
 
DynReg style:
 - inclusion of field replaces that field value on the server with the= new value
 - omission of field tells the server to leave its current value alone=
 - inclusion of field with an empty string value deletes/clears that f= ield value from the server
 
 
Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its curren= t semantics? Why? Is there another option that's even better?
 
 -- Justin
 
 
On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <

Mike, Jo= hn, thanks for the feedback. I hope and anticipate that this conversation w= ill help improve both drafts.

I disagree with the assessment here that it makes things more complicated i= n the simple case. How? The way that DynReg is currently written, if the cl= ient simply POSTs back the entire set of information that it has about itse= lf every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn'= t it? There's nothing in the draft that REQUIRES an incomplete POST, it jus= t ALLOWS it to happen and defines what to do when it does. Furthermore, it = makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the se= mantics are now, explicitly, to leave alone any values that are left out. I= n other words, it's my view that this actually makes things far simpler for= clients wanting to do simple things, and makes more complex things possible. This is especially in light of the= requirement of the server to echo out the actual full state of the client = during the transaction. Having implemented this myself, it's really not ver= y complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or = "up to the server to decide". 

Part of the motivation I had for changing this here was to cope with the ca= ses where the server asserts things about the client that the client doesn'= t register about itself in the first place, and I wanted something that was= simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the m= ost complete picture of the client's state, not the *client*, which is the = assumption made in OIDC and by Mike and John's comments below. Let's take t= his example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory)= :

Client registers with params:

  client_name=3DFoo
  token_endpoint_auth_type=3Dclient_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (ho= wever it wanted to, probably by a defaulting mechanism) to give the client = three scopes. In the current OIDC spec, the client would never even know th= is happened because this information isn't ever echoed back (though this at least is changing). Even if it did = know about this parameter, it didn't ask for anything in particular in that= field, so it now has to keep around something that it doesn't really know = what to do with. So with that in mind, the client decides to change its name and sends back all the paramet= ers that it knows about:

  client_name=3DBar
  token_endpoint_auth_type=3Dclient_secret_basic
  access_token=3DTOKEN

Now in the OIDC definition of the semantics, this tells the server to clear= out the existing "scope" value, because it's not included in the= request. But the server really shouldn't do that, should it? You could arg= ue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server w= ould have to track which fields are still in a "defaulted" state,= or keep some kind of programming logic that says "a blank on an updat= e actually means something else". Which fields does this apply to? Neither of those are "simple". 

In the current definition of the DynReg spec, the client not only knows the= fields and can do something about them if it wants to, it can also *safely= * ignore them in responses. If the client sends back the same set above, de= aling only in the parameters that it knows and cares about, the server now has an unambiguous message when t= he client omits the "scope" field. 

With this behavior, though, we do need the equivalent of "set to null&= quot; in order to explicitly empty out the value of an existing field. I to= ok the approach of using a blank value -- expressed in HTTP forms as an emp= ty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the bes= t I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that parti= cular red herring. :)

 -- Justin


From:=  o= auth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bradley [ve7jtb@ve7jtb.com]
Sent: Friday, Janu= ary 04, 2013 7:13 PM
To: Mike Jones
Cc: o= auth@ietf.org
Subject: Re: [OAUT= H-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-re= g and OpenID Connect Registration

We did discuss this issue in the connect WG.
 
The decision was made to always completely replace.   That prevents un= known states if a update fails.   
 
I think the always replace everything rule is simpler, though admittedly mo= re bandwidth is required.  However bandwidth is not a significant fact= or for this as far as I know.
 
John B.
 
On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:


The cli= ent_update operation in <= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03" target=3D= "_blank" style=3D"color: purple; text-decoration: underline; ">http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03=  does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-= 1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values= , the OAuth operation allows only selective fields to be replaced, designat= ing fields to remain unchanged by specifying their value as the empty strin= g (=93=94).
 <= o:p>
I'm per= sonally not happy with the change to the semantics of client field inclusio= n.  Updating some but not all fields is a substantially more complicat= ed operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a sub= stantial burden on the registering party to remember all the field values f= rom the initial registration and then selectively use them for update opera= tions, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every se= rver.  It complicates the simple case, rather than pushing the complex= ity to the rare case, violating the design principle =93make simple things = simple and make more complicated things possible=94.
 <= o:p>
Is anyo= ne opposed to updating the OAuth Registration semantics to match the Connec= t registration semantics?  Is so, why?
 <= o:p>
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Tha= nks,
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            -- = Mike
 <= o:p>
___= ____________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=
 
___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth


--_000_B33BFB58CCC8BE4998958016839DE27E06873F7AIMCMBX01MITREOR_--