Can you point out where it says that, I think I must of missed it. Warren Parad
Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan <ashvinnaraya...@gmail.com> wrote: > Hey Warren, > > 7009 states that you need to pass just the client_id for public clients, > so if: > >> The client_id isn't necessary. >> > > Then obviously something about 7009 needs to change. > > Whichever angle you look at, 7009 needs to change. > > On Thu, Sep 2, 2021 at 5:16 PM Warren Parad <wpa...@rhosys.ch> wrote: > >> Great, then let's fix 6749 not this one. The client_id isn't necessary. >> >> And then wouldn't 7009 not need to be changed because it already says you >> don't need to pass any authorization for public clients? >> >> For credentialled client issued grants, refresh tokens, and access >> tokens, these must not be able to be revoked without client credentials, so >> using the refresh token or access token only for all other client types >> must not be supported. >> >> On Thu, Sep 2, 2021, 08:52 Ash Narayanan <ashvinnaraya...@gmail.com> >> wrote: >> >>> Hi Warren, >>> >>> If you are referring to the client_id as arbitrary information, then the >>> same would also be true for refresh requests to the token endpoint from >>> public clients. As per 6749, you need to pass the client_id along with the >>> refresh token. The client_id adds no additional security. >>> >>> But really, the whole point I've been trying to make from the start is >>> that the token itself should be the only form of 'security' needed...as >>> that's the point of OAuth. >>> >>> Regardless, 7009 needs to be made obsolete by a newer RFC. >>> >>> Ash >>> >>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad <wpa...@rhosys.ch> wrote: >>> >>>> What's the point in passing arbitrary other information that is already >>>> known by the AS and does not provide the level of security necessary to >>>> prevent abuse of the revocation endpoint? >>>> >>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan <ashvinnaraya...@gmail.com> >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> The approach you've suggested sounds good. Passing just the client_id >>>>> along with the token and type (regardless of client type) would be >>>>> consistent with how refresh_token requests are structured. As long as the >>>>> new RFC obsoletes this one. >>>>> >>>>> Ash >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
