private_key_jwt audience requirements

[Filip Skokan]

Currently

• clients shall use the Issuer Identifier value as aud and to be sent as string not as array
• servers shall accept its Issuer Identifier value (format unrestricted)

I believe this should be

• clients shall use the Issuer Identifier value as aud (format as per RFC/OIDC string/string[])
• servers shall accept its Issuer Identifier value as the aud claim or as one of the members of the aud claim when it is an array.

It’s okay to guide the fapi 2.0 ecosystem to use the issuer identifier as its primary assertion identifier, but not at the cost of clients not being able to work with other ecosystems by forcing a single string value which isn’t generally accepted everywhere.

By requiring clients to send aud as a string we’re making them less interoperable with existing deployments of non FAPI2 profiles. An existing client that sends an array with issuer identifier and token endpoint and does so in order to be interoperable with most AS implementations (FAPI 1, OIDC, and others) cannot participate in FAPI 2.0 which is sort of absurd.

Since there is no discovery method in place that clients could use to determine which audience value they should be using we need to have this reverted.

‌

[Joseph Heenan]

The removal of the array option was deliberate as per https://bitbucket.org/openid/fapi/issues/426/fapi-2-multiple-audience-values-in-client

Currently the FAPI WG has never made a decision to require servers to accept aud values that are an array, as per https://bitbucket.org/openid/fapi/issues/403/proposed-new-fapi-certification-test (though the suggested warning there has not yet been implemented in the certification tests).

‌

[Filip Skokan]

Furthermore this issues has now (with the release of conformance suite v5.1.1) spilled over to FAPI 1 conformance tests where clients using PAR are issued a warning if they send an array that includes an issuer.

[Brian Campbell]

I did express “concern that [restricting the audience to being a single value] would cause more issues than it solves” in https://bitbucket.org/openid/fapi/issues/426/fapi-2-multiple-audience-values-in-client

[Filip Skokan]

On today’s call there were no objections to

updating the client requirements to

if using private_key_jwt, shall use the Authorization Server's issuer identifier value (as defined in [RFC8414]) in the aud claim sent in client authentication assertions, and the issuer identifier value should be sent as a string;

The change is making the string format a should, not a shall which we know clients that out of the box already interoperate cannot obide without manual intervention/configuration.

updating the server requirements to

shall accept its issuer identifier value (as defined in [RFC8414]) either as the aud claim (when a string) or as a member of the aud claim (when an array) received in client authentication assertions;

The change is explicitly saying that servers must accept array values including the expected identifier as well as string values being the expected identifier.

updating the fapi 2 certification tests to

• include an AS test similar to #403 to make sure array values are accepted
• update the client test so that it only issues a warning if the client sends a value which isn’t the issuer identifier string or isn’t an array including it. token endpoint uri presence or the current endpoint uri presence in the array should not trigger a warning but other unrecognized values possibly might.

‌

[Joseph Heenan]

Thanks Filip.

So just to confirm, based on “and the issuer identifier value should be sent as a string;” the RP tests should raise a warning for any case where the aud is an array?

‌

[Joseph Heenan]

update the client test so that it only issues a warning if the client sends a value which isn’t the issuer identifier string or isn’t an array including it. token endpoint uri presence or the current endpoint uri presence in the array should not trigger a warning but other unrecognized values possibly might.

I believe “warning” here should be “error” as this relates to the “shall”, right?

[Filip Skokan]

Everything in my summary was deliberate and after re-reading, correct as per our discussion on the call.

[Joseph Heenan]

Thanks Filip. I wasn’t able to make the call unfortunately.

I can’t follow the logic whereby:

if using private_key_jwt, shall use the Authorization Server's issuer identifier value (as defined in [RFC8414]) in the aud claim sent in client authentication assertions,

despite being a ‘shall’ in the new proposed text is treated as a ‘should’ (warning) in the tests:

update the client test so that it only issues a warning if the client sends a value which isn’t the issuer identifier string or isn’t an array including it

‌

‌

[Filip Skokan]

RP tests error if a string value is not the issuer identifier.

RP tests error if an array doesn't contain the issuer identifier.

RP tests do not warn on array unless the array contains a value which isn’t there for interoperability purposes, token endpoint url is ok, current endpoint url is ok, issuer identifier is a must as per the prev. point

‌

OP test errors if array including issuer identifier or the same as a single string value isn’t accepted.

[Joseph Heenan]

PR: https://bitbucket.org/openid/fapi/pull-requests/415

[Filip Skokan]

https://bitbucket.org/openid/fapi/pull-requests/415 was merged