The JWT being provided is already an access token so in general issuing another access token upon initial presentation of the JWT seems that it would not bring much to the table. However, it always depends on the exact details.
What you described is an authentication system based on bearer access tokens; however, the issuing of tokens is done in a custom way instead of following a framework like OAuth2. The overall security is tied to how the private key is communicated to the user, how the user stores that key and how you validate the token.
It seems that you’re interested in putting the responsibility of owning the private key into each user so although this is not a common approach it may work for you. It’s important that you also ensure that the fact that the user can control all the JWT payload does not put your system at a risk of being abused. For example, you can’t make any access control decisions based on the content (with the possible exception of the user identifier as that is validated by having the public key) of the token because that is fully controlled by the user.
In conclusion, you’re rolling your own bearer token authentication system/protocol instead of reusing something publicly available and publicly reviewed (think OAuth2). This implies that you may forget something fundamental that leaves the entire system at risk so the general recommendation is to stick to available frameworks/protocols.
As a final suggestion I would suggest you to go through the available documentation for API Authorization and to consider the use of OAuth2 end-user based flows to get access tokens meant to call resource servers (aka API’s).