proposal: add/merge OIDC requirements into OAuth2 paragraph (instead of separate OIDC paragraph)

[elarlang]

I prefer to have OAuth2 and OIDC requirement in one main paragraph - those are implemented hand-in-hand and it could be confusing to search them from separate paragraphs from the ASVS

This is just an initial idea, if it does not work out, we can split them to separate paragraphs.

So, any arguments against to put OAuth and OIDC to one paragraph?

(will be implemented, if there is no feedback in one week)

[jmanico]

OAuth2 and OIDC are used for such different purposes, my instinct it to keep them separate.

[elarlang]

Just in case, explanation for the options.

My proposed option.

# V51 OAuth and OIDC

## V51.1 OAuth generic

## V51.2 OAuth Authorization Server

...

## V51.5 OIDC generic

## V51.6 OIDC authorization server

---

Vs alternative:

# V51 OAuth

## V51.1 OAuth generic

## V51.2 OAuth Authorization Server


# V52 OIDC

## V52.1 OIDC generic

## V52.2 OIDC authorization server

[jmanico]

I like your proposed option!

[TobiasAhnoff]

I also like the proposed option from @elarlang, since RFCs , BCPs and security profiles for OAuth/OIDC overlap more and more.
For ASVS I think it is important that, if using just "pure" OAuth grants (no id tokens are returned), it should be easy to only apply OAuth verifications (e g when using client-credentials). And I think the proposed option supports that in a good way, given that OAuth verifications are kept clean from OIDC stuff and that the scope for both OAuth and OIDC is well defined.

Note that if the chapter is built this way then 51.1.1 and 51.1.2 needs to be removed/modified so all OIDC details are separated from OAuth verfications

[elarlang]

My proposed structure leads to another question, how to put introtext info to the document. At the moment @TobiasAhnoff has proposed 2 separate texts, one for OAuth and another for OIDC.

• V51 OAuth: Improve scope definition for new OAuth chapter #2036
• V51 OAuth: Add new OIDC chapter  #2037

My first instinct and idea is to combine them to one intro chapter texts with the clear goal to point out their differences - that those are used together, but the point and the goal for them is different.

[csfreak92]

I like this proposed structure, @elarlang. Normally, I would say v51 for OAuth 2.0 and v52 for OpenID Connect, but since they really go hand-in-hand and to @TobiasAhnoff's point, it covers the case of "pure" OAuth grants in that structure.

For the proposed texts, I can help separating or even combining them. This is the reason I like the v51 and v52 (alternate structure) because there is clear separation of texts from OAuth and OIDC. If I will be the one to decide, I would do the alternate structure as things are separate and clear, but I think we can try an attempt to clarify things with the proposed structure too. It's worth a try.

[randomstuff]

This is the reason I like the v51 and v52 (alternate structure) because there is clear separation of texts from OAuth and OIDC.

I would think that having clearly separating chapters (if well done) would prevent people from mixing the two topics up. I feel that people often do not see the difference between OAuth and OIDC which leads to architectural/implementation issues.

However, the overlap between the two chapters might be difficult to handle.

[TobiasAhnoff]

One reason for having one chapter is that when using OIDC you get the full picture in one chapter and less overlap and duplicated text to maintain, but with the risk of not having a clear separation...

Maybe we just have to pick one and try? It is easy to copy paste between the two anyway since OAuth is separate from OIDC in both alternatives. The only thing that needs to be rewritten is the first sections of scope text.

Hard to decide...if I have to choose I think I go for trying with one OAuth2 and OIDC chapter (as I believe the separation will be good enough)

[elarlang]

@TobiasAhnoff - let's go for it - let's put my proposed structure (#2039 (comment)) and your proposed texts (#2039 (comment)) and get things moving. We going to make changes, fixes and update to it countless time in the future, but we need to get moving.