[Openid-specs-ab] Tracking IETF Dynamic Registration

Justin Richer jricher at mitre.org
Wed Jan 9 15:04:36 UTC 2013


I'm not opposed to the idea of an explicit read operation on existing 
registrations, provided they're always protected by the 
registration_access_token credential. I don't quite see the utility, 
personally, but it's simple and non-breaking enough that I wouldn't be 
against its inclusion if others see value. From an implementor's 
perspective, the returned value is identical to that which comes back 
from the client_update (in the latest revision of both OAuth DynReg and 
OIDC Reg in the repository).

This is general functionality, though, so it really ought to be 
discussed in the OAuth2 context. I'd suggest bringing it up with the WG 
there.

  -- Justin

On 01/09/2013 03:25 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> 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



More information about the Openid-specs-ab mailing list