Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

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 <ashvinnarayanan@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 <wparad@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 <ashvinnarayanan@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 <wparad@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 <ashvinnarayanan@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
>>>>>
>>>>