Currently the Portal is authenticated by using a JWT which is stored in the registry.
As the registry becomes public, this token would also be exposed publicly and thus serve little purpose in terms of securing the API.
The proposed solution is to add an authentication API that returns a valid JWT to use for the rest of the gateway API, whilst removing the one in the registry.
The Portal would then use the proposer's signature as way of identifying itself to the gateway.
It's up to the gateway to determine if the proposer should be then allowed to interact with it, for example by checking if the proposer is part of the active set in the current epoch.
We retain the JWT for all other requests for 2 reasons:
- SImulating a normal Engine API
- Avoiding requiring more signatures after the first one
Currently the Portal is authenticated by using a JWT which is stored in the registry.
As the registry becomes public, this token would also be exposed publicly and thus serve little purpose in terms of securing the API.
The proposed solution is to add an authentication API that returns a valid JWT to use for the rest of the gateway API, whilst removing the one in the registry.
The Portal would then use the proposer's signature as way of identifying itself to the gateway.
It's up to the gateway to determine if the proposer should be then allowed to interact with it, for example by checking if the proposer is part of the active set in the current epoch.
We retain the JWT for all other requests for 2 reasons: