The answer is (once again) complicated. The short version is that basically we do not yet support JWT(s) or anything that would require EncryptedSecret; The question is that how much you need this and when?

That password limit is a bug, though to other direction, the limit should actually be 64bytes, due to https://reference.opcfoundation.org/v104/Core/docs/Part4/7.36.2/:

“The legacy token secret format defined in 7.36.2.2 is not extensible and provides only encryption but the encrypted data is not signed. It is used together with the USERNAME_1 UserIdentityToken. The password secret exchanged with this format shall not exceed 64 bytes.”

1.04 defined new “7.36.2.3 EncryptedSecret Format” and also sort of re-wrote the issued token and there is some “native” support for JWT’s, https://reference.opcfoundation.org/Core/docs/Part4/7.36.6/. That would seem to need the EncryptedSecret Format:
“The IssuedIdentityToken is used to pass SecurityTokens issued by an external Authorization Service to the Server. These tokens may be text or binary.

OAuth2 defines a standard for Authorization Services that produce JSON Web Tokens (JWT). These JWTs are passed as an Issued Token to an OPC UA Server which uses the signature contained in the JWT to validate the token. OPC 10000-6 describes OAuth2 and JWTs in more detail. If the token is encrypted, it shall use the EncryptedSecret format defined in 7.36.2.3.”

previously (pre-1.04) it was
“The IssuedIdentityToken is used to pass W S-Security compliant SecurityTokens to the Server. WS-Security defines a number of token profiles that may be used to represent different types of
SecurityTokens. For example, Kerberos and SAML tokens have W SS token profiles and shall be
exchanged in OPC UA as XML Security Tokens.

…
“

The 1.04 part 6 link: https://reference.opcfoundation.org/Core/docs/Part6/6.5.2/, that tells what the issuedTokenType and issuerEndpointUrl should contain if it is a JWT.

The encryption algorithm parameter in the token is The URI of the AsymmetricEncryptionAlgorithm. This goes a bit outside of what I usually do, thus this part might be incorrect. I think the limiting factor is the cert size, and basically there is no way around that: https://stackoverflow.com/questions/10007147/getting-a-illegalblocksizeexception-data-must-not-be-longer-than-256-bytes-when .

The EncryptedSecret would use symmetric encryption algorithm so size would not be a problem. And I think this symmetric key would then be encrypted with the asymmetric algo using the public key as in the “legacy token”.

Technically the limits on the token size as it is now is: 1k cert: 117bytes, 2k cert: 245bytes, 4k cert: 501bytes, anything larger would need the EncryptedSecret support (plus not sure is this only for JWTs yet).