Change the JWT 'iss' claim to the introspection endpoint URL of the issueing IM/Zen

Customers' landscape still is sort of silo-ed, meaning there's a large department managing BAW , and there's another big department managing FileNet. Current production for both
runs on WebSphere traditional (tWAS), ( deployed on CloudPak Systems aka. PureApplication Systems ).  BAW applications work with FileNet documents, where technically users that are logged on to BAW applications , also use their identity on FileNet to work with the FileNet documents. This is known as 'application SSO using identity propagation'.For CP4BA, the usual WebSphere 'LTPA' tokens do not exist anymore; now JWT's  (JSON WebToken) are used to transfer an identity.

We recently finalized a combined effort with IBM Enterprise Content Management and CP4BA Security to enable the use of JWT's to authenticate to Filenet on tWAS,
which is really important for the customer to be able to gradually migrate to CP4BA BAW while still being able to use the Filenet backends.Unfortunately a limitation of the JWT surfaced..  
 

Elements in the JWT are called 'claims', and once specific claim is called 'iss'  ( the JWT issuer ).
In the current Zen design, the value for the 'iss' claim is set to 'KNOXSSO'. While the JWT specs allow for that, another common value would be the URL of the JWKS
endpoint where the JWT signature can be verified, aka. one of Zens' endpoints. The 'introspection_endpoint' to be more specific.
With the current 'KNOXSSO' label as the issuer, there is no way to distinguish between JWTs from different Zen instances ( or CP4BA instances ), meaning the
FileNet server can only have _one_  CP4BA client !
 Relying only on iss is a limitation. To support multiple CP4BA clients, you’ll need either distinct claims (audience, client_id) or multiple TAI configs. If Zen can issue JWTs with richer claims, that’s the cleanest fix.

Question is : can we change the JWT issuer field to the 'introspection_endpoint' of the IM/Zen instance ?