# Frequently Asked Questions

How does ENS integration work?

ENS integration allows authentication using domain names like "alice.eth". The module detects ENS names (containing "."), queries ENS Registry for ownership, handles wrapped domains, and validates that the ENS owner matches the wallet address in your authentication contract.

Which networks are supported?

Authentication: Only Oasis Sapphire (testnet/mainnet) due to confidential smart contract requirements.

ENS: Ethereum mainnet, Sepolia testnet, or any network with ENS contracts deployed.

Network Configuration Options:

Production (Mainnet) Configuration: Use Oasis Sapphire Mainnet for authentication contracts and Ethereum Mainnet for ENS queries. This setup is ideal for production deployments with real ENS domains.

Testing (Testnet) Configuration: Use Oasis Sapphire Testnet for authentication contracts and Ethereum Sepolia for ENS queries. This setup is perfect for development and testing with test ENS domains.

Single Network Configuration: Use the same network for both authentication and ENS queries. This simplified setup is suitable when you don't need cross-chain ENS functionality.

Custom Network Configuration: Use custom RPC endpoints for both authentication and ENS queries. This setup is useful for private networks or alternative providers.

What smart contract interface is required?

Your contract must implement:

    ...
    function authenticateUser(
        string memory username, string memory realm, string memory method,
        string memory uri, string memory nonce, uint8 algorithm,
        bytes memory response
    ) public view returns (bool)
    ...

    ...
    function getWalletAddress(string memory username)
        public view returns (address)
    ...

What happens if networks are down?

Authentication fails after the configured timeout. Use reliable RPC providers, appropriate timeout values, and implement fallback authentication for high availability production environments.

Do SIP clients need modifications?

No. The module maintains full RFC 2617/7616 compatibility. Clients use standard digest authentication. ENS validation happens transparently on the server side.

How do I troubleshoot authentication failures?

1. Enable debug mode: modparam("auth_web3", "contract_debug_mode", 1)

2. Check Kamailio logs for detailed error information

3. Verify ENS domain ownership on etherscan.io

4. Test RPC endpoints manually

5. Verify contract addresses and function signatures

Is this suitable for production?

Yes, but consider: network reliability (use reliable RPC providers), latency (blockchain calls add 100-1000ms), security (audit smart contracts), and monitoring (implement comprehensive network status monitoring).

Security Considerations: Smart contract audits should be conducted thoroughly for authentication contracts. Leverage Oasis Sapphire's confidential computing capabilities for enhanced security. Use HTTPS for all RPC endpoints to ensure network security. Verify that ENS ownership matches wallet addresses during validation. Implement backup authentication mechanisms for emergency situations.

Are there any known limitations with blockchain authentication?

Yes, the main limitation is dependency on external blockchain network availability and response times. Authentication will fail if the blockchain RPC endpoint is unreachable or if the smart contract is not properly deployed.

Blockchain calls add 100-1000ms latency compared to traditional database queries. Set appropriate RPC timeouts (10-30s recommended) to handle network delays. Furthermore, ENS resolution may require 2 RPC calls, adding additional overhead. Use reliable RPC providers for production environments to minimize performance impact.

How do I configure for containers?

All parameters can be configured via environment variables for containerized deployments. Environment variables take precedence over modparam configurations. Use environment variables for all parameters:

    ...
    # Environment variables
    AUTHENTICATION_RPC_URL="https://testnet.sapphire.oasis.dev"
    AUTHENTICATION_CONTRACT_ADDRESS="0xYourContract"
    ENS_RPC_URL="https://ethereum-sepolia-rpc.publicnode.com"
    CONTRACT_DEBUG_MODE="0"
    RPC_TIMEOUT="15"
    ...

    ...
    # Minimal Kamailio config
    loadmodule "auth_web3.so"
    ...

Can I use free RPC providers?

Free providers work for development and low-volume production but have rate limits and no SLA. For production, use paid providers (Infura, Alchemy) for better reliability. For Oasis Sapphire, use official endpoints.

The following RPC endpoints are commonly used with the auth_web3 module:

Oasis Sapphire Mainnet: https://sapphire.oasis.io (Production network)

Oasis Sapphire Testnet: https://testnet.sapphire.oasis.dev (Testing network)

Ethereum Mainnet: https://mainnet.infura.io/v3/YOUR_KEY OR https://eth.drpc.org (Production network)

Ethereum Sepolia: https://ethereum-sepolia-rpc.publicnode.com (Testing network)