FAPI2 Baseline + jarm & iss draft

I think when using JARM with FAPI2 baseline, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp the iss draft is essentially a ‘no op’ - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp#section-2.4 says:

‌

   Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
   (JARM)" [JARM] defines a mechanism that conveys all authorization
   response parameters in a JWT.  This JWT contains an "iss" claim that
   provides the same protection if it is validated as described in
   Section 2.4.  Therefore, an additional "iss" parameter outside the
   JWT is not necessary when JARM is used.

(although ‘not necessary’ is subtly different to ‘MUST NOT’)

Although according to JARM all auth response parameters must be inside the JWT, so it would arguably be an error to have iss outside the JWT.

However https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp#section-2.4 also says this, which really says that when the iss draft is used clients MUST check for the value outside the JWT:

   Clients that support this specification MUST extract the value of the
   "iss" parameter from authorization responses they receive if the
   parameter is present.  Clients MUST then decode the value from its
   "application/x-www-form-urlencoded" form according to [RFC6749],
   Appendix B, and compare the result to the issuer identifier of the
   authorization server where the authorization request was sent to.

‌

I think just to make things clear it would be worth adding “if JARM is not used” to both of these clauses in FAPI2 baseline:

shall return an iss parameter in the authorization response according to [@!I-D.ietf-oauth-iss-auth-resp]

shall check the iss parameter in the authorization response according to [@!I-D.ietf-oauth-iss-auth-resp] to prevent Mix-Up attacks

‌

Comments (8)