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
