[Openid-specs-ab] Tracking IETF Dynamic Registration
Michael.Jones at microsoft.com
Fri Jan 4 20:22:31 UTC 2013
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.)
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  protocol with the OpenID Connect Dynamic Registration  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  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
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.
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab