rmb right now support message validation against 2 different key types. (ed, and sr) key. This is encoded in the signature attached to the message itself.
So signature created by a ed signature will have the prefix 0x65 (ascii for e) and sr signature will have prefix 0x73 (ascii for s). We need to support one more signature type jwt this one can has a prefix t.
In this signature type. the signature is a fully (signed) jwt token. Hence validation of the token depends soley on the jwt content and not the message. Thins that need to be taken into acount:
Token signature still can be of Sr or Ed type. this can be checked by decoding the jwt and then validating it's signature
Timestamps and life of the token need to be validated. an expired token is not accepted.
Note:
RMB will never sign with jwt, it will only use either ed, or sr as configured by the user. the JWT will normally be done by the UI when using a proxy.
rmb right now support message validation against 2 different key types. (ed, and sr) key. This is encoded in the signature attached to the message itself.
So signature created by a ed signature will have the prefix
0x65(ascii fore) and sr signature will have prefix0x73(ascii fors). We need to support one more signature typejwtthis one can has a prefixt.In this signature type. the signature is a fully (signed) jwt token. Hence validation of the token depends soley on the jwt content and not the message. Thins that need to be taken into acount:
Note: RMB will never sign with jwt, it will only use either ed, or sr as configured by the user. the JWT will normally be done by the UI when using a proxy.