Setting Up a User Consent Framework for Data Sharing in Social Logins

Social logins like "Sign in with Google" or "Login with X" offer user convenience but create significant privacy and control trade-offs. The standard OAuth 2.0 flow often bundles broad data permissions into a single, opaque consent screen. Users grant access to their profile, email, and sometimes friend lists without clear understanding of how this data will be used, stored, or shared downstream. This model centralizes sensitive user information with a few large identity providers, creating honeypots for data breaches and limiting user sovereignty over their digital identity.

A transparent consent framework shifts this paradigm by making data sharing explicit, granular, and revocable. Instead of a monolithic permission grant, users should be presented with specific, scoped requests: "Share your email for login only" versus "Share your email for marketing." This requires moving beyond basic OAuth scopes to implement selective disclosure patterns. Technologies like Verifiable Credentials (VCs) and decentralized identifiers (DIDs) enable users to present cryptographically signed claims (e.g., "I am over 18") without revealing their raw birthdate, providing a blueprint for minimal data exposure.

For developers, building this requires architectural changes. The client-side integration must request specific data scopes, while the backend must handle partial data responses and token management for revoked consents. A robust system logs all consent events on-chain or in an immutable ledger, providing a transparent audit trail. Smart contracts can enforce consent terms, automatically revoking access after a set period or when conditions change. This technical foundation turns consent from a one-time checkbox into a dynamic, user-managed relationship.

Implementing transparent consent is not just ethical; it's becoming a regulatory imperative. Regulations like the EU's General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) mandate purpose limitation, data minimization, and clear user consent. A well-designed framework ensures compliance by design. Furthermore, in Web3, where user ownership is paramount, transparent consent becomes a key feature, building trust and differentiating applications in a crowded market. It aligns application incentives with user privacy.

This guide will walk through building this framework. We'll cover defining granular data scopes, implementing a consent management UI, handling credential issuance and verification using libraries like SpruceID's didkit, and storing consent receipts. The goal is to provide a practical, implementable pattern for making social logins more respectful, compliant, and user-controlled.

Before implementing a consent framework, you need a foundational understanding of the involved technologies. This includes decentralized identity standards like Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), which are governed by the W3C. You must also be familiar with OAuth 2.0 and OpenID Connect (OIDC) flows, as they are the bedrock of most social login systems. For on-chain components, knowledge of smart contract development (e.g., using Solidity for EVM chains) and wallet interaction libraries like ethers.js or viem is essential. Finally, ensure you have a development environment ready with Node.js, a package manager like npm or yarn, and access to a blockchain testnet such as Sepolia or Polygon Amoy.

The system architecture for a consent framework integrates traditional web infrastructure with decentralized components. At its core is a Consent Management Service, a backend server that handles the logic for requesting, storing, and verifying user consent receipts. This service interacts with a Verifiable Data Registry, which can be a blockchain (e.g., Ethereum, Polygon) or a decentralized storage network (e.g., IPFS, Arweave) used to anchor consent proofs. The user's wallet (e.g., MetaMask, Rabby) acts as the identity and signing agent, while the Relying Party (your dApp) initiates the login and data request flow. The architecture must also include a secure off-chain database for storing encrypted user data, ensuring only consented access is granted.

A critical architectural decision is choosing the consent proof mechanism. One approach is to use a smart contract as a consent ledger. When a user grants permission, they sign a structured message (e.g., using EIP-712 for type-safe signing) which is submitted to the contract, emitting an event with the consent parameters. Alternatively, you can use signed Verifiable Credentials, where the consent terms are issued as a VC by the user's wallet and presented to the service. The VC can be stored off-chain, with its integrity verified by checking the issuer's DID against the blockchain. Each method has trade-offs: on-chain proofs are transparent and non-repudiable but incur gas costs, while off-chain VCs are more flexible and private.

