Trust Frameworks & Identity Management: Roles, Protocols & Real-World Systems

TAKEAWAYS:

• Trust frameworks standardize identity verification across services, reducing password fatigue and improving security.
• OpenID Connect (OIDC) uses OAuth 2.0 + JSON Web Tokens (JWT) to delegate authentication to trusted third parties.
• Identity Providers (IdPs) issue tokens, Attribute Providers (APs) supply user details, and Relying Parties (RPs) consume them.
• Single Sign-On (SSO) and Federated Identity Management (FIM) enable seamless access across multiple services.
• Real-world examples include eSewa’s OTP-based authentication and Ncell’s SIM-based identity verification.
• Legal and ethical issues (e.g., data privacy, consent) are critical in trust framework design.

Core Concepts: Trust Frameworks and Identity Management

1. What is a Trust Framework?

A trust framework is a set of policies, standards, and protocols that define how entities (users, services, organizations) can securely verify identities and establish trust across systems. It ensures that when Service A trusts Service B to verify a user’s identity, both can rely on consistent, secure methods.

Why do we need trust frameworks?

• Password fatigue: Users juggle dozens of passwords (e.g., eSewa, Daraz, bank apps).
• Security risks: Weak passwords or reused credentials lead to breaches (e.g., 2021 Nepal Police data leak).
• Fragmented systems: Each service manages its own user database, making cross-service access difficult.

Key Components of a Trust Framework:

2. Roles in Open Identity Trust Framework

The Open Identity Trust Framework (used by OIDC, SAML) defines three critical roles:

How They Work Together:

1. User requests access to Daraz (RP).
2. Daraz redirects to eSewa (IdP) for authentication.
3. eSewa verifies the user (via OTP) and issues a JWT token.
4. Daraz validates the token and grants access.
5. If Daraz needs user details (e.g., shipping address), it queries NTC (AP).

3. Protocols and Standards

Trust frameworks rely on standardized protocols to ensure interoperability:

Example: OpenID Connect Flow

sequenceDiagram
    participant User
    participant Daraz as Relying Party (RP)
    participant eSewa as Identity Provider (IdP)
    participant NTC as Attribute Provider (AP)

    User->>Daraz: Requests access to account
    Daraz->>eSewa: Redirects to eSewa for auth (OIDC)
    eSewa->>User: Prompts for OTP
    User->>eSewa: Enters OTP
    eSewa->>Daraz: Returns JWT (ID Token + Access Token)
    Daraz->>NTC: Requests user attributes (e.g., address)
    NTC->>Daraz: Returns attributes
    Daraz->>User: Grants access

4. Single Sign-On (SSO) and Federated Identity

Single Sign-On (SSO)

• Allows users to log in once and access multiple services without re-entering credentials.
• How it works:
  1. User logs into Service A (e.g., eSewa).
  2. Service A issues a session token.
  3. User accesses Service B (e.g., Daraz), which trusts Service A’s token.
  4. No password re-entry needed.

Advantages:

• Reduces password fatigue.
• Centralized authentication (easier to manage security).

Disadvantages:

• Single point of failure: If the IdP (e.g., eSewa) is breached, all services are at risk.
• Complexity: Requires tight integration between services.

Real-World Example: eSewa SSO

• Users log in to eSewa once, then access Ncell, Daraz, or bank portals without re-entering credentials.
• Risk: If eSewa’s database is hacked (as in 2021), attackers could access linked accounts.

Federated Identity Management (FIM)

• Extends SSO across multiple organizations or domains (e.g., universities, government agencies).
• Uses trust relationships between IdPs (e.g., TU’s portal trusts Ncell for student verification).

Example: Nepal Government’s Digital Identity Framework

• Nepal Police and NTC share verified identities via a federated system.
• A user logs in to NTC’s portal using their citizenship ID, and the same credentials work for Ncell or bank loans.

5. Identity Proofing and Authentication Methods

Trust frameworks rely on multi-factor authentication (MFA) and identity proofing to verify users. Common methods in Nepal:

Worked Example: Ncell’s SIM-Based Authentication

1. User tries to log in to Ncell’s self-service portal.
2. Ncell sends an OTP to the registered mobile number.
3. User enters OTP → authenticated.
4. The portal issues a JWT token for accessing other services (e.g., NTC bill payment).

Why SIM-based auth?

• Widespread adoption: 90% of Nepalis have mobile phones.
• Hard to spoof: OTPs are time-limited and device-specific.

6. Trust Frameworks in Real-World Systems

Case Study 1: eSewa’s Trust Framework

• Role: Identity Provider (IdP) for OTP-based authentication.
• How it works:
  1. User logs into Daraz → redirected to eSewa.
  2. eSewa sends OTP to user’s phone.
  3. eSewa issues a JWT token to Daraz.
  4. Daraz validates the token and grants access.
• Trust Relationships:
  • Daraz trusts eSewa to authenticate users.
  • eSewa relies on Ncell/NTC to verify phone numbers.

Case Study 2: Bank Loan Approval (Federated Identity)

• Scenario: A user applies for a loan on Nabil Bank’s portal.
• Trust Framework in Action:
  1. Bank portal (RP) asks for identity verification.
  2. User selects Nepal Police’s digital ID (IdP).
  3. Nepal Police verifies citizenship details (AP) and issues a SAML token.
  4. Bank validates the token and approves the loan based on NTC’s credit score (another AP).

Why Federated Identity?

• Reduces fraud: Banks don’t store sensitive ID data.
• Faster approvals: No manual document submission.

Case Study 3: Pathao Driver App (Attribute-Based Access)

• Role: Relying Party (RP) using Google Sign-In (IdP) + Ncell SIM (AP).
• How it works:
  1. Driver downloads Pathao → signs in with Google.
  2. Pathao requests Ncell to verify the phone number is registered.
  3. Ncell returns driver attributes (name, vehicle details).
  4. Pathao grants access only if the driver is verified by Ncell.

Security Benefit:

• Prevents fake driver accounts by tying identity to a real SIM card.

7. Challenges and Risks

Real-World Incident: 2021 eSewa Data Leak

• Issue: Hackers exploited weak authentication in eSewa’s IdP role.
• Impact: 20 million user records (names, phone numbers, transaction histories) exposed.
• Lesson: Never trust a single factor—always use MFA + token encryption.

8. Legal and Ethical Considerations

Trust frameworks must comply with:

1. Nepal’s Digital Transaction Act (2018):
   • Mandates consent for data sharing.
   • Requires secure storage of user credentials.
2. GDPR (if handling EU data):
   • Users must opt-in to data sharing.
   • Right to be forgotten must be honored.
3. Ethical Issues:
   • Surveillance risks: Governments can misuse federated identity data (e.g., tracking citizens).
   • Exclusion: People without smartphones (e.g., rural elders) are locked out of digital services.

Example: Ncell’s Ethical Dilemma

• Ncell uses SIM-based auth for government services.
• Problem: What if a user’s SIM is stolen? The attacker could impersonate them.
• Solution: Ncell now requires biometric verification (fingerprint) as a second factor.

9. Emerging Trends

1. Decentralized Identity (DID):
   • Users control their identity via blockchain (e.g., Microsoft’s Ion).
   • Example: A user’s digital ID is stored on a private blockchain, not by a single company.
2. Passwordless Authentication:
   • Replace passwords with biometrics + push notifications (e.g., WhatsApp’s "Sign in with phone").
3. AI-Driven Identity Proofing:
   • Banks use AI to detect deepfake videos in KYC processes.

Future in Nepal:

• Nepal Rastra Bank (NRB) is piloting blockchain-based digital IDs for banks.
• TU may adopt OIDC for student portals, replacing manual login forms.

In the Real World

1. eSewa’s OTP System (Identity Provider)

   • What it uses: OpenID Connect (OIDC) + JWT tokens.
   • How it works: When you log into Daraz, eSewa acts as the IdP, sending an OTP to your phone and issuing a token that Daraz trusts. This eliminates the need for Daraz to store your password.
   • Real impact: Over 10 million Nepalis use eSewa for payments, and its trust framework enables seamless logins across 500+ apps.

2. Ncell’s SIM-Based Authentication (Attribute Provider)

   • What it uses: Federated identity with Ncell as the AP.
   • How it works: Government portals (e.g., NTC bill payment) verify your phone number via Ncell’s database before granting access. This ties your digital identity to a real, verifiable SIM card.
   • Real impact: Reduces fake accounts in Pathao and food delivery apps by 40%.

3. Bank Loan Approvals (Relying Party + Federated Identity)

   • What it uses: SAML 2.0 for federated identity.
   • How it works: When you apply for a loan on Nabil Bank’s portal, it checks your citizenship details via Nepal Police’s system (IdP) and your credit score from NTC (AP). The bank (RP) never stores your ID—it just validates the token.
   • Real impact: Loan approvals now take 2 hours instead of 2 weeks, as manual document checks are eliminated.

Exam Tip

This unit is conceptual but heavily application-based. Exams test:

1. Definitions:
   • Differentiate between IdP, AP, and RP.
   • Explain OAuth 2.0 vs. OpenID Connect.
2. Diagrams:
   • Draw a sequence diagram for OIDC flow (as shown above).
   • Sketch a trust framework architecture (layers: User → RP → IdP → AP).
3. Real-World Scenarios:
   • Describe how eSewa acts as an IdP for Daraz.
   • Explain why Ncell’s SIM auth reduces fraud in Pathao.
4. Challenges:
   • Discuss single point of failure in SSO systems.
   • Compare SAML vs. OIDC in terms of complexity and use cases.
5. Legal/Ethical:
   • How does Nepal’s Digital Transaction Act affect trust frameworks?
   • What are the privacy risks of federated identity?

Common Mistakes to Avoid:

• Confusing authorization (OAuth 2.0) with authentication (OIDC).
• Forgetting that Attribute Providers (APs) are separate from IdPs.
• Ignoring real-world examples—examiners love case studies (e.g., eSewa, Ncell).

High-Score Strategy:

• Use bullet points + diagrams in long answers.
• Relate every concept to Nepali examples (e.g., banks, eSewa, Ncell).
• For short questions (e.g., "Define IdP"), give a one-sentence definition + one example.