[Openid-specs-ab] Dynamic Client Registration

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Sat Feb 2 09:14:02 UTC 2013


The "client_id" parameter was actually dropped in revision 12 of
Registration, quoting from the change log:

"""
removed client_id from request as the client_id is implicit in the
access token for updates 
"""


Vladimir


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



-------- Original Message --------
Subject: Re: [Openid-specs-ab] Dynamic Client Registration
From: Mike Jones <Michael.Jones at microsoft.com>
Date: Sat, February 02, 2013 1:06 am
To: Nat Sakimura <sakimura at gmail.com>, John Bradley <ve7jtb at ve7jtb.com>
Cc: "openid-specs-ab at lists.openid.net Group"
<openid-specs-ab at lists.openid.net>


The other change we could make at the same time then is removing the
"operation" parameter entirely. The "client_register" and
"client_update" operations are easily distinguishable by whether the
request contains a "client_id" parameter or not.

Justin, are you good with these changes?

 -- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat
Sakimura
Sent: Friday, February 01, 2013 5:04 PM
To: John Bradley
Cc: openid-specs-ab at lists.openid.net Group
Subject: Re: [Openid-specs-ab] Dynamic Client Registration

+1

=nat via iPhone

Feb 2, 2013 9:29、John Bradley <ve7jtb at ve7jtb.com> のメッセージ:

> The registration spec originally used the same secret for updating and authentication to the token endpoint.
>
> We added rotate_secret to stop the secret from rotating each time as it did in the original spec because there were legitimate concerns about clients getting locked out if they did not receive a response for some reason and lost the new secret.
>
> Later we separated the authentication to the registration endpoint from the client secret string, however we kept the rotate secret thinking that perhaps a client might want to rotate it's secret.
>
> In OAuth client secret provisioning and rotation if there is such a thing are out of scope.
>
> We did add some additional security that might never get used.
>
> We later also added the assertion profile for authenticating to the token endpoint using asymmetric keys.
>
> I think anyone interested in security should be using this and not worrying about rotating symmetric client secrets.
>
> The Rotate secret verb is I think a bit of cruft that collected and really has no practical use any more.
>
> Low security clients won't use it, and high security clients don't need it.
>
> For asymmetric you would just use your access token to update your signing key to rotate.
>
> I would like to remove rotate_secret as it is not restful for those that care and not especially useful.
>
> If people agree this can be take to the OAuth list. Honestly adding a new endpoint for redundant functionality in a new spec should probably be avoided:)
>
> John B.
>
> _______________________________________________
> 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


More information about the Openid-specs-ab mailing list