Data minimization and selective disclosure are key principles. Your architecture should support granular consent scopes, similar to OAuth scopes but defined for specific data attributes (e.g., profile:email, social:followers). The consent request should clearly state the purpose, duration, and data processors involved. Implement cryptographic techniques like zero-knowledge proofs (ZKPs) via libraries like SnarkJS or projects like Sismo Protocol to allow users to prove they meet certain criteria (e.g., "is over 18") without revealing the underlying data. This moves the system from all-or-nothing data sharing to attribute-based, purpose-limited access.

Finally, you must plan for the user experience (UX) flow. This involves designing a consent interface that can be triggered from your dApp, often via a wallet connection library like WalletConnect or a dedicated modal. The interface should present the consent terms in a human-readable format before requesting a signature. Your backend service needs corresponding endpoints for /auth/request, /auth/callback, and /data/query that verify signatures and check the on-chain or VC-based consent status before returning any user data. Logging and monitoring for consent lifecycle events are crucial for compliance and debugging.

In traditional OAuth 2.0 for social logins, scopes like profile or email are often overly broad, granting access to a user's entire public profile or primary email address. A granular permission model decomposes these into specific, atomic units of data. For example, instead of a single profile scope, you might define separate scopes for profile:display_name, profile:avatar, and profile:birthdate. This design empowers users with fine-grained control, allowing them to share only the data necessary for your application's core functionality, such as a display name for personalization while withholding their birthdate.

When designing scopes, categorize them by data sensitivity and purpose. Common categories include Identity (user:id, user:handle), Profile (profile:name, profile:image), Social Graph (connections:read, followers:list), and On-Chain Activity (transactions:read, nft_holdings:read). Each scope should have a clear, user-friendly description explaining why the data is needed (e.g., "To show your profile picture next to comments"). This transparency is mandated by frameworks like the W3C's Verifiable Credentials and is critical for building trust.

Technically, these scopes are implemented as strings in your authorization request. Using the OAuth 2.0 scope parameter, you request a space-separated list. For a decentralized application (dApp) using Sign-In with Ethereum (SIWE) or a similar protocol, the request might look like this in a message payload:

codeCopy
scope="profile:name profile:avatar tokens:read"

The authorization server or wallet (like MetaMask) then presents these discrete permissions to the user for individual approval, creating a clear consent record.

The key principle is data minimization. Request the least amount of data required. If your app only needs to display a username, request profile:display_name, not the full profile scope. This reduces privacy risk for users and liability for your application. Furthermore, consider defining scope dependencies. A scope like post:create might inherently require profile:display_name to attribute the post, which should be communicated clearly to avoid surprising the user with additional permission prompts later.

Finally, document your permission scopes in your developer documentation or a dedicated permissions page. This allows users to audit what they've granted and enables other developers to understand your data model. Granular scopes are the foundational layer upon which revocable consent and selective disclosure are built, setting the stage for the next steps in implementing the consent framework.

A revocable consent token is a non-transferable, soulbound token (SBT) that represents a user's permission for a specific data-sharing action. Unlike traditional OAuth scopes stored in a centralized database, this token is minted on-chain, creating an immutable, user-owned record of consent. Each token's metadata should encode the granted permissions (e.g., read:profile, write:posts), the recipient application's address, and an expiration timestamp. This on-chain artifact serves as the single source of truth for authorization checks, enabling transparent and auditable data governance.

The core smart contract functions are mintConsent, revokeConsent, and checkConsent. The mintConsent function is callable only by the user (via their wallet) and creates a new SBT with the encoded metadata. A critical security pattern is to implement an allowlist of verified application addresses to prevent spam and phishing. The revokeConsent function allows the token owner to burn their token, instantly revoking the permission. The checkConsent function is a view function that dApps call to verify an active, unexpired token exists for a given user and permission set before accessing data.

Here is a simplified Solidity example for the consent token's core logic, using the OpenZeppelin ERC721 implementation for SBTs (by overriding _update to block transfers):

solidityCopy
contract ConsentToken is ERC721 {
    mapping(uint256 => Consent) public consentData;
    address[] public allowedApplications;

    struct Consent {
        address application;
        string permissions; // e.g., "read:profile"
        uint256 expiresAt;
    }

    function mintConsent(address app, string memory perms, uint256 expiry) external {
        require(isAllowed(app), "App not authorized");
        uint256 tokenId = totalSupply();
        _mint(msg.sender, tokenId);
        consentData[tokenId] = Consent(app, perms, expiry);
    }

    function revokeConsent(uint256 tokenId) external {
        require(ownerOf(tokenId) == msg.sender, "Not owner");
        _burn(tokenId);
        delete consentData[tokenId];
    }

    function checkConsent(address user, address app, string memory perm) external view returns (bool) {
        // Logic to iterate user's tokens and check for a valid, unexpired match
    }
}

To integrate this with a social login flow, the frontend application must interact with the user's wallet. After a user authenticates via OAuth (e.g., Sign-In with Google), your dApp should prompt them to sign a transaction calling mintConsent. This transaction approves the specific data sharing request. The backend API, which holds the user's OAuth access token, should then call the checkConsent function on-chain before returning any user data. If the consent is valid, the API proceeds; if the token is revoked or expired, it returns a 403 Forbidden error. This decouples the authentication provider from the authorization logic.

Key considerations for production include managing gas costs for users (consider L2s like Base or Polygon), implementing off-chain indexing (e.g., with The Graph) for efficient checkConsent queries, and defining a clear data schema for permissions. Standards like ERC-4973 for SBTs or EIP-4361 (Sign-In with Ethereum) can inform your design. The final system provides users with a transparent, chain-verifiable ledger of all data permissions they have granted and the power to revoke them instantly.

A privacy dashboard is the user-facing interface for your consent framework. Its primary function is to present data-sharing requests in a clear, transparent manner. When a user authenticates via a social login, your application should request specific permissions (e.g., profile:read, email:read, onchain_tx:read). The dashboard must list these requested scopes in plain language, explaining what data each scope accesses and how it will be used. For example, instead of showing erc20:balances, the interface should state "View your token balances." This transparency is a core requirement of regulations like GDPR and builds essential user trust in Web3 applications.

The technical implementation involves storing and managing user consent states. Upon first login, you should record the granted permissions in a user-specific data structure, such as a key-value store in your backend database or a smart contract on-chain for fully decentralized apps. A common pattern is to use a mapping like mapping(address => mapping(string => bool)) public userConsents, where the string key is the permission scope. The dashboard UI then queries this state to display checkboxes or toggles reflecting the user's current preferences. Any change from the user triggers an update to this state, which must be securely authorized, often by verifying a signature from the user's wallet.

For dynamic consent, your system must handle incremental authorization. A user might initially grant only profile:read but later decide to enable email:read for a newsletter feature. The dashboard should allow toggling these permissions independently without requiring a full re-authentication. Implement this by having your auth middleware check the stored userConsents for the required scope before executing a protected action. If consent is missing, the app should redirect the user back to the privacy dashboard with a clear prompt for the additional permission, following the principle of progressive disclosure.

Code integration is straightforward. Here's a simplified example of a smart contract function to update consent, using Solidity and EIP-712 signatures for security:

solidityCopy
function setConsent(string memory scope, bool granted, bytes memory signature) public {
    bytes32 messageHash = keccak256(abi.encodePacked(msg.sender, scope, granted));
    address signer = ECDSA.recover(messageHash, signature);
    require(signer == msg.sender, "Invalid signature");
    userConsents[msg.sender][scope] = granted;
    emit ConsentUpdated(msg.sender, scope, granted);
}

Your frontend would generate the signature using the user's wallet (e.g., eth_signTypedData_v4) when they toggle a setting, then call this function.

Finally, the dashboard should provide auditability. All consent changes should emit events (as shown in the code example) that are logged and, ideally, made accessible to the user. Consider providing a timeline or log within the dashboard showing when each permission was granted or revoked. This creates a verifiable record of user intent, which is valuable for compliance and dispute resolution. By combining clear UI, secure state management, granular controls, and an audit trail, you build a privacy dashboard that respects user autonomy and meets modern regulatory standards for data handling.

When users authenticate via social logins like Google OAuth or Sign-In with Ethereum (SIWE), your application receives personal data from the identity provider. Under regulations like the EU's General Data Protection Regulation (GDPR) and California's California Consumer Privacy Act (CCPA), you must obtain explicit, informed consent before processing this data. This is distinct from the OAuth scope consent for account access. You need a separate mechanism to document user permission for your specific data usage purposes, such as profile personalization or analytics. Failure to do so can result in significant fines, up to 4% of global annual turnover under GDPR.

A compliant consent framework requires several key elements: granularity (users must consent to specific purposes separately), informed choice (clear language about what data is collected and why), freely given (no service denial for declining non-essential data use), and easy withdrawal. For a Web3 app using SIWE, you might request separate consents for storing the wallet address on-chain, using the ENS name for display, and analyzing transaction patterns. The consent record itself—including the timestamp, purpose, and the specific data fields—must be stored as proof of compliance.

Technically, this is often implemented as a multi-step flow after authentication. First, the user signs in. Then, your frontend displays a modal or dedicated page listing data processing purposes. Each purpose has a toggle, with essential items (like storing the user ID for session management) pre-selected and non-essential items (like marketing) optional. The user's selections are sent to your backend, which stores them in a secure, audit-ready database. A common pattern is to hash the consent statement text with the user's ID and timestamp, storing this hash on-chain or in your database to create an immutable audit trail.

For developers, here is a conceptual backend endpoint example using Node.js and Express to record consent:

javascriptCopy
app.post('/api/record-consent', async (req, res) => {
  const { userId, consentPurposes, consentStatementVersion } = req.body;
  // 1. Validate user session
  // 2. Store in your database
  const consentRecord = await db.collection('consents').insertOne({
    userId,
    timestamp: new Date(),
    purposes: consentPurposes, // e.g., ['profile', 'analytics']
    version: consentStatementVersion,
    ipAddress: req.ip
  });
  // 3. Optionally, create a hash and store it on-chain for verification
  const hash = ethers.utils.id(`${userId}-${consentStatementVersion}-${Date.now()}`);
  // ... call to your smart contract to store `hash`
  res.json({ success: true, recordId: consentRecord.insertedId });
});

You must also provide users access to their consent history and a way to withdraw consent, which triggers data deletion or anonymization processes where required. Integrate these options into a user settings page. For CCPA compliance, ensure a clear "Do Not Sell or Share My Personal Information" link is visible. Regularly review and update your consent statements if your data practices change. Tools like OneTrust or Cookiebot can manage the UI and logging, but for decentralized apps, you may need a custom solution that aligns with on-chain identity principles, potentially using Zero-Knowledge Proofs (ZKPs) to prove consent without revealing the full record.

Implementing a robust consent framework is a critical step for any dApp integrating social logins like Sign-In with Ethereum (SIWE) or OAuth. The core principles involve granular permission scopes, transparent data handling, and user-centric control. By using smart contracts for on-chain consent records or decentralized identifiers (DIDs) for portable preferences, you can build a system that respects user autonomy while enabling secure data sharing. This approach directly addresses the trust deficit in traditional Web2 models.

For next steps, begin by auditing your dApp's data requirements. Map out which user attributes (e.g., public wallet address, transaction history, social graph data from a Lens Protocol profile) are essential for core functionality versus optional for enhanced features. This exercise will define your permission scopes. Then, choose your technical stack: a simple on-chain registry using an ERC-725-inspired contract for consent states, or an off-chain verifiable credential system using Ceramic or Spruce ID's Kepler for more complex, portable consent agreements.

Finally, integrate the consent UI/UX into your authentication flow. Tools like Dynamic or Privy provide SDKs that can streamline this process. Always conduct a security audit of your consent management contracts and ensure your frontend clearly communicates the purpose, duration, and revocability of each data request. For further learning, explore the W3C Verifiable Credentials data model and the EIP-4361 (SIWE) standard for implementation details. Building with consent from the ground up is not just a compliance measure—it's a foundational component of credible neutrality and user sovereignty in Web3.