Pushed Request Object - Signed request object shouldn't be used for client authentication

[Takahiko Kawasaki]

The 2nd clause in “5.1. Request Object Request” in “Financial-grade API: Pushed Request Object” says as follows.

If the request object is signed, the signature serves as means for client authentication

However, the signed request object shouldn't be used for client authentication. Conceptually, this is trying to mix request_object_signing_alg and token_endpoint_auth_signing_alg (which is for RFC 7523 client assertion). It is likely that we will encounter undesirable side effects in future.

[Ralph Bragg]

I’m not sure i agree with this but i can understand the point that’s being conceptually made. Technically the client HAS been authenticated, i.e we know where the request_object came from and the fact that it came from a valid client BEFORE the client then tries to obtain an access token which requires a seperate act of client authentication. The signature is authenticating the sender orginator of the message (RP) in both cases but for different purposes. It is not “client authentication” for the purposes of obtaining an access token and i personally don’t think that this is confusing.

I don’t think it’s required to explicitly put a comment on the token endpoint authentication section to say “that a signed authorization request object “ shouldn’t be used to obtain a token from the token endpoint. Private_key_jwt mechnaism is explicit enough in the claims that are required.

[Takahiko Kawasaki]

Maybe, I should have excerpted the full text of the clause. It says as follows.

If the request object is signed, the signature serves as means for client authentication and as evidence of the client submitting the request object, which is referred to as 'non-repudiation'. If the request object is not signed, the client is expected to authenticate itself using its registered token endpoint authentication method.

That is, if the format of the input data to the request object endpoint is plain JSON, client authentication is performed according to the pre-configured value of token_endpoint_auth_method client metadata, which might be (not assertion-based but) certificate-based client authentication (e.g. tls_client_auth). On the other hand, if the format of the input data is signed JWT and if the current clause is honored, client authentication is performed in a way like assertion-based client authentication. This means that client authentication method varies depending on the difference of the format of the input data. This would make the behavior of the request object endpoint inconsistent among other endpoints such as the token endpoint, the revocation endpoint, the introspection endpoint, and the backchannel authentication endpoint.

FAPI requires that key size be 2048 bits or more when an RSA algorithm is used for client authentication (FAPI Part 1, 5.2.2, 5) and that key size be 160 bits or more when an elliptic curve algorithm is used for client authentication FAPI Part 1, 5.2.2, 6). If the 2nd clause of “5.1. Request Object Request” requires the request object serve as means for client authentication, the same requirement for key size should apply to the request object, too. I don’t think people want to impose such requirements on the input request object.

cf. OAuth 2.0 Client Authentication

[Brian Campbell]

I agree with Taka here and note that issue #226 is effectively seeking the same outcome.

[Ralph Bragg]

Thanks Taka, given the full text, was the intention behind the clause that the client has authenticated itself for implicit type requests? Where the token is returned by the user agent? If so, and given that fapi is removing support for code id_token token then this clause needs revision.

[Takahiko Kawasaki]

I don't know the intention behind the clause because I don't know even when the WG started to develop this new specification. The reality was that I just started to read the specification to implement it.

Anyway, if I understand your question correctly, it is not the user agent that calls the request object endpoint, so no token is returned to the user agent from the request object endpoint. Instead, it is the client application that calls the request object endpoint. So, we don't have to discuss code id_token here.

[Torsten Lodderstedt]

I created a PR https://bitbucket.org/openid/fapi/pull-requests/137/changed-the-draft-to-use-the-application-x/diff

I’m quite satisfied with this change as it makes the spec considerably simpler. The request processing turned out to be a combination of JAR and the token endpoint behavior.

[Torsten Lodderstedt]

PR has been merged, closing ticket