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

Hi Ash, my understanding of a errata is when there is something technically wrong with the document. Your point is clear: requiring the client id on the revocation endpoint for public clients does not protect the endpoint is valid. You might say that is a point less to require it and might cause p

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

Ah in 5. Security Considerations 👍 Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Thu, Sep 2, 2021 at 10:25 AM Ash Narayanan wrote: > According to this specification, a client's request must contain a >>va

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

> > According to this specification, a client's request must contain a >valid client_id, in the case of a public client, or valid client >credentials, in the case of a confidential client. > > On Thu, Sep 2, 2021 at 6:22 PM Warren Parad wrote: > Can you point out where it says that, I th

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 . On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan wrote: > Hey Warren, > > 7009 states that you need t

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

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 wrote: > Great, t

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

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 a

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

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 rea

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

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 wrote: > Hi Thomas, > > The approach you've suggested sounds good. Pa

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

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 ___

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

I agree with you Justin. While there probably is a need for an errata to this RFC wrt public clients, it wouldn't be the one proposed here. Wrt public clients, section 5 states: According to this specification, a client's request must contain a valid client_id, in the case of a public clie

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

Hi Torsten, Thanks for clarifying. The errata system allows for two types of errata, editorial and technical. I selected technical when I submitted this particular one. Things like typos and ambiguities sound like editorial to me, unless I'm mistaken. I'd be fine with submitting a new RFC so as t

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

Hi Ash, > Am 31.08.2021 um 02:42 schrieb Ash Narayanan : > > Hi Dick, > > >The access token represents the authorization to access the resource(s) -- > >it does not represent the authorization to manipulate tokens. > > Anything for which the client must have an access token to access is a > p

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

Hi Dick, >The access token represents the authorization to access the resource(s) -- >it does not represent the authorization to manipulate tokens. Anything for which the client must have an access token to access is a protected resource. In order to revoke a token, the client must have the assoc

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

Hey Emond The access token represents the authorization to access the resource(s) -- it does not represent the authorization to manipulate tokens. The client credentials are used for token management. While your implementation may be ok with using the access token to revoke itself, it is not the s

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

On Tue, Aug 24, 2021 at 12:14 PM Warren Parad wrote: > I think it is worth pointing out, if we were to agree with the errata, > that this particular use case probably isn't relevant: > > Our client in this case was a command line tool, which only requests the >> client credentials on login. It th

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

I think it is worth pointing out, if we were to agree with the errata, that this particular use case probably isn't relevant: Our client in this case was a command line tool, which only requests the > client credentials on login. It then fetches an access token and stores > this locally. The clien

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

On Mon, Aug 23, 2021 at 9:42 PM Justin Richer wrote: > I personally don’t agree with this errata. Token Revocation was never > meant to act as a protected resource, but rather as a function of the AS. > The client is known to the AS and so authentication is expected here. > We ran into this very

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

I personally don’t agree with this errata. Token Revocation was never meant to act as a protected resource, but rather as a function of the AS. The client is known to the AS and so authentication is expected here. — Justin > On Aug 22, 2021, at 5:14 AM, RFC Errata System > wrote: > > The fo