[Openid-specs-ab] Tracking IETF Dynamic Registration
Vladimir Dzhuvinov / NimbusDS
vladimir at nimbusds.com
Wed Jan 9 08:25:48 UTC 2013
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 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  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
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