I have open sourced my project where I implemented it by calculating a JWT in Python, pyJwt, using an off IC Django API. It is bit elaborate, but it does nicely secure things using II.
I think that would be a really helpful example - threshold ECDSA is going to be a really versatile feature, and we should be hyping it up more for general secret functionality
I am using a chatbot framework that runs outside the IC, in a traditional cloud. Long term my goal is to run it on the IC, but that will be long term.
My front end is serbed from a canister and it uses Internet Identity as the login mechanism. After login, he frontend then connects to the off IC chatbot over socketio, protected by a JWT token.
Ideally, as part of the Internet Identity login flow, an asymmetric JWT would be generated in the canister and returned to the frontend, which then uses that to authenticate with the chatbot.
Currently, I hacked together an elaborate procedure where the front first logs in with II, then calls an api of an off IC python web server to generate the JWT. The python webserver calls a canister to confirm that a principal was properly logged in with II, and only if that is the case, will it return a JWT. Currently I am using a symmetric JWT and store a secret with the python server that generates the JWT and with the chatbot that validates the JWT.
That off IC python server and complicated logic, just to generate a JWT can be removed if the JWT could be created by the canister during II login.
You could also verify the delegation from II directly on the chatbot server and just create a session for the user.
tECDSA signatures for access tokens are probably too costly/resource intensive (currently a subnet can do about 1 sig/s). Nevertheless, I created a small PoC that creates different types of JWTs on the IC, if you’re curious: https://github.com/domwoe/jwt_issuer_poc
I like your idea to verify the delegation from II directly on the chatbot server and just create a session for the user. I am going to investigate that option.