2.3.1 Note in Response Mode "query.jwt"

[Nat Sakimura]

Comments

JARM appears to only define behaviour for response type code and token and not for the hybrid mode with id_token. Indeed, it does not make sense to use both “code id_token” as the response type and use JARM as the response mode so it does make sense. However, the treatment of ID Token comes up in 2.3.1 saying it needs to be encrypted.

Note: "query.jwt" MUST NOT be used in conjunction with response types that contain "token" or "id_token" unless the response JWT is encrypted to prevent token leakage in the URL.

Proposal

Amend the note to read as:

Note: "query.jwt" MUST NOT be used in conjunction with response types that contain "token" unless the response JWT is encrypted to prevent token leakage in the URL.

‌

[Filip Skokan]

Like with response types containing id_token, we do not allow the use of query response mode. That’s being re-iterated in this document with a caveat that it is okay IF the JWT is encrypted.

The current text is okay because JARM does not define behaviour only for response type code and token, it’s a general purpose response mode.

[Brian Campbell]

‌

Reiterating from the mailing list https://lists.openid.net/pipermail/openid-specs-fapi/2022-July/002637.html

JARM defines behavior for any response type as the last part of the introduction says, "The JWT authorization response mode can be used in conjunction with any response type" while the middle section of The JWT Response Document reiterates that it "is applicable to all response types including those defined in [OIDM]."  That paragraph goes on to say "The following subsections illustrate the pattern with the response types `code` and `token`", which is not limiting to those but just illustrative of a couple response types. 

This is how Torsten structured the document originally, so it's always been like that, and I believe that the actual text makes it pretty clear that it applies to any response type. But I have heard this misconception from at least one other reader of the draft. So maybe something more or different is needed to prevent the misunderstanding?

‌

And https://lists.openid.net/pipermail/openid-specs-fapi/2022-July/002637.html

The text is, 'Note: "query.jwt" MUST NOT be used in conjunction with response types that contain "token" or "id_token" unless the response JWT is encrypted to prevent token leakage in the URL.'  which is saying you can't use query string encoding for response types that contain "token" or "id_token" *unless* the whole JARM response is encrypted. Core and FAPI outright prohibit response types that contain "token" or "id_token" being used with query string encoding. So this is not more restrictive. It's an allowance for query string encoding when JARM encryption is used.

‌

[Nat Sakimura]

@Filip Skokan True but at the same time, it does not make much sense to use both ID Token in the front channel and JARM at the same time, at least to me.

[Filip Skokan]

When considering the front-channel ID Token as means for a client to get end-user claims early, before exchanging an authorization code through an external HTTP request, then an encrypted JARM response delivered via query, in other words what the current language in 2.3.1 says, makes sense to me.

To re-iterate, are you asking to make JARM applicable only for select response types?

[Filip Skokan]

‌

Looking at the ToC, section 4.1 - we are missing the response type id_token and potentially response type none. I can now see where Nat is coming from saying “JARM appears to only define behaviour for response type code and token”.

But then 4.1 clearly states

The JWT furthermore contains the authorization endpoint response parameters as defined for the particular response types, even in case of an error response.

This pattern is applicable to all response types including those defined in [OIDM].

The following subsections illustrate the pattern with the response types "code" and "token".

“Illustrate the pattern”

So i’m thinking 4.1.1. and 4.1.2. need to be moved to examples and more substance be added to 4.1 to send the point across that JARM defines behaviour for any response type.

[Nat Sakimura]

Add “Example: “ at the beginning of the title?

[Nat Sakimura]

Decision: Add "Example: " to 2.1.1. Drop 2.1.2.

[Brian Campbell]

7/6 call agreed to add example to the subsections. maybe remove token subsection

[Brian Campbell]

PR #354