It's been a few days now and I haven't seen any traffic from the group about this at all, so I'll just come out and ask for opinions. The two proposals 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 current semantics? Why? Is there another option that's even better? -- Justin On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jric...@mitre.org<mailto:jric...@mitre.org>> wrote: Mike, John, thanks for the feedback. I hope and anticipate that this conversation will help improve both drafts. I disagree with the assessment here that it makes things more complicated in the simple case. How? The way that DynReg is currently written, if the client simply POSTs back the entire set of information that it has about itself 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 just 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 semantics are now, explicitly, to leave alone any values that are left out. In 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 very 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 cases 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 state, not the *client*, which is the assumption made in OIDC and by Mike and John's comments below. Let's take this 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=Foo token_endpoint_auth_type=client_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 (however 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 this 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 parameters that it knows about: client_name=Bar token_endpoint_auth_type=client_secret_basic access_token=TOKEN 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 because 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 says "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, dealing 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 order to explicitly empty out the value of an existing field. I took the approach 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 particular red herring. :) -- Justin ________________________________ From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] on behalf of John Bradley [ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>] Sent: Friday, January 04, 2013 7:13 PM To: Mike Jones Cc: oauth@ietf.org<mailto: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 more bandwidth is required. However bandwidth is not a significant factor for this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> 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 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, designating fields to remain unchanged by specifying their value as the empty string (“”). I'm personally not happy with the change to the semantics of client field inclusion. Updating some but not all fields is a substantially more complicated operation than replacing all fields. Is there some use case that motivates this? I don't think it's a substantial burden on the registering party to remember all the field values from the initial registration and then selectively use them for update operations, when needed. Then the work goes to the (I suspect rare) parties that need partial update - not to every server. It complicates the simple case, rather than pushing the complexity to the rare case, violating the design principle “make simple things simple and make more complicated things possible”. 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
