[Openid-specs-ab] Tracking IETF Dynamic Registration

Mike Jones Michael.Jones at microsoft.com
Fri Jan 4 22:46:19 UTC 2013

Sure - I'll raise the issue on the OAuth mailing list.

				-- Mike

-----Original Message-----
From: Justin Richer [mailto:jricher at mitre.org] 
Sent: Friday, January 04, 2013 2:44 PM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Tracking IETF Dynamic Registration

I'm OK with leaving that particular functionality on the table if all the others are taken up, since they are significantly more syntactical in nature. I am not going to change the OAuth registration semantics to match Connect in the near future, but I don't think this is a critical breaking feature and I wouldn't get hung up on it. Clients doing the normal OIDC-style update will still function just fine against a DynReg-style server, after all. Changing the parameter names and values to match and changing the output content of the register/update calls is much more important to implementors.

With that said, my reasoning for the semantic change is actually tied to implementation experience. In our server, as with other OAuth2 servers I've played with, the server actually inserts some missing pieces of client information with default values on registration, either through the registration endpoint or through the client registration services that underlie it.

The only real difference here is the semantics of field deletion. In OIDC, you delete a field by leaving it out. In DynReg, you delete a field by sending a blank. (By blank value, I mean "empty string", since these are all form inputs and aren't parsed for further structure. That is to say, there are no "null" or "empty list" mechanics at play. I think that's clear in the draft, if not in my text below, so I apologize for the confusion.) OIDC has no way for the client to say "leave something alone", so it has to remember all of its metadata (including defaults inserted by the server) for it to function properly. This can leave the server in a bit of a weird state if the client is trying to update something that's been changed at the server, when the client doesn't even care about its value.

But if the OAuth WG wants to change the semantics of this operation, I will be the happy editor and express that in the document. I haven't seen any discussion to that effect yet, so maybe you can raise the issue there and get a thread going, see who else has an opinion on the matter.

  -- Justin

On 01/04/2013 03:22 PM, Mike Jones wrote:
> Thanks for writing this up, Justin.  That really helps clarify what the issues are.
> 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.
> I'm still OK with putting an informative reference into the Connect Implementer's Drafts to the OAuth Registration draft, but because this is a semantic change - not a syntactic one, I'm now against modifying the Connect Registration spec to track the OAuth Registration draft until this is resolved.  It would mean that current Connect Registration servers would have a lot more complicated changes to make than just query-replace on specific identifiers.
> Unless you want to update the OAuth Registration spec in the next few days, Justin, so that the semantics of client field inclusion are unchanged from Connect?  At that point, I would drop my objection.
> By the way, "blank value" isn't well-specified.  Do you mean null, "", 
> [], or something else?  (Of course, the answer to this will become 
> moot if you change the update semantics to complete replacement, like 
> they are in Connect.)
> 				Thanks,
> 				-- Mike
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net 
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Justin 
> Richer
> Sent: Thursday, January 03, 2013 12:54 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Tracking IETF Dynamic Registration
> Since the working group has expressed an intention to ultimately track the IETF OAuth2 Dynamic Registration [1] protocol with the OpenID Connect Dynamic Registration [2] protocol, I would like to propose that we make at least some of the fundamental breaking changes that will come with this prior to the next Implementer's Draft, which is due in roughly a week. While the Final version of the OIDC spec will likely be a normative extension of the IETF document, I propose that we simplify the transition from both the editor's perspective as well as the implementer's perspective by making a few key syntactic changes to the OIDC draft. To wit:
> 1) change the 'type' parameter to 'operation', because 'type' sounds 
> like it's another piece of metadata against the client (ie, "client 
> type")
> 2) change all references from "association" to "register", particularly the 'client_associate' value becomes 'client_register'
> 3) change semantics of client field inclusion. Currently all fields must be included in every client_associate and client_register request, and are strict overwrites. Absence of a field implies deletion of field value at server. Proposed new mechanism:
>      - if field is included and not blank, update value
>      - if field is included and blank, clear value
>      - if field is not included, leave current value as-is
> 4) change client_register and client_update responses to contain all 
> registered client information instead of just the client_id
> 5) change the 'application_name' field to 'client_name', to match 
> OAuth
> 6) I would suggest adopting the 'scope' and 'grant_type' fields with 
> their currently defined semantics in [1] section 2
> 7) Add the 'none' value to the 'token_endpoint_auth_method' parameter, 
> to denote a public client
> As you can see, these aren't overly weighty changes from the spec's 
> perspective, and they're mostly drop-in name replacements from the 
> implementer's perspective. To make it even easier to accept, I'm 
> willing to do the spec edits myself if that's desired. (I think I 
> still have write perms?)
> Ultimately, I believe the Final version of the OIDC spec will simply 
> extend section 2 of the IETF spec and leave the rest as a normative 
> inclusion, with copious examples.
>    -- Justin
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03
> [2] http://openid.net/specs/openid-connect-registration-1_0.html
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list