WebRTC paves the road to decentralized social
networks

Filippos Vasilakis
KTH Royal Institute of Technology
Network Services and Systems

Stockholm, Sweden
fvas@kth.se

With the rise of Internet, things started to change..

  • Codecs and implementation take place at the end points
  • Network is considered only as a medium

Enormous possibilities for research and innovation

Network architecture powering telephony had always been centralized

  • functionality takes place in SAIs (fixed)
    • codecs, multiplexing, processing
  • ​common standards and protocols

20 years later..

  • Voip has replaced telephony with very small (fixed) cost for all parties
  • End users receive equal QoS if not better (with video enabled)
  • End user got enormous amount of different options and providers

BUT

  • No compatibility in most popular Voip providers :/
  • Providers try to lock the users => more engagement => stable income
    • Worsens user experience

WebRTC might change this

  • runs in the browser
  • IETF/W3C have standardized it
    • the developer API
    • the underlying protocols (SRTP, SDP, ICE, TURN, STUN etc)

What do we want to solve ?

  1. Allow users to authenticate to other parties using their favorite social service
  2. Use the most common user interface: browsers
    • leverage WebRTC

Break silos in a standard way

How ?

Any related work ?

  • Decentralied Social Networks
  • Voip apps

Our Model

Other Entities

  • Calling Services
    • Ideally users should own/run one
    • Can be authenticated through TLS
  • Identity Providers
    • can be authenticated though TLS
  • Other users
    • Authenticated through IdPs

Solution Overview

Our solution is divided in 3 parts:

  1. The steps required for Alice to communicate with Per when both have a trusted browser open
  2. The steps required for each Identity Provider to confirm a user’s identity
  3. The steps required when Alice tries to communicate with Per when he is not in front of a trusted browser

Signaling Server

Signaling Server

SIP

Browser

JS API

Alice

  • Media channel information
  • ICE candidates
  • A fingerprint attribute binding the communication to a key pair
  • User's identity IdP fingerprint
  • Per’s calling site domain or IP

Per

HTTPS

Signaling Server

Signaling Server

SIP

HTTPS

Browser

Browser

JS API

JS API

Alice

Per

  • Media channel information
  • ICE candidates
  • A fingerprint attribute binding the communication to a key pair
  • User's identity IdP fingerprint
  • Alice’s calling site domain or IP

HTTPS

Signaling Server

Signaling Server

SIP

HTTPS

Browser

Browser

JS API

JS API

Alice

Per

  • Media channel information
  • ICE candidates
  • A fingerprint attribute binding the communication to a key pair
  • User's identity IdP fingerprint
  • Alice’s calling site domain or IP
  • TLS + IdP fingerprints make communication secure
    • secure enough

HTTPS

User identity confirmation by IdPs

Based in RFC 5785

  • Defines a framework for well-known URIs
    • URIs are located in /.well-known/{service}

    • Solves discoverability issues
  • IdPs domain name
  • IdP's protocol to be used (like OAuth2)
  • https://example.com/.well-known/oauth2?foo=bar

Each identity provider is associated with two values:

URI scheme

HTTPS only

IdP domain name

Authentication protocol

Signaling Server

Signaling Server

SIP

HTTPS

HTTPS

Browser

Browser

IdP1

IdP2

JS API

JS API

Alice

Per

Media

DTLS+SRTP

Get identity fingerprint

Verify identity based on fingerprint

  • A user's browser authenticates other parties by accessing the well-known URI
  • Her browser runs IdP's JS in a different security context (like a constrained iframe)
    • feeds it with the parties claimed identity fingerprint
  • IdP provides all the permitted user's information
    • the authenticating party can setup privacy policies
    • the other entities can decide whether the exposed information is enough to derive the identity

Authenticate another user using RFC 5785

The same endpoint is used for generating the fingerprint by the authenticating party

Call notifications

Not everyone is in front of her computer/browser :)

We need a way to notify the callee that someone wants to establish a call with her

SRV domain record ?

_service._proto.name. TTL class SRV priority weight port target.

Very powerful

hostname    IN  A   ip-address  time-to-live

for reference, an A record signature:

Call notifications

Unfortunately SRV is great for machines

problematic for humans

Privacy issues !

Security issues as well

The callee should expose her IP only when she is ready to answer the call.

Signaling Server

Signaling Server

SIP

Browser

Alice

Per's phone

Push Notifications

HTTP

TCP

Call notifications

Filtering service

Contacts (identities/ips) whitelist/blacklist

Block based on Per's preferences or status (busy)

Thank you!

Questions ?

WebRTC paves the road to decentralized social
networks

Made with Slides.com