[Openid-specs-ab] Dynamic Client Registration

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Sun Feb 3 17:45:44 UTC 2013


Thank you Nat. I went through the text, it looks nicely structured, I
like it. RESTful developers will probably find themselves immediately at
home.

I'm fine with allowing JSON alongside POST parameters. In our Java SDK
all reg parameters are parsed from a java.util.Map representation and a
JSON object maps naturally to that.

If you guys think DELETE is problematic from a management or some other
perspective I can also live without it in the official reg spec.

Thanks again,

Vladimir


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




-------- Original Message --------
Subject: Re: [Openid-specs-ab] Dynamic Client Registration
From: Nat Sakimura <sakimura at gmail.com>
Date: Sun, February 03, 2013 9:54 am
To: Mike Jones <Michael.Jones at microsoft.com>
Cc: John Bradley <ve7jtb at ve7jtb.com>, "Vladimir Dzhuvinov / NimbusDS"
<vladimir at nimbusds.com>, "openid-specs-ab at lists.openid.net Group"
<openid-specs-ab at lists.openid.net>, Justin Richer <jricher at mitre.org>

Before getting this mail, I already added GET and DELETE. GET would not
change the footprint at all, since its functionality is actually
included in the POST (update). 
Normative text in the DELETE is just two lines so it can be easily added
or removed. 
Hard part is what John has pointed out - whether we really want to allow
the client to de-register. 


Here are the changed drafts: 
http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html
http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml


Nat

2013/2/3 Mike Jones <Michael.Jones at microsoft.com>
 At least for Connect, I believe that we want to define only the
operations that are essential to making Connect work.  So for instance,
unregistering clients and retrieving registration state aren't actually
necessary operations, and so I would not add these at the present time. 
We want to keep the implementation footprint as small as possible.
 
                                 -- Mike
 
 -----Original Message-----
 From: openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John
Bradley
 Sent: Saturday, February 02, 2013 9:20 AM
 To: Vladimir Dzhuvinov / NimbusDS
 Cc: openid-specs-ab at lists.openid.net Group
 Subject: Re: [Openid-specs-ab] Dynamic Client Registration
 
 
As you point out the client_id was removed when we went to OAuth
authentication by the client for updates.
 
 I can see in a developer environment you may want to allow the master
token to modify any of the clients created by it thus requiring a
separate client_id parameter.
 That is a reasonable reason to have that parameter.
 
 As far as de registering a client we start down a slippery slope of
full API management.
 
 I would not want to de register a app.  I could perhaps be convinced to
have a app state where you could have "enabled": false.
 
 That way an admin could disable a compromised client_id.
 
 However that raises questions like should an app be able to re enable
itself?   Should that only be modifiable through the developer
credential?
 
 Disabling is a bit of a can of worms so I am cautious, perhaps it
belongs in a client management extension.
 
 I am also receptive to the use of GET to inspect the current client
config state without updating it.
 
 John B.
 
 
 
 
 
 On 2013-02-02, at 7:12 AM, "Vladimir Dzhuvinov / NimbusDS"
<vladimir at nimbusds.com> wrote:
 
 > Thank you John for explaining the story behind the current spec.
 >
 >
 >> I would like to remove rotate_secret as it is not restful for those
 >> that care and not especially useful.
 >
 > If we think in terms of REST and CRUD, is there a scenario where a
 > client may want to unregister? E.g. for an  IdP service that is paid
 > for?
 >
 > I also have a real case with a customer who wishes to add an optional
 > manual registration UI which should speak to the dynamic registration
 > endpoint for all requests:
 >
 > (1) client admin registering app,
 >
 > (2) client admin viewing existing registered app details,
 >
 > (3) client admin updating registered app details,
 >
 > (4) client admin deleting app registration.
 >
 >
 > The current endpoint spec that we have covers (1) and (3); (2) is
 > however only indirectly covered, using the update operation as a work
 > around, and (4) not at all.
 >
 > The missing "client_id" from update operations also makes it hard for
 > trusted third parties, such as the server hosting the manual reg UI,
 > to handle updates, because the access_token is directly tied to the
 > client_id and is used to derive it. If the client_id was specified
 > explicitly we could then issue an access_token the reg UI server for
 > all update operations.
 >
 >
 > Vladimir
 > _______________________________________________
 > Openid-specs-ab mailing list
 > Openid-specs-ab at lists.openid.net
 > http://lists.openid.net/mailman/listinfo/openid-specs-ab
 
 _______________________________________________
 Openid-specs-ab mailing list
 Openid-specs-ab at lists.openid.net
 http://lists.openid.net/mailman/listinfo/openid-specs-ab
 _______________________________________________
 Openid-specs-ab mailing list
 Openid-specs-ab at lists.openid.net
 http://lists.openid.net/mailman/listinfo/openid-specs-ab
 






-- 
Nat Sakimura (=nat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list