Have you tried setting ValidateLifetime to false in TokenValidationParameters? That would allow any expiration dates.

Another thing you can do is to set RequireExpirationTime to false, which means exp doesn't need to be present in the token.

So, if you want to configure it to allow tokens not to contain an expiration time, but still validate the expiration time if the exp property is present, you can do this:

.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateLifetime = true,
        RequireExpirationTime = false,
    };
});

Also, if you want, you can set a custom lifetime validator at the same place:

.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        // ... Other settings

        LifetimeValidator = (notBefore, expiration, token, parameters) =>
        {
            // Decide if expiration is valid. Don't forget about clock skew.
        }
    };
});

Although it's unclear if you have control over the token issuer, or the token consumer, or both. All the above solutions assume you have control over the token consumer.

If you have control only over the issuer, it's a bit more difficult. What comes to my mind is setting an exp date that is extremely far into the future. And for invalidating the tokens if it's later required, one thing you could do I suppose is to change the encryption key that the issuer and consumer uses to create/validate the signature.

Removing exp, iat and nbf at the issuer side

As for removing the properties from the token, you can just leave them our from the token generation. Assuming you're doing manual token generation, you'd want to configure it e.g. like this:

var tokenOptions = new JwtSecurityToken(
    issuer: jwtIssuer,
    audience: jwtAudience,
    claims: new List<Claim>() {
        new Claim(JwtRegisteredClaimNames.Sub, userName),
    },
    // 'expires' not set
    signingCredentials: new SigningCredentials(new SymmetricSecurityKey(Convert.FromBase64String(someKey)), SecurityAlgorithms.HmacSha256)
);

Generating it this way it won't contain exp, iat or nbf (confirmed locally).

Of course if you happen to generate it via e.g. Identity Server, it's a different story, but then you forgot to mention that (you mentioned Identity, which is a membership system that doesn't have built-in JWT token generation capabilities).