Original title: "Using Ethereum Login - Proposal Workflow"
Original Source: Spruce Blog
Original Compilation: ETH Chinese Station
< br>
Translator's note: Spruce is an open source software company focused on decentralizing identity and data, evolving from "not your keys, not your coins" to "not your keys , not your identity." Previously, ENS and Spruce announced a partnership, and Spruce issued a document stating that Sign-in with Ethrereum will enable users to use their Ethereum accounts instead of accounts owned by large companies to access Web2 network services.
Regarding the work on promoting login with Ethereum, our initial goal was to create a specification and reference implementation for users to log in to traditional Web2 using Ethereum accounts The service provides an end-to-end authentication process and uses ENS as the main user control data aggregator.
This will allow Ethereum users to provide their own digital identities based on keys, rather than relying on Centralized identity providers such as Google, Facebook or Amazon. We further describe how relying parties can retrieve and verify information about a user's identity, such as email accounts, phone numbers, and social media accounts, while protecting user privacy.
Currently, if users want to log into a website, they need to choose from several large Internet companies A company that serves as its identity providers (identity providers, IdPs) for its digital identity. The designers of OAuth 2.0 and OpenID Connect originally intended to result in an entire ecosystem of identity providers from which users could choose, not just a few unified entities. These large identity providers control who users are by simplifying authentication for end users and developers, which means they also control access to key services including banking, payments and social networks (they even have visible privileges) . This intermediary structure restricts people's direct access to online services in much the same way that centralized banks restrict users' direct access to financial markets.
Ethereum-compatible wallets are becoming more and more popular, such as MetaMask with more than 5 million monthly active users . There is now a new way to provide direct authentication for logging into Web2 services: using message fronting and claim aggregation directly from the user's Web3 wallet and ENS, rather than through traditional intermediaries.
These statements can be used not only for the login process, but also for the wider use of existing Web2 accounts transform into cryptocurrency applications.
· Use an Ethereum wallet that supports WalletConnect to log in to the installed "Sign- in With Ethereum Server SDK" (using Ethereum login server SDK) in the Web2 service.
· Learn what information a Web2 service needs to authenticate and what sources to complete the login process.
· From "Sign-in with Ethereum Client SDK" (client SDK for logging in with Ethereum) to select claims to present to the server so that the server can retrieve and verify information from a variety of sources, including Ethereum Name Service (ENS), Interplanetary File System (IPFS), HTTPS wait.
A statement that uses encryption and requires authorization (note: this may be removed from the extension specification core library and specification).
· Integrate Sign-in with Ethereum Server SDK or specification into popular Sign-in with Ethereum is supported in web frameworks and authorization libraries, either directly or through an authentication method aggregator such as Auth0 or Passport.js.
· Clarify the requirements for Sign-in with Ethereum. As part of the login process, the service can retrieve and verify claims submitted by the user and/or aggregated by ENS, such as Web3 account balances, NFT ownership, W3C verifiable credentials, etc.
· Link a Web2 account to an Ethereum address. Services can retrieve and verify claims submitted by users and/or ENS to augment their Web2 accounts with new features, such as special portals or downloads for NFT owners only, private off-chain admin panels for DAO members, or from Other decisions made by on-chain data or off-chain signed credentials.
Integrate Sign-in with Ethereum workflow into existing OAuth 2.0 using configuration only /OpenID Connect Relying Party. This workflow relies on a trusted identity provider that supports the Sign-in With Ethereum authentication method and is able to establish an OAuth 2.0/OpenID Connect session.
In terms of how the workflow works, the relying party will first present the user with a login request, including Which claims from ENS, nonces to prevent replay, and unique site identities are required for different authentication types. In this case, ENS domain ownership can serve as a basic anti-Sybil mechanism.
The user then performs Ethereum-based authentication with a WalletConnect signature, which is sent to relying party. This step will use a data schema that enables user selection of relevant claims, allowing the user to specify which claims (i.e., selected facts about their account) that the relying party should query should be used to establish a session. These facts are retrieved via ENS as TXT records by value or by reference (i.e. URL).
Then, the relying party uses the claim query method to retrieve and verify the relevant claims of the Ethereum account, such as ENS addresses, email verification, social media account linking or verification (e.g. via Uniswap Sybil), and any other claims supported by both the user and the server.
Users can then access and interact with the service as usual and be able to provide their digital identity rather than being at the mercy of centralized identity providers. We believe this will be a great advancement in user control and management of web interactions.
A note about privacy. We'll start by focusing on Web3 users who are already used to and understand the implications of associating their Ethereum addresses with their public personas, such as the many who proudly display their NFTs as their profile picture (pfp) on Twitter people. We believe that privacy should be about enabling the proper flow of information, not absolute secrecy. As the privacy requirements of different user groups (such as mainstream web users) change, our approach to using privacy tools must also change, such as using newly derived Ethereum addresses on a per-interaction basis, or incorporating zero-knowledge privacy techniques to reduce correlation.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia