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
Currently, only one user can request a message for a particular account, because we currently store keyshares under the signature request account ID.
That is, when server receives a signature request (user/sign_tx) it uses the public key of the author of the request to lookup which keyshare (and therefore which entropy 'account') it should use to sign the message.
For private access mode, this is desired. But for public or permissioned we want to allow different users to request to sign messages with the same 'account' or 'verification key'.
We want to have public and permissioned access modes (although maybe we each understand something different by that).
What steps are required to resolve this?
There are many ways this could be solved. Personally i think we should use either the program modification account ID, or the public verification key as the key under which keyshares are stored.
So when making a signature request, you must also give this identifier as to which 'entropy account' you are requesting to sign a message with.
It is then up to the program to decide whether this is allowed, and in the case of 'permissioned' mode, the signature request ID should be passed as auxiliary data to the program.
Does this change the spec? HTTP, extrinsic, or storage? Is it breaking? Clearly describe the new interface.
Yes i expect this would break server's HTTP API and would might also effect extrinsics for registering
The text was updated successfully, but these errors were encountered:
Currently, only one user can request a message for a particular account, because we currently store keyshares under the signature request account ID.
That is, when
server
receives a signature request (user/sign_tx
) it uses the public key of the author of the request to lookup which keyshare (and therefore which entropy 'account') it should use to sign the message.For private access mode, this is desired. But for public or permissioned we want to allow different users to request to sign messages with the same 'account' or 'verification key'.
This issue is previously noted here: #431
Why is this issue relevant?
We want to have public and permissioned access modes (although maybe we each understand something different by that).
What steps are required to resolve this?
There are many ways this could be solved. Personally i think we should use either the program modification account ID, or the public verification key as the key under which keyshares are stored.
So when making a signature request, you must also give this identifier as to which 'entropy account' you are requesting to sign a message with.
It is then up to the program to decide whether this is allowed, and in the case of 'permissioned' mode, the signature request ID should be passed as auxiliary data to the program.
Does this change the spec? HTTP, extrinsic, or storage? Is it breaking? Clearly describe the new interface.
Yes i expect this would break
server
's HTTP API and would might also effect extrinsics for registeringThe text was updated successfully, but these errors were encountered: