Advanced Security Service Specification: few issues with JWT usage

[sirzooro]

1. Specification says that base64 encoding should be used, what is not exactly true - it should be base64url. It uses - and _ instead of + and /, and no padding with =.
2. Why JWT token sent in Authorization: Bearer header has to be base64-encoded twice? Formal syntax for this header in section 2.1 of RFC 6750 allows for 3 sections of base64url-encoded parts joined with dots. Normal base64 encoding with trailing = is not compatible with it, but base64url with no padding is fine. https://jwt.io/introduction also does not say anything about double encoding.
3. Annex C. JWT over RTSPS also contains Revision History copied from Annex D. There is no RTSPS example.

[jmelancongen]

1. The wording is not super clear but both instances I found are "technically correct". The first paragraph of Section 4.3 says base64, but refers to RFC 7519 which does clarify on the base64url variant. Might be worth rewording to make it clear though. Similarly, the signature part mentions base64, but is clear on base64url in the example fragment.
2. Wow, that is correct. I'm surprised we missed this during review as most prototyping I'm aware did not do that. It seems that Annex A is completely incorrect and should be removed entirely. The examples in the other annexes should be updated to remove that double-base64 thing.
3. This was the case until a couple weeks ago. It was fixed in #407

[sirzooro]

Thanks! BTW, there is one more issue with JWT token example - encoded token contain = in the middle. Decoder at jwt.io complains about it.