WebAPI/PresentationAPI:Protocol Draft

This is a draft of protocol proposal for 2-UAs Presentation Scenario

Requirement

• Device Discovery
  • Device information: unique name, user-friendly name, address for ctrl server
  • Device capability: resolution, supported media type, supported apps, supported IO capability
  • Protocol information: protocol version
• Service Launching
  • Service information: app/page URL
  • Session information: session Id, bootstrap info for communication
  • Controlling message: launch, reconnect, terminate
  • User settings: preferred locale
• Communication
  • establish dedicate transportation channel
• Security
  • device challenge: OOB channel, passkey
  • data encryption: key derived from challenge, key exchange for communication channel

Architecture

Here is the high-level architecture overview of 2-UAs protocol

Architecture overview of 2-UAs Protocol

Controlling Page

• request a presentation session via PresentationRequest
• interact with Presented Content via PresentationConnection

Presented Content

• page loaded by Receiving User Agent for a presentation session
• interact with Controlling Page via PresentationConnection

Controlling User Agent

• display controlling page
• display pairing information and provide UI to resolve device challenge

Receiving User Agent

• display presented content
• generate challenge for pairing procedure
• display pairing information

PresentationControlClient

• query for available PresentationControlServer
• query device capability for device filtering
• initiate connection to server
• trigger session creation / reconnection / termination
• reply to device challenge during pairing procedure

PresentationControlServer

• register as an service profile on mDNS
• handle session creation / reconnection / termination
• generate auth token / cryptography key for pairing procedure

mDNS Query

• mDNS stack that supports service query over mDNS protocol

mDNS Registration

• mDNS stack that supports service registration over mDNS protocol

WebRTC

• WebRTC stack that provides Data Channel implementation
• Generate SDP for exchanging offer/answer over presentation control protocol

Protocol Details

Service Discovery

• STEP 1: server registers itself as a mDNS service with service type = "_presentation-ctrl._tcp"
• STEP 2: client starts a mDNS query for service type "_presentation-ctrl._tcp"
• STEP 3: mDNS notifies a service instance is found with service profile provided
• STEP 4: establish control channel to server
• STEP 5: send query command to server
• STEP 6: server sends query-reply command back to client, carrying detailed device capability
• STEP 7: client updates device profile to controlling user agent and closes control channel

Device Pairing

• STEP 1: server display a passcode and send challenge command to client, after receiving connect command
• STEP 2: client display passcode input and wait for user typing the same passcode
• STEP 3: client and server use the passcode to initiate J-PAKE procedure
  • STEP 3a: client and server exchange the round 1 information
  • STEP 3b: client and server exchange the round 2 information, and compute session key
• STEP 4: client send verify command with H(H(key)) to server
• STEP 5: server verify the H(H(key)) and send H(key) to client
• STEP 6: client and server can use key to encrypt following control message and provide H(key) as auth token.

Establish Control Channel

Simply establish a TCP socket to the service port received during service discovery

Start Presentation

• STEP 1: find device (mDNS/DNS-SD: _presentation-ctrl._tcp)
  • STEP 1a: query device capability (send query message: supported media type, supported URL format)
• STEP 2: setup control channel to remote device (send connect message: device name, protocol version, supported challenge method)
  • STEP 2a: device challenge / device pairing (send challenge message: ) (send resolve message: ) (send auth message: encrypted auth token)
• STEP 3: launch app / page (send launch message: url, session Id)
• STEP 4: setup communication channel (send offer message: SDP for DataChannel) (send answer message: SDP for DataChannel)
  • STEP 4a: establish DataChannel via SDP
• STEP 5: close control channel (send close message: )

Establish Data Channel

• STEP 1: client creates data channel and generates SDP as offer
• STEP 2: establish control channel to server
• STEP 3: send send-offer command with offer to server (send-offer command should be encrypted and carried by encrypted-ctrl-msg)
• STEP 4: server creates data channel, assigns the received SDP as remote description, and generates SDP as answer
• STEP 5: send send-answer command with answer to client (send-answer command should be encrypted and carried by encrypted-ctrl-msg)
• STEP 6: client assigns the received SDP as remote description
  • STEP 6': client and server might generate more ICE candidate and exchange it via update-ice-candidate command (update-ice-candidate command should be encrypted and carried by encrypted-ctrl-msg)
• STEP 7: data channel is created via JSEP procedure

Terminate Presentation

• STEP 1: setup control channel to remote device
• STEP 2: terminate app / page via session Id (send terminate command: session Id) (terminate command should be encrypted and carried in encrypted-ctrl-msg command)
• STEP 3: receiving user agent close the presented content and close data channel
• STEP 3a: server send terminate-ack to client
• STEP 4: client close control channel and notify onterminate event to controlling page

Close Connection

• STEP 1: controlling page or presented content initiate connection.close()
• STEP 2: sending close command to remote device, with closeReason = "closed"
• STEP 3: close data channel while receiving close command (close command should be encrypted and carry in encrypted-ctrl-msg command)
• STEP 4: notify onclose event to both controlling page and presented content

Resume Connection

• STEP 1: setup control channel to remote device
  • STEP 1a: complete challenge with stored information
• STEP 2: reconnect app / page via session Id (send reconnect message: session Id) (reconnect message should be encrypted and carried in encrypted-ctrl-msg)
• STEP 3: setup communication channel following the Data Channel establish procedure
• STEP 4: close control channel

References

• Protocol suggestion by Second Screen WG
• Architecture proposed by Google