Clarification of JWT Security section: Remove notion of double-base64 encoding of JWTs

[jmelancongen]

The Annex A in the Security spec talks about double-base64 encoding the JWTs that are being used everywhere, which is in contradiction with the actual JWT specs and doesn't fit what we have actually prototyped as far as I'm aware. As far as I know we have always passed JWTs as-is during the different prototypes.

I've left the JWT over SCTP annex the same as I was not sure if double-base64 might actually be necessary there to fit the SOAP spec? Maybe someone with knowledge around that part can confirm? I can move the explanation there if it's needed.

Fixes #434

[venki5685]

Binary Security Token is base64 encoded. JWT by itself cannot fit in the binary security token, since JWT contains .(i.e Dot) character concatenating three JWT components Base64 Url encoded JOSE Header, JOSE Payload, signature.

.(Dot) character is not part of Base64 encoding character set.

[ocampana-videotec]

Correct me if I am wrong, but my understanding is that this PR should be rejected. @venki5685 before me explained by the dot is not compatible with base64 encoding, thus my conclusion is that the PR is not correct. Do you agree?

[jmelancongen]

The Authorization header in HTTP has no such base64 requirement. RFC 7519 says that the dotted format is intended specifically for the Authorization header usecase. All prototyping where Genetec was involved in was done using that standard format as far as I'm aware, and since those worked it also means the device side were sending the RFC format as-is too.

The PR attempts to reflect that reality, instead of the one that splits from the RFC we refer to. We keep the double-encoding only where it is actually needed: In the SOAP messages BinarySecurityToken. Other usages use the JWT directly as is defined in the RFC

[venki5685]

JWT should be base64 encoded when carrying over soap xml as part of Binary Security Token. In other usages JWT can be used directly.

[ocampana-videotec]

The Authorization header in HTTP has no such base64 requirement. RFC 7519 says that the dotted format is intended specifically for the Authorization header usecase. All prototyping where Genetec was involved in was done using that standard format as far as I'm aware, and since those worked it also means the device side were sending the RFC format as-is too.

The PR attempts to reflect that reality, instead of the one that splits from the RFC we refer to. We keep the double-encoding only where it is actually needed: In the SOAP messages BinarySecurityToken. Other usages use the JWT directly as is defined in the RFC

I double checked my scripts for validation the usage with HTTP, you are right. the second encoding is necessary when using JWT within the XML.

[ocampana-videotec]

@jmelancongen I have one doubt before approving the pull request. I see you got rid of the example with the double encoding and put the correct "single encoded" JWT for usage over HTTP.

I think the usage within XML would still need to have an example. It is a very uncommon mechanism, although supported by SOAP. Therefore, I think that an informative annex with that example is very useful. And in that annex we can clearly underline the difference in encoding when used over HTTP and SOAP/XML/SCTP.

What do you think?

[jmelancongen]

That make sense. There's already the annex talking about binary security token that I have adjusted to mention the double encoding. But I could add a bit more details in there now that we've confirmed it is the right strategy.

[sujithhanwha]

That make sense. There's already the annex talking about binary security token that I have adjusted to mention the double encoding. But I could add a bit more details in there now that we've confirmed it is the right strategy.

@jmelancongen, when checking the current ONVIF spec, at present we use EncodingType as http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#BinarySecurityToken, which is a custom EncodingType defined only for ONVIF. Therefore doing double encoding or not is up to ONVIF.

If we are using, EncodingType as "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" then we may have to do base64encoding once again.

[jmelancongen]

I'm not familiar enough with these SOAP naming, from the EncodingType it didn't feel onvif specific at all. But it also doesn't talk about base64 so I was a bit confused. If we say that the format as-currently-specified allows for arbitrary strings, I'd much rather we use the regular JWT syntax everywhere instead of that double-encoding thing. I'm just not sure if it's legal, or even how to validate it

[venki5685]

Base64 or Base64 Url encoding is the commonly used method to encode BinarySecurityToken. I did not understand the rational behind defining custom encoding type [BinarySecurityToken]](http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#BinarySecurityToken,) in ONVIF with out using standard encoding schemes i.e base64 or base64 url encoding. And where this custom encoding is documented in ONVIF and does it not create interoperability issues while using with different devices and clients.