Make it clear that the entire flow is OIDC Hybrid Flow (related to #155)

[Nat Sakimura]

I was pointed out that this was not clear as stated below:

The flow is explicitly stated to be a "profile of The OAuth 2.0 Authorization Framework" (section 5.2.1 of profile 2), which does not have a hybrid flow. The behavior of the AS in the rw-flow is inherited from the AS of the r-flow, which is an OAuth 2.0 profile. As we see it, in the case of a r-flow, the AS only returns an id token if the scope contains openid. Therefore, we assumed that this also holds true for the rw-flow.

[Brian Campbell]

Might also be worth mentioning that the main reason for using the OIDC Hybrid Flow is to get the security benefit of the detached signature of the ID Token.

[Nat Sakimura]

Related to #155

[Andrew McMiddlin]

What does this mean for section 5.2.5 of profile 2? Currently it explicitly says that code may be used as the response type when responses are protected by a JWT, which is not the hybrid flow, but does address the primary reason for using the hybrid flow.

[Joseph Heenan]

This ticket predates JARM. My understanding is that JARM will continue to be allowed with the code flow. This ticket is mostly about just tidying up some language so that the use of openidconnect is more explicit - ie. any fix for this ticket won't be a normative change.

[Nat Sakimura]

The text is clarified in the introduction.