Allow `nbf` and `nnc` to be `null`

[bgins]

Summary

Problem

ts-ucan does not allow nbf and nnc to be null.

Impact

ts-ucan reports an invalid payload when either of these fields are null.

Solution

Allow the fields to be null when validating payloads.

The fields are checked here:

ts-ucan/src/types.ts

Lines 122 to 123 in 978dfd2

	&& (!util.hasProp(obj, "nbf") || typeof obj.nbf === "number")
	&& (!util.hasProp(obj, "nnc") || typeof obj.nnc === "string")

[cdata]

On the rs-ucan side, it would be trivial for us to omit these fields when they are not used. It would probably be better to omit them as it improves payload size (however marginally).

Do you have an opinion about what to do with fct? The spec says this field is optional, but current we emit an empty array no matter what.

[cdata]

As an optimization/mitigation, I changed rs-ucan's serialization to omit these fields when unused: ucan-wg/rs-ucan@7203f32

Published as https://crates.io/crates/ucan/0.5.0-alpha.6

Tokens generated by rs-ucan are now accepted and interpreted correctly by the validator 👍

[matheus23]

Do you have an opinion about what to do with fct? The spec says this field is optional, but current we emit an empty array no matter what.

Omitting fct and an empty fct array should I think be treated exactly the same way. So, in that case I'd err on the side of omitting the field?

And we should probably start doing that in ts-ucan as well, if we're not doing that already :)