[Openid-specs-ab] Tracking IETF Dynamic Registration

[Vladimir Dzhuvinov / NimbusDS]

I welcome the idea to give client registration an OAuth spec of its own.
I think there's good potential for the client reg protocol to find use
in other applications beyond OIDC. 

The optimal semantics of registration will surely get clarified as we
put the endpoint to practical test. Last month I implemented the OIDC
style reg into our OIDC SDK and in two - three months I'll be able to
provide practical feedback on that.

I noticed there is no direct way for a client to query its registration
params. But it looks like the update operation provides a work around?

What is your opinion on providing a "read" operation guys? Right now I
imagine use for that in our OIDC server project, to allow the reg
endpoint to be implemented as a separate web service, and let the AS
query client reg data via a simple "read" query. A "read" operation can
also be useful if we have a web page for manual registrations that
fronts the auto-reg endpoint.


Vladimir



--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
 







-------- Original Message --------
Subject: [Openid-specs-ab] Tracking IETF Dynamic Registration
From: Justin Richer <jricher at mitre.org>
Date: Thu, January 03, 2013 8:54 pm
To: "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>


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