Request for suggestions for tests for FAPI2-Baseline RP/client testing

[Joseph Heenan]

The set of certification tests we’ve identified for FAPI2-Baseline RP testing seems very short. Partly this feels okay as part of the ethos of FAPI2 was to simplify things for clients, but I’m worried the certification team might’ve missed something.

The tests we currently have or plan to do are:

1. General happy flow tests (i.e. all requests from client are fully verified, and AS responds with good responses)
2. Variant of happy flow that returns id_token that has the aud claim as a single entry array (this is a test from the FAPI1-Adv tests, and though I can’t recall the history it still seems applicable)
3. Negative test that missed out iss from the authorization endpoint response and expects the client to abort / NOT call the token endpoint
4. Negative test as per '3' but returning an incorrect value for iss
5. Probably something that requires the client to demonstrate it can correctly handle refresh token rotation

‌

Here’s a list of the other things we tested in FAPI1-Adv but don’t seem applicable to FAPI2 and hence we don’t plan to test (mentioned in case anyone can see a reason why these are applicable)

1. Tests for invalid s_hash (not mentioned in FAPI2)
2. Tests for encrypted id_tokens (id tokens are only returned in backchannel in FAPI2 so no reason to encrypt)
3. Tests that return no/extra scopes in the token endpoint response (there’s no relevant clauses in FAPI2)
4. Tests that returned bad nonces/states (there’s no requirement for the client to use state nor to use nonce in FAPI2)
5. Tests that returned bad id_tokens (invalid signatures/expired/missing required fields/etc) and expected the client to stop (there’s no requirement for the client to validate the id_token in FAPI2 as it’s returned in the backchannel)

‌

[Filip Skokan]

Tests that returned bad nonces/states (there’s no requirement for the client to use state nor to use nonce in FAPI2)

I believe a client that uses the openid scope is still required to error if an unexpected nonce value is in the ID Token returned from token endpoint. Unexpected means both wrong value (in case a client sent one) or just unexpected value (in case a client did not indicate one)

Same deal with state. The client is still required to error if an unexpected state is returned.

This is probably two tests, one for state, one for nonce, in which the expectation both times is the client erroring when the suite provides back a different (random) value. The nonce one can be skipped if the client is not sending the openid scope?

Tests that returned bad id_tokens (invalid signatures/expired/missing required fields/etc) and expected the client to stop (there’s no requirement for the client to validate the id_token in FAPI2 as it’s returned in the backchannel)

Despite not being required (by OIDC Core 1.0) to check the signature, a client that uses openid scope is still required to verify that 1) ID Token was returned, and 2) its claims are conform (not missing, correct values, etc.). Not sure how to deal with the skipped signature check.

The openid / ID Token specific checks can easily flow to a SKIPPED state if the client does not request the openid scope.

[Dave Tonge]

Joseph to review current RP tests to see if these are covered