[Openid-specs-ab] Dynamic Client Registration

Nat Sakimura sakimura at gmail.com
Sat Feb 2 12:46:53 UTC 2013


Yes. By dropping "operation", "operation=rotate_secret" is also dropped.

Nat

2013/2/2 Mike Jones <Michael.Jones at microsoft.com>

> Are you also in favor of removing the rotate_secret operation, Nat?
>
> -----Original Message-----
> From: Nat Sakimura [mailto:sakimura at gmail.com]
> Sent: Friday, February 01, 2013 5:28 PM
> To: Mike Jones
> Cc: John Bradley; openid-specs-ab at lists.openid.net Group
> Subject: Re: [Openid-specs-ab] Dynamic Client Registration
>
> Oops. I thought John was proposing to remove the operation parameter.
> I did +1 for that, as I indicated on the OAuth list.
>
> =nat via iPhone
>
> Feb 2, 2013 10:07、Mike Jones <Michael.Jones at microsoft.com> のメッセージ:
>
> > 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
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130202/daed2f05/attachment.html>


More information about the Openid-specs-ab mailing list