Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public / Permissioned access mode not possible with current setup #484

Closed
ameba23 opened this issue Nov 8, 2023 · 0 comments
Closed

Public / Permissioned access mode not possible with current setup #484

ameba23 opened this issue Nov 8, 2023 · 0 comments

Comments

@ameba23
Copy link
Contributor

ameba23 commented Nov 8, 2023

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 registering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant