[Openid-specs-ab] Tracking IETF Dynamic Registration

[Justin Richer]

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