private_key_jwt audience requirements
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 theaud
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.
Comments (14)
-
-
reporter 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.
-
reporter - edited description
-
reporter - edited description
-
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
-
reporter 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 theaud
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 theaud
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
#403to 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.
- include an AS test similar to
-
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?
-
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?
-
reporter Everything in my summary was deliberate and after re-reading, correct as per our discussion on the call.
-
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 theaud
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
-
reporter 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.
-
-
assigned issue to
-
assigned issue to
-
-
reporter - changed status to resolved
- Log in to comment
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).