proposed new FAPI certification test: private_key_jwt client authentication assertion where aud contains multiple values

[Joseph Heenan]

As per https://gitlab.com/openid/conformance-suite/-/issues/886 the certification team intends to implement an additional test that sends multiple aud values in client assertions.

We’d likely send the normal aud and also https://other1.example.com and the server must accept that as valid. I guess this would be for FAPI-RW-ID2 tests and also FAPI1-Advanced-Final.

This is at least partly related to https://bitbucket.org/openid/connect/issues/1213/private_key_jwt-client_secret_jwt-audience which some RPs are working around by sending multiple aud values.

Any feedback/objections welcome.

[Joseph Heenan]

Discussed on today’s FAPI WG call. We don’t have a good feeling for how many implementations might not implement this correctly, there was a suggestion it would be added as a warning at least initially.

‌

Also to clarify this is an interoperability concern, and is not a security concern.

‌

[Rui Engana]

We are finding a few entities from Open Banking UK very strict with audience checks and not accepting array values, even when correct value is part of audience array.

Agree this is an interoperability problem and not a security concern, but without interoperability there isn’t adoption. We have also raised this concern with OBIE too.

From RFC7521 https://tools.ietf.org/html/rfc7521#section-5.1 which govern Client Assertions Metamodel it’s said.

Audience
A value that identifies the party or parties intended to process
the assertion. The URL of the token endpoint, as defined in
of OAuth 2.0 [], can be used to indicate that
the authorization server is a valid intended audience of the
assertion. In the absence of an application profile specifying
otherwise, compliant applications MUST compare the Audience values
using the Simple String Comparison method defined in [].

‌

[Joseph Heenan]

https://bitbucket.org/openid/fapi/issues/426/fapi-2-multiple-audience-values-in-client resolved this for FAPI2, where the decision was made to just require a single simple string value for aud that is the issuer url.

The situation in FAPI1 remains unresolved, and an ongoing interoperability issue. At least some clients are sending aud as an array with multiple values, at least some servers are not accepting arrays.

[Filip Skokan]

The situation in FAPI1 remains unresolved, and an ongoing interoperability issue. At least some clients are sending aud as an array with multiple values, at least some servers are not accepting arrays.

The situation seems pretty clear. Clients may be sending aud as an array in order to interoperate. OTOH servers not accepting arrays do not fully handle RFC7523 and RFC7519 (which even goes as far as to say that array is the general case and one audience being a string is a special case, a MAY one at that).

[Filip Skokan]

On today’s call there were no objections to adding a FAPI AS test(s) making sure that ASs accept their respective audience identifier sent in an array.

[Dave Tonge]

@Joseph Heenan can we resolve this?

[Joseph Heenan]

I don’t think so, we don’t have a conclusion yet. As per the above the WG only agreed to add a warning, so we remain in the situation where certified clients may send an array, and certified authorization servers may not accept an array.

(FAPI2 is now clearer. The WG could resolve this for FAPI1 by endorsing the addition of a certification test for FAPI1 that would require AS to accept aud values that are arrays containing multiple values.)

‌

[Filip Skokan]

That’s what https://bitbucket.org/openid/fapi/issues/403/proposed-new-fapi-certification-test#comment-64997366 said to do.

[Joseph Heenan]

Oh, right, sorry, I may have missed that. I hadn’t realised that the conversation encompassed both FAPI1 and FAPI2.

[Joseph Heenan]

I created an issue here to add the FAPI1 test: https://gitlab.com/openid/conformance-suite/-/issues/1207

As such I believe we can close this issue and track it on the conformance suite issue instead.