[Openid-specs-fapi] Issue #581: private_key_jwt audience requirements (openid/fapi)

[panva]

New issue 581: private_key_jwt audience requirements
https://bitbucket.org/openid/fapi/issues/581/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` and to be sent as string **or be part of the array of audience values**
* servers shall accept its Issuer Identifier value as the `aud` claim when a string as well as when an array

It’s okay to restrict the fapi 2.0 ecosystem to use the issuer identifier as its primary identifier, but not at the cost of clients not being able to work with other ecosystems. By requiring clients to send `aud` as a string we’re making them less interoperable. An existing client that sends an array with issuer identifier and token endpoint that does so in order to be interoperable with most AS implementations \(FAPI 1, OIDC, and others\) cannot participate in FAPI 2.0 which is absurd.