Perhaps allow audience= and issuer= args to .encode()

This would be nice for API parity with .decode() and would allow applications to ignore the iss and aud abbreviations used by JWT, and it would also give pyjwt control over the the way those fields are formatted, making it less likely that .encode() spits out a non-conforming token.

[mark-adams]

So, the big question here would be… how would you handle conflict? If a consumer passed in a payload to encode() that already had “aud” set but they also passed in a value for audience=

I think the best thing in that situation would be to throw an exception. It seems like any other option would result in a confusing API.

[wbolster]

ok feel free to assign this issue to me. no guarantees about time frame but I’ll see what I can do 😃