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

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

• 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

Any related work ?

• Decentralied Social Networks
• Voip apps

Our Model

• Users can access a trusted browser
• Users trust/own their signaling server
  • Not necessary if https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-13 gets published
• User's identity is decoupled from signaling process
  •  Users have relationship IdP

• 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

• 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

Signaling Server

Signaling Server

SIP

Browser

JS API

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

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

Signaling Server

Signaling Server

SIP

HTTPS

HTTPS

Browser

Browser

IdP1

IdP2

JS API

JS API

Per

• 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

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

Call notifications

Unfortunately SRV is great for machines

problematic for humans

Signaling Server

Browser

Per's phone

HTTP

Call notifications

Thank you!

Questions ?

WebRTC paves the road to decentralized social
networks