FAPI-CIBA: Does "JWS/JWE Algorithm considerations" apply to Read-Only, too?

[Takahiko Kawasaki]

“7.6 JWS/JWE Algorithm considerations” of the FAPI-CIBA profile says as follows.

CIBA Authorization Servers and Clients shall follow the guidance around JWT signing and encryption Algorithms in [FAPI2] 8.6 and 8.6.1.

‌

In FAPI, JWS algorithm is checked only in the case of Read-and-Write. On the other hand, “5.2.1 Introduction” of the FAPI-CIBA profile says “This profile applies to both Read-Only APIs and Read-and-Write APIs.” This makes room for ambiguity.

When a backchannel authentication request is judged as a request for FAPI Read-Only APIs, should the signature algorithm of the signed authentication request (= the value of the "request" request parameter) be checked?

Likewise, when a backchannel authentication request is for FAPI Read-Only APIs, should the signature algorithm of client assertion (= the value of the "client_assertion" request parameter) be checked?

In my opinion, signature algorithm should be checked only when a backchannel authentication request is judged as a request for FAPI Read-and-Write APIs.

To eliminate the ambiguity, the sentence in “7.6 JWS/JWE Algorithm considerations” should be followed by a constraint like “when a backchannel authentication request is judged as a request for FAPI Read-and-Write APIs.” (I hope native English speakers find a better wording.)

[Joseph Heenan]

I think the intention of the clause was that all FAPI CIBA clients would be required to avoid the use of RS256 / RSA1_5, regardless of whether they’re read-only or read-write.

Whether was the intent of the whole FAPI WG or not I’m not sure. I’m not sure anyone has actually deployed FAPI-R anywhere which to some extent makes read vs read-write an unimportant distinction.

[Dave Tonge]

I agree with Joseph - I think FAPI-CIBA applies to read and read/write clients

[Takahiko Kawasaki]

If so, it must be explicitly written in the FAPI-CIBA profile because the requirement is different from FAPI’s requirement.

[Takahiko Kawasaki]

Does this rule apply only to the backchannel authentication endpoint? Or, does it apply to the entire implementation of an authorization server? For example, client_assertion that may be used at the token endpoint, the introspection endpoint, the revocation endpoint, and the device authorization endpoint, JWT returned from the userinfo endpoint, JWT returned by JARM, Request Objects to the authorization endpoint, etc.?

Applying the rule not only to Read-and-Write but also to Read-Only will have a bigger impact than you may imagine. If the rule should apply to the entire authorization server implementation, "8.5. TLS considerations" should be moved from FAPI Part 2 to FAPI Part 1. I'm not sure that it is proper to write such big requirement calmly in the FAPI-CIBA profile.

[Joseph Heenan]

I think the intention was it applied to all use of CIBA.

I think you raise an interesting point that it means that [if a client is allowed to use both FAPI-CIBA and, say, FAPI-R] it means that the authorization server’s revocation endpoint would have to figure out if the refresh token was issued under FAPI-CIBA or FAPI-R before figuring out if the client authentication method is appropriate.

I think the counter argument would be that a client that is registered for FAPI-CIBA would/should only be permitted to register token_endpoint_auth_signing_alg as PS256 or ES256 anyway, so there's no need for a new check at the revocation endpoint?

[Nat Sakimura]

FAPI-CIBA: Add JWS/JWE algorithm considerations

The intention was always that the same rules as FAPI-RW were followed; this makes it explicit.

closes #244

→ <<cset 3b8a29c714a4>>