Comments (14)
I never shared the previous workshop's results on GitHub. It may be challenging to understand without an explanation, but it includes several concepts to keep in mind.
Things seem complex. Let's clarify major components and steps at a high level first, then focus on smaller details. Can someone propose something, or else we can resort to a workshop.
I add to my to-do list to propose something if nobody else does first.
from gno.
@moul @jaekwon @zivkovicmilos @Nhatran94 @AnhVAR Can Onbloc also work on this Account Session feature? I'm personally interested in what this will bring to the Web3 wallets in terms of UX, and this could be one of the unique features that Gno offers to the ecosystem.
from gno.
The diagram below shows a rough flow of the Account Session that I have in mind.
sequenceDiagram
participant User
participant Client
participant SessionAccount
participant PrimaryAccount
participant ACL
User->>Client: Login request
Client->>PrimaryAccount: User authentication request
PrimaryAccount->>Client: Authentication result returned
Client->>SessionAccount: SessionAccount creation request
SessionAccount->>PrimaryAccount: Permission delegation request
PrimaryAccount->>ACL: Permission verification request
ACL->>PrimaryAccount: Permission verification result returned
PrimaryAccount->>SessionAccount: Permission delegation approved
SessionAccount->>Client: SessionAccount creation completed
loop User request processing
User->>Client: Service request
Client->>SessionAccount: Signature request
SessionAccount->>PrimaryAccount: Signature permission verification request
PrimaryAccount->>ACL: Permission verification request
ACL->>PrimaryAccount: Permission verification result returned
PrimaryAccount->>SessionAccount: Signature permission verification result returned
alt Signature permission granted
SessionAccount->>PrimaryAccount: Signature request
PrimaryAccount->>PrimaryAccount: Signature processing
PrimaryAccount->>SessionAccount: Signature result returned
SessionAccount->>Client: Signature result returned
Client->>User: Service response
else Signature permission denied
SessionAccount->>Client: Signature permission denied error returned
Client->>User: Error response
end
end
User->>Client: Logout request
Client->>SessionAccount: Session termination request
SessionAccount->>PrimaryAccount: Permission revocation request
PrimaryAccount->>ACL: Permission revocation request
ACL->>PrimaryAccount: Permission revocation completed
PrimaryAccount->>SessionAccount: Permission revocation completed
SessionAccount->>Client: Session termination completed
It would be good to use ACL (Account Control List) to grant access permissions or assign arbitrary roles to certain groups or users and grant permissions based on those roles. [1]
Expanding on this concept, we can allow the Primary Account (PA) to grant the Session Account (SA) the arbitrary to sign under certain conditions. With this apporach, the users can interact with dApps using the SA without directly accessing the PA.
Using a DAO as an example, Tier1DAO can grant Tier2DAO the authority to sign within a certaiin amount, and Tier2DAO can grant Tier3DAO the authority to sign within an even smailler amount and so on.
Furthermore, as much as this concept is used to enhance security, it is crucial to throughly separate them so that even if a lower-level session is attacked, it does not affect the root accounts (or, higher-level account). Moreover, to ensure the consistency, even when a session is used, the actual signing must occur in the PA.
cc: @zivkovicmilos @dongwon8247
[1] I think we can use the Directory
type of the p/demo/acl
package.
from gno.
Here are a few ideas I have regarding session accounts:
- Implement session time limits: I believe that session accounts should have a session time limit, meaning that the account's access would be revoked after a certain period of inactivity. This would enhance security by preventing unauthorized access if the account is left unattended.
- Shift signature message generation to session accounts: I'm concerned about the current implementation of signature messages being generated by the primary account. This poses a security risk as hackers could potentially exploit this to interact with the main wallet. To mitigate this risk, we should implement a mechanism where signature messages are generated by the session account instead of the primary account. This would ensure that even if a hacker gains access to the session account, they would not be able to compromise the primary account.
from gno.
A similar concept introduced by Starknet/Argent https://support.argent.xyz/hc/en-us/articles/19662145575325-v0-4-0-contract-upgrade-for-Argent-X
from gno.
@AnhVAR @nhatran Let's continue the discussion here
from gno.
Here is my idea for that. The main account will store in wallets, each application like game, social will be generate Session Account to do all action without need request many time to accept from main wallet.
from gno.
@moul @dongwon8247 pls feedback
from gno.
demo_H.264.mp4
We made a sample demo follow our solution. You can see in video, we made a smart contract, we can link with main account with session account. After that, the main account can authorize session accounts to perform actions on chain.
@moul @dongwon8247 @Nhatran94
from gno.
@jaekwon Should we build a feature that is only an account session, or should we build a feature that is similar to account abstraction on ETH? gnolang/hackerspace#58
from gno.
of course @dongwon8247 we would love to have you join us on this.
from gno.
Based on what @moul has drawn, I can imagine and want to improve by using SSO service to help users start sessions more conveniently instead of using QR codes. I propose the following. Please contribute further:
We will build a deep account session system within the core blockchain. This system is designed in the direction of a Single Sign-On (SSO) service.
The use of secondary accounts to access assets of the primary account will be determined by the validator (we will update Tendermint 2 for it).
The Dapps must integrate SSO. This involves logging in by signing a message on the primary account.
User Experience:
- User clicks on the login button with the account session.
- User verifies the scopes of this session (each Dapp will determine different scopes).
- User signs, grants permission to the account session.
- User uses Dapp with the token provided by SSO (the Dapp does not retain this token).
- The account session will have a timeout, or the user can revoke permissions by pressing the end session button.
- Users can monitor active sessions and revoke them all on the Adena wallet.
Permission scopes:
To ensure the security of the primary wallet, Dapps will request scopes for each session. Users will review these scopes and sign off on them.
- Execute Transaction
Rate Limit: 100 transactions/hour
Gas Limit: 1 GNO
Valid For: Specified contract, Specified function - Transfer Native Token
Rate Limit: 10 transfers/day
Cap Limit: 100 GNO
Valid For: Native Token - Transfer Custom Token
Rate Limit: 10 transfers/hour
Cap Limit: 100 TokenA, 100 TokenB
Valid For: List specific tokens (e.g., TokenA, TokenB)
Session Expiration:
- Fixed Timeout: The session expires after 24 hours from the start of the session.
- Sliding Expiration: The expiration time is reset each time the user interacts with the server. (e.g., 30 minutes).
Consensus Modifications:
It will be a new concept when one account can sign transactions for another account. We need to update Tendermint 2 to allow validators to accept those signatures. Additionally, information related to sessions will also be stored on the blockchain to provide Tendermint 2 with confirmation information.
Security:
- Private key: The private key will be generated and only stored in the memory of the SSO application (not stored in storage) and ensure that no one can access this memory portion. We can further apply the MPC method (splitting private data and storing it in SSO service and DApp client) or encrypted passwords to enhance security.
- Session token: The session tokens are stored in the client browser (or mobile app). Dapps does not have permission to access this information.
- Scopes: Whitelisting scopes from Dapp requests can be considered if necessary.
from gno.
@moul What do you think above our team idea?
from gno.
@moul @dongwon8247 can we create a workshop to move it forward? cc @AnhVAR @jamesnguyentech
from gno.
Related Issues (20)
- uassert/urequire: Wrong message when strings are not the same. HOT 1
- uassert/urequire: Messages from PanicsWithMessage method are inverted HOT 2
- [examples] Improve AVL interface to take in any type of ID HOT 3
- PR Review throttling HOT 1
- [govdao] Make `r/gov/dao` proposals fee-based for non-members
- [chain] Add a more robust e2e node / cluster testing framework
- CI should detect problems in PRs, not after merging HOT 1
- CI: detect outdated docs' examples
- gnofaucet should have docker images/binaries HOT 1
- "Go version autonomy" for important packages used by the keeper, like go/types and go/format
- [ops] Add release flow for `gnofaucet`
- feature request: Ledger hardware wallet support for validator addresses
- Move GnoVM testing logic within pkg/gnolang; separate from `gno test` logic
- [GnoVM] Better error message with `MsgRun` HOT 1
- javascript: getElementById("source") not always available
- change default genesis package creator, and add way to configure it HOT 1
- Validator resolves old IP address after sentry IP change when using FQDN HOT 1
- p/demo/mux: support query strings HOT 1
- integrate p/demo/avl/pager with existing examples
- Discord roles HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gno.