FAPI2SP appears to permit response_types "id_token", "id_token token" and "none"

[Joseph Heenan]

FAPI2SP appears to permit response_types "id_token", "id_token token" and "none" - the only text I could find that’s relevant is these two statements, neither of which would prevent this:

‌

shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749] or the hybrid flow as described in [OIDC]¶

shall support the authorization code grant (response_type=code & grant_type=authorization_code) described in [RFC6749]¶

‌

‌

‌

[technically, “id_token token” is probably not permitted because I don’t think there’s any way to issue a sender constrained access token from the authorization endpoint.]

[Joseph Heenan]

Discussed on today’s call - consensus to just expand the wording so it covers the implicit from OIDC as well, and explicitly denies none.

[Brian Campbell]

It was my suggestion so I should probably offer some text. Here’s a stab at rewording that first sentence:

“shall reject requests using the resource owner password credentials grant, the implicit grant described in [RFC6749], the implicit or hybrid flows as described in [OIDC], or the none response type.”

‌

a ref for none may or may not be needed https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#none

‌

‌

‌

[Dave Tonge]

discussed on the call and suggestion to further clarify:

• don’t issue access token from authorization endpoint
• don’t issue id token from authorization endpoint

‌

[Dave Tonge]

suggestion for auth code flow section:

1. shall support the authorization code grant (`response_type=code` &
    `grant_type=authorization_code`) described in [@!RFC6749];

to change to make clear only that response type

[Filip Skokan]

Close to the end of the call the following suggestion was made (this is a rough summary)

Under General Requirements the

shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749] or the hybrid flow as described in [OIDC]

may just end up being

shall reject requests using the resource owner password credentials grant

or it may end up being a combination of that, what brian suggested above and what Aaron mentioned on the call (about not issuing access and id tokens via frontchannel?

A section to add before Authorization Code Flow called Authorization Endpoint

For the Authorization Endpoint, Authorization servers

1. shall require the use of the code response type described in [RFC6749]

The Authorization Code Flow section may stay as-is.

[Nat Sakimura]

Just checked.

1. shall require the use of the code response type described in [RFC6749]

As pointed out, “the use of” may be a bit vague. Perhaps

1. shall require the value of response_type described in [@!RFC6749]to be code;

might be better.

‌

[Nat Sakimura]

Dave to create a PR.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/442

[Dave Tonge]

PR merged