V10 section texts

[elarlang]

Topic 1

Control Objective

Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

Maybe

Therefore, instead of authenticating itself using client secrets (parameters 'client_id' and a 'client_secret'), it only identifies itself as a client (using a 'client_id').

---

Topic 2

Terminology is defined in Appendix A - Glossary and aligns with OAuth RFCs and OIDC specifications. Note that in this chapter, OIDC terminology is only used for OIDC-specific requirements, otherwise, OAuth terminology is used.

Propose to ignore the Appendix A link here.

Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements, otherwise, OAuth terminology is used.

---

Topic 3

• Access tokens, which shall only be consumed by the RS and can either be reference tokens, validated using introspection, or self-contained tokens, validated using some key material.

I think the commas are incorrect (or at least confusing) here

• Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection, or self-contained tokens that validated using some key material.

---

Topic 4

V10.1 Generic OAuth and OIDC security

This section covers generic architectural requirements that apply to all applications using OAuth or OIDC, such as key architectural patterns available when building browser-based JavaScript applications that rely on OAuth or OIDC for accessing protected resources.

A bit hard to read. Maybe it can be split into 2 sentences

[elarlang]

ping @randomstuff @TobiasAhnoff

[randomstuff]

Nitpick, the OAuth client does not always authenticates itself using a client_secret (a shared secret) but may instead authenticate itself using a private key:

Therefore, instead of authenticating itself using client secrets (typically using 'client_id' and a 'client_secret' parameters), it only identifies itself as a client (using a 'client_id').

[randomstuff]

Small change:

Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection, or self-contained tokens that are validated using some key material.

[randomstuff]

Can we just say:

This section covers generic architectural requirements that apply to all applications using OAuth or OIDC.

Does the rest of the sentence bring much value?

or maybe:

This section covers generic architectural requirements that apply to all applications using OAuth or OIDC for browser-based applications.

or

This section covers generic architectural requirements that apply to all applications using OAuth or OIDC for web-based applications.

[elarlang]

Nitpick, the OAuth client does not always authenticates itself using a client_secret (a shared secret) but may instead authenticate itself using a private key:

Therefore, instead of authenticating itself using client secrets (typically using 'client_id' and a 'client_secret' parameters), it only identifies itself as a client (using a 'client_id').

The context here is a bit different, it is definition what is a public client:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

[elarlang]

I numerated the points, Point 1 is still something to discuss and the rest is as quoted below.

Point 1 - see #2896 (comment) - ping @randomstuff

---

Point 2

Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements, otherwise, OAuth terminology is used.

---

Point 3

Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection, or self-contained tokens that are validated using some key material.

---

Point 4

This section covers generic architectural requirements that apply to all applications using OAuth or OIDC.

[randomstuff]

The context here is a bit different, it is definition what is a public client: […]

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

My point was that in,

Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

we assert that the confidential client authenticates itself using a client_secret. This is not always true as the client authenticate itself using another form of credentials. This is reflected by the definition of the public client:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

"credentials" is more general than "client_secret" (as the former includes for example private keys while the latter is only a shared secret).

(That is a very nitpicky detail about the text though.)

[jmanico]

Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

In the Authorization Code Flow, the client application only needs a client_id during the initial, user-driven request, even for confidential clients. I think that distinction is important.

The client_secret is purposefully omitted in this first hop - again - even for confidential clients.

Only the second and third hop of the authorization code flow (the back-channel requests) require a client secret.

Hop 2 - The exchange of the authorization code for tokens—requires a client_id and client_secret.
Hop 3 - When using an access token and refresh token - the core RFC for Oauth2 does not require a client_secret, only per RFC 9700 is this requirement suggested.

I just think this is interesting. :) Please ignore if it hurts the flow of this conversation, no pun intended.

[elarlang]

Point 1

Ok, got the point.

Current text in chapter text:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using a client_id and a client_secret, it only identifies itself using a client_id.

Proposal based on feedback from @randomstuff

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using client secrets (e.g., using 'client_id' and a 'client_secret' parameters), it only identifies itself as a client (using a 'client_id').

Note that I changed "typically" to "e.g.," as I don't have any arguments or reason to state that this is typical and will stay "typical", and it is not well aligned with strong authentication requirements.

[jmanico]

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using client secrets (e.g., using 'client_id' and a 'client_secret' parameters), it only identifies itself as a client (using a 'client_id').

Client_id is not a client secret, it's a public client identifier. The phrase "client secrets (e.g., using 'client_id' and a 'client_secret' parameters)" makes no sense. I would suggest:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using client secrets (e.g., using the 'client_secret' parameter), it only identifies itself as a client (using a 'client_id').

or maybe just:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using 'client_id' and 'client_secret' parameters, it only identifies itself as a client using a 'client_id'.

or perhaps:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself using 'client_id' and 'client_secret' parameters, it only identifies itself using a 'client_id'.

I like the last one better.

[randomstuff]

What about

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (eg. using 'client_id' and 'client_secret' parameters), it only identifies itself using a 'client_id'.

[elarlang]

As we are in the beginning of intro text with this phrase, I put all the parameters "away" to brackets:

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter).

[jmanico]

A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter).

This looks solid. Nice work folks.