You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updating authentication and token management flow to accomodate context switching of agent for different roles based on type of agent (multi-tenant or dedicated) and different role in multi-tenancy(dedicated and tenant)
Token creation for different roles (Basewallet (BW), Tenant Wallet(TW), Dedicated agent wallet(DW))
Authenticating token based on endpoints being accessed and type of token(authorization)
Attaching agent context based on roles through request
Secret keys used for generating and verifying tokens for BW and TW in case of multi-tenancy will be same and stored in BW. (Since, opening wallet to access secretKey for each request in case of tenant agent verification will be an expensive process in terms of time and computation) - This is already been coded and only needs to be un-commented depending on which approach we decide on.
Removing middleware and utilizing authentication module for authorization and context switching
Handling error for unauthorized access
Receiving apiKey as an additional parameter while staring the agent. This will act as an authentication for BW and DW
Releasing agent session at the end of request
Using agent context from request for all endpoints. (Unlike as a global param currently being used in controllers)
Update branch
Optimize in accordance to load-testing reports
Security: fall back mechanism to update the jwt secret, if required, while starting the agent
Route changes: to combine didcomm, anoncreds, etc. routes
Updating authentication and token management flow to accomodate context switching of agent for different roles based on type of agent (multi-tenant or dedicated) and different role in multi-tenancy(dedicated and tenant)