Backwards-compatible implementation of RFC7519's registered claim's structure

[oxisto]

This PR aims at implementing compliance to RFC7519, as documented in #11 without breaking the public API. It creates a new struct RegisteredClaims and deprecates (but not removes) the StandardClaims. It introduces a new type NumericDate, which represents a JSON numeric date value as specified in the RFC. This allows us to handle float as well as int-based time fields in aud, exp and nbf. Additionally, it introduces the type StringArray, which is basically a wrapper around []string to deal with the oddities of the JWT aud field.

Closes #11

[oxisto]

Now this introduces a whole range of other problems, specifically: Should we serialise the time as float including the fractions or not? There seems to a lot of confusion about that particular sentence in the RFC, whether actually any form of timestamp like 12345678.123456 should be supported or actually just things like 12345678.000000

Not sure about the state of other JWT libraries, I fear that if we start to serialise as float, this might break more things in the end than it does good.

Update: I saw, that the original author tried to tackle the problem in the v4 branch and was moving in the same direction that I have started. Plus he introduced a TimePrecision variable, which can be used to modify the precision.

The question is: What would be a sensible default? Just seconds to basically ignore the fractions, but allowing developers to be more precise, if needed?

[oxisto]

There is still a weird flaky test failure on Go 1.15, but otherwise, this would be ready for a first review. @mfridman did you have something like this in mind?

[lggomez]

Now this introduces a whole range of other problems, specifically: Should we serialise the time as float including the fractions or not? There seems to a lot of confusion about that particular sentence in the RFC, whether actually any form of timestamp like 12345678.123456 should be supported or actually just things like 12345678.000000

In this regard, RFC 3339 which is supersedes ISO 8601 as the standard for the HTTP date data type clearly states that dates must be serialized at complete precision, even at units of magnitude with zero value or in the absence of a timezone

Not sure about the state of other JWT libraries, I fear that if we start to serialize as float, this might break more things in the end than it does good.

Well, that's the ugly side of standards. As developers we still cope with the misuse of IEEE 754 and its border cases that are by design and using it in scenarios which are not clearly suitable for it like currencies. Enforcing standards can have unexpected side effects, so I get that in this scenario we do not want to break existing projects, and I agree to support extra precisions only if wanted. Kinda contradicts my previous point but it is a way to maintain the backwards compatibility in this current version

[oxisto]

I merged in v4, there were some conflicts but everything should be ready now.

[oxisto]

I know everyone is busy (including myself). Giving a small nudge to @mfridman, @lggomez, @Waterdrips, @ripienaar. There are several request for this coming up in the issues. However it is a big PR so I definitely want to have some reviews here before we merge it :)

[lggomez]

I'd look to replicate #83 into this new implementation, otherwise it LGTM

[mfridman]

I know everyone is busy (including myself). Giving a small nudge to @mfridman, @lggomez, @Waterdrips, @ripienaar. There are several request for this coming up in the issues. However it is a big PR so I definitely want to have some reviews here before we merge it :)

Apologies, I have been quite busy as of late. I'll have some more time this week and can take a look if others haven't.

[lggomez]

Sorry for the delay. I left a comment on the documentation some days prior, and now I came back with some feedback in relation to a possible quirk on the TimePrecision nanoseconds case which, should not be a bug, must be documented for the users so they can be aware. Otherwise, aside from these 2 comments I have no other comments from my side

[mfridman]

lgtm.

[oxisto]

I'd look to replicate #83 into this new implementation, otherwise it LGTM

Done

[lggomez]

LGTM

[oxisto]

Should be good to go then, I had to resolve one last merge conflict. Sorry @lggomez this dismissed your review for some reason... I need another approve for it to merge :)

[mfridman]

Lgtm

[mfridman]

@oxisto I saw a few mentions to this ticket, are we safe to tag a new release 4.1.0 ?

This was on of the main changes since the prior release, figured I'd ask just in case.

[oxisto]

@oxisto I saw a few mentions to this ticket, are we safe to tag a new release 4.1.0 ?

This was on of the main changes since the prior release, figured I'd ask just in case.

We might need to wait until we resolve #86

[mfridman]

I'm not sure how best to coordinate releases, maybe discussions or a tracking "releases" issue?

Just confirming now that #86 is landed we can cut a release: 4.1.0

cc @oxisto