Add definitions for client_secret_basic, client_secret_post and none client authentication methods

[ThisIsMissEm]

Whilst the revised text in OAuth 2.1 does clear up a lot of my concerns from the OAuth mailing list, it still doesn't explicitly define the methods by name from what I can see.

It would be good to have these named methods very clearly defined in this revision.

https://mailarchive.ietf.org/arch/msg/oauth/QGJfkCMqN2kVMRMDwvCiF3mZ6r4/

[dickhardt]

PRs are welcome! ᐧ

…

On Tue, Apr 22, 2025 at 3:22 PM Emelia Smith ***@***.***> wrote: Whilst the revised text in OAuth 2.1 does clear up a lot of my concerns from the OAuth mailing list, it still doesn't explicitly define the methods by name from what I can see. It would be good to have these named methods very clearly defined in this revision. https://mailarchive.ietf.org/arch/msg/oauth/QGJfkCMqN2kVMRMDwvCiF3mZ6r4/ — Reply to this email directly, view it on GitHub <#210>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIGVVPUX5XKICDV5KSAUD2226IZAVCNFSM6AAAAAB3U2AHX2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGAYTEMRVG4YDGNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> *ThisIsMissEm* created an issue (oauth-wg/oauth-v2-1#210) <#210> Whilst the revised text in OAuth 2.1 does clear up a lot of my concerns from the OAuth mailing list, it still doesn't explicitly define the methods by name from what I can see. It would be good to have these named methods very clearly defined in this revision. https://mailarchive.ietf.org/arch/msg/oauth/QGJfkCMqN2kVMRMDwvCiF3mZ6r4/ — Reply to this email directly, view it on GitHub <#210>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIGVVPUX5XKICDV5KSAUD2226IZAVCNFSM6AAAAAB3U2AHX2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGAYTEMRVG4YDGNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ThisIsMissEm]

To be honest, the reason I opened the issue is because I'm not sure exactly how we'd want to structure this information in this I-D that I don't work on currently.

[dickhardt]

That's fine. Would you be up for summarizing your email in the issue?

[ThisIsMissEm]

I believe I have already: the client authentication mechanism mentioned by name above aren't formally specified — they are given names in RFC7591 (DCR) but the definitions linked to in RFC6749 are not without a lot of room for interpretation.

E.g., can you use client_secret_basic without a "password" value in the HTTP Basic Authentication header?

Also, the links in RFC7591 are broken & reference internal sections that do not exist

[dickhardt]

Any hints on what is not clear and needs clarity is useful. For example, why would you want to use client_secret_basic without a password value? I would think that you would need to include a password if using client_secret_basic.

[ThisIsMissEm]

I would think that you would need to include a password if using client_secret_basic.

Right, but that behaviour isn't specified, I think I'd agree you'd need to pass the client_secret via the http basic authentication password to use client_secret_basic, just like client_secret_post requires client_secret

[aaronpk]

Please see this PR: #223

Since RFC7591 defines the registry, I don't think it's a good idea to try to move the registry itself. But in the spirit of updating OAuth 2.1 with references to newer specs that RFC6749, it seemed appropriate to at least mention these names and the definition in RFC7591 in the client authentication section.

I don't think there is any ambiguity about whether a password needs to be included, since the whole section begins by talking about how clients with passwords authenticate.