2014_who is calling which page on the web

26 Published by the IEEE Computer Society 1089-7801/14/$31.00 © 2014 IEEE IEEE INTERNET COMPUTING

Secu

rity

and

the

Rea

l-Ti

me

Web

Who Is Calling Which Page on the Web?

Li Li, Wu Chou, Zhihong Qiu, and Tao CaiHuawei Shannon (IT) Lab

Web identity and resolution identifies, authenticates, and locates users on the

Web, and is a critical aspect of Web Real-Time Communications (WebRTC).

Although WebRTC proposes a security architecture to integrate with federated

Web identity systems, it’s incompatible with those identity protocols that don’t

satisfy WebRTC requirements. To fill this gap, two alternative architectures are

proposed. In addition, a Web-of-Trust model is described to address hierarchical

identity systems’ limitations, and a mirror-presence system is developed that can

locate Web users in real time when they’re moving between websites.

W eb Real-Time Communications (WebRTC) is an ongoing joint effort from the W3C and IETF to

develop standards that will enable real-time communication (RTC) between Web browsers. The W3C WebRTC work-ing group’s charter is to develop a JavaScript API to control and monitor the RTC function inside Web brows-ers,1 while the IETF RTCWEB working group is focused on the real-time media and transport protocols between those functions (see https://tools.ietf.org/wg/rtcweb/charters). Although Web brows-ers can communicate through voice and video using browser-dependent plug-ins and extensions, WebRTC is the first industrial effort to develop an open platform for RTC over the Web based on standard APIs and protocols.

More than 30 companies and orga-nizations — including Google, Microsoft, Cisco, Mozilla, Huawei, and Ericsson — are investing in WebRTC; their hope is to change both the telecommunications

industry and the Web ecosystem. WebRTC could change telecommunica-tions by lowering the barrier for Internet companies, browser vendors, and device makers to provide RTC services over the Web. With proper standards, web-sites and Web browsers collectively can become a new open platform for deliv-ering RTC and collaboration services to users. With this platform and the flex-ibility of HTML5, developers can rap-idly create real-time Web applications that run on any operating system and any device. For users, WebRTC’s benefit isn’t just free phone calls — it’s the abil-ity to interact in a global communication space in an unconstrained way.

However, creating a global RTC sys-tem over the Web entails some acute technical challenges:

• Identity authentication. How can we authenticate users on the Web? That is, how do we verify their identities to ensure that only the


NOvEMbER/DECEMbER 2014 27

intended parties receive confidential or pri-vate information?

• Identity resolution. How can we locate users on the Web? That is, how do we use identity to find the pages users are visiting so we can deliver calls to them when they’re moving between different websites?

Both processes are difficult, because there’s no uniform way to identify, authenticate, and locate a user on the Web. For this rea-son, WebRTC proposes a security architecture to integrate with federated identity systems. However, not all such systems are compatible with the WebRTC architecture. To solve this problem, we propose two alternative architec-tures to adapt incompatible identity protocols to the WebRTC security architecture. Further-more, while federated identity protocols such as OpenID (http://openid.net/wg), BrowserID (https://developer.mozilla.org/en-US/Persona), and WebID2 give users great flexibility in let-ting them identify themselves with any URI they own, they also have drawbacks, includ-ing a hierarchical authentication model, in which an identity can be authenticated only by a single chain of identity providers. To address these issues, we propose a new Web identity system based on a Web-of-Trust (WoT) identity network.

Finally, on top of Web identity architec-tures, we also propose a decentralized identity-resolution system that tracks and locates users across websites by connecting their multiple identities on different sites with real-time pres-ence. Although WebRTC can work with a single website that connects all users who want to call each other, we focus on cross-site collaborations that let users call each other at different web-sites. Few websites currently offer such capabil-ity, but we believe it represents the Web’s future as a global communication space. Without this cross-site capability, WebRTC would create only closed communities that make it difficult for users to interact on a global scale; this would be akin to having a browser that let you send emails only to people who share your email pro-vider, so you have to use Yahoo email for peo-ple on Yahoo and Gmail for people on Google. The challenge for cross-site collaboration is to develop technologies that impose minimal requirements for websites without compromis-ing their autonomy, security, or usability.

WebRTC Identity ArchitectureAs Figure 1 shows, the WebRTC security archi-tecture3 consists of three distinct component layers:

• The identity layer consists of identity pro-viders (IdPs) and their JavaScript proxies, which can authenticate a user to a browser.

• The media layer consists of Web browsers that exchange secure real-time media using the Secure Real-Time Protocol (SRTP).

• The signaling layer consists of pages and websites that control the calls between browsers.

WebRTC doesn’t standardize the signaling layer, so websites can establish calls between browsers using any standard or proprietary voice-over-IP (VoIP) signaling protocol — such as the Session Initiation Protocol (SIP), the Extensible Messaging and Presence Protocol (XMPP), Jingle, or Skype.

Because WebRTC requires interoperability with traditional VoIP systems, its call signal-ing and media layers are similar to those of traditional VoIP architectures such as SIP and XMPP. However, the identity layer is quite dif-ferent; WebRTC lacks a built-in identity system, so it uses those developed for the Web in gen-eral. For this reason, the identity layer’s prob-lems are new and unique.

WebRTC’s architecture deems browsers as the trusted computing base (TCB) and IdPs as trusted third parties between the browsers, but it doesn’t trust websites for user authentications.

Figure 1. WebRTC security architecture. The architecture consists of three components: the identity layer, the media layer, and the signaling layer (dashed lines indicate the layer boundaries).

Site A Site B

Page A Page B

Browser A Browser B

IdP BIdP A

BobAlice

Mediachannel(SRTP)

Signalingchannel

Proxy A Proxy B

Security and the Real-Time Web

28 www.computer.org/internet/ IEEE INTERNET COMPUTING

Given these trust relationships, browsers must authenticate users to ensure the media streams are coming from and going to the right users. This process involves complex interactions among the browsers and the IdPs.

To illustrate this process, let’s assume that Alice, who is at www.toys.com and has an OpenID URI alice.identity-a.com from IdP identity-a.com, wants to make a video call to Bob, who is at www.games.com and has an Open ID URI bob.identity-b.com from IdP identity-b.com. When Alice clicks a button on Page A to call Bob, the SRTP module in Browser A generates a public-key certificate needed for a secure media channel between the browsers. It then asks identity-a.com to sign the fingerprint of the public key with Alice’s identity alice.identity-a.com.

For identity-a.com to fulfill this request, Alice must authenticate herself to it using whatever method it requires (such as a user-name and password). After Alice is authenti-cated, identity-a.com will sign the fingerprint and alice.identity-a.com, and return the digital signature to Browser A, which will send the fingerprint, the identity, and the signature in a call-offer message to Page B on Browser B, going through the websites www.toys.com and www.games.com.

Upon receiving the offer, Page B will instruct Browser B to contact identity-a.com to verify the signature received from Browser A. If the verification is successful, Browser B knows that the call and the fingerprint are indeed from Alice. If Bob decides to answer the call, he must authenticate himself with identity-b.com. Upon success, Browser B sends a call-answer message including Bob’s fingerprint, identity, and signa-ture to Page A on Browser A, going through the websites www.games.com and www.toys.com.

Once Page A receives the answer message, it performs signature verification against iden-tity-b.com to authenticate both bob.identity-b.com and the fingerprint. The aforementioned interactions essentially establish an authentica-tion chain from each browser to an identity. For Browser A, the chain is (Browser A, IdP B, bob.identity-b.com); for Browser B, it’s (Browser B, IdP A, alice.identity-a.com).

Once both browsers authenticate the peer users and their fingerprints, they proceed to establish an encrypted media channel accord-ing to Datagram Transport Layer Security (DTLS) by exchanging their certificates. Each browser matches its peer’s fingerprint against the peer’s certificate to ensure that the call and the media channel come from the same user. Using the encrypted media channel, the brows-ers negotiate a common master secret key for both browsers to derive their key streams to encrypt the video streams according to SRTP.

The WebRTC security architecture decou-ples the websites (such as www.toys.com and www.games.com) that make calls from the user authentication websites (such as identity-a.com and identity-b.com). But this architecture cre-ates problems for some IdP protocols that are designed for browser–website authentications, and can’t be readily used for browser–browser authentications, because browsers can’t act as websites (see Figure 2).

The IdP protocol WebID illustrates this mis-match. In WebID architecture, users can employ any URI they own on the IdP as their identity to authenticate to Site B by showing that the cer-tificate they send to Site B over TLS is the same as the one at the URI. To use WebID as it is in WebRTC, Browser B must act as Site B; this is impossible, however, because Browser B doesn’t accept TLS connections from Browser A.

OAuth, another IdP protocol, suffers the same problem.4 According to OAuth 2.0, after Browser A authenticates to the IdP to grant access to Site B, the IdP will redirect Browser A to Site B so that it can receive the access code or token. How-ever, this redirection between browsers is impos-sible, because Browser B doesn’t accept HTTP connections from Browser A.

In both cases, the IdP protocols must be modified for use with WebRTC. As we now describe, our goal is to improve reusability by using existing and future IdP protocols without changing them for WebRTC.

Figure 2. Two identity triangles that don’t match. Some IdP protocols authenticate a Web browser to a website through HTTP, but can’t authenticate one browser to another because a browser can’t accept HTTP connections.

Browser A

Website B

Browser B

IdP



WebRTC Identity AdaptationHere, we describe two approaches to adapt IdP protocols to the WebRTC security architecture.

Identity Adaptor Provider (IdAP)IdAP extends the WebRTC security architecture by inserting a new layer between the proxies and the IdPs to convert WebRTC authentication requests to the IdP protocol. As Figure 3 shows, in this architecture, there’s an IdAP for each IdP. For each call, the IdAP plays a dual role: to the browsers, it acts as an IdP that provides the required WebRTC identity proxy and services (that is, sign and verify); to the IdP, it acts as a regular website that tries to authenticate the users through the IdP.

When a browser requests a signature for a call, an IdAP creates a session that holds the call-related data (such as the fingerprint) and directs the users to log in to the session. Because the IdP guards the session, the user must authenticate through the IdP to the IdAP. Once the user is authenticated to the session, the IdAP signs the fingerprint, saves the signature in the session, and returns it to the browser.

When another browser sends a call-verifica-tion request, the IdAP will verify the identity assertions and signature based on the signature saved in the session. The session can be deleted once the signature verification is complete. This process is used by both sides to establish two authentication chains: (Browser A, IdAP B, IdP B, Bob) and (Browser B, IdAP A, IdP A, Alice) for a call between Alice and Bob.

Any website that wants to provide WebRTC identity services can operate the IdAP, either as a separate server or as an extension to an exist-ing IdP. IdAPs can adapt multiple IdPs that speak different authentication protocols and methods. The approach won’t increase user work or risk because users interact only with the IdP, and their IdP secrets won’t be exposed to IdAP. This approach increases IdP protocols’ interoperabil-ity and extensibility with the WebRTC security architecture, because it allows the IdP protocols and the WebRTC architecture to evolve indepen-dently and still be used together. IdAP’s draw-back is that it adds an extra layer and thus the authentication process might take longer. IdAP sessions could also become the target of security attacks. The IdAP can mitigate attacks by secur-ing the communications with the IdP and brows-ers and releasing the sessions as soon as possible.

Mixed Layer Approach The mixed layer approach assumes that brows-ers trust their websites for user authentications, without restricting the authentication protocol used. Although different from WebRTC, this assumption is reasonable in many situations in which users trust the websites because of reputation, a business contract, or government regulations; examples include financial institu-tions, insurance companies, call centers, phone carriers, schools, hospitals, and government agencies.

This architecture removes the mismatch that occurs when a browser must act as a website to satisfy both the WebRTC requirements and the IdP protocol (see Figure 2). Instead, Browser A authenticates to Site B using IdP A, and Browser B authenticates to Site A using IdP B (see the two dashed triangles in Figure 4).

In this mixed layer architecture, a call from Alice, with an identity alice1 on IdP A, to Bob, with an identity bob1 on IdP B, proceeds as follows:

1. Browser A calls Site A, which creates a ses-sion (session-a) to hold the fingerprint (fingerprint-a) from Browser A and the signature (signature-a) from IdP A, and sends a call-offer message with alice1, fingerprint-a, and signature-a to Site B.

2. Site B creates a session (session-b) and sends a challenge message back to Site A, asking it to prove the identity alice1, and Site A

Figure 3. WebRTC security architecture with identity adaptor provider (IdAP). The IdAP layer bridges the gap between the WebRTC security architecture and the IdP protocols.

Site A Site B

Page A Page B

Browser A Browser B

IdP BIdP A

BobAlice

Mediachannel(SRTP)

Signalingchannel

Proxy A Proxy B

IdAP A IdAP B



redirects Browser A to access session-b with alice1.

3. Site B authenticates alice1 through IdP A and Browser A (IdP triangle for Browser A).

4. Upon successful authentication of Alice, Site B alerts Browser B about the incoming call from Alice.

5. To answer the call, Browser B saves its fin-gerprint (fingerprint-b) and the signature (signature-b) from IdP B in session-b and sends a call-answer message with

bob1, fingerprint-b, and signature-b to session-a.

6. Site A responds with a challenge message, asking Site B to prove identity bob1, and Site B redirects Browser B to access session-a with bob1.

7. Site A authenticates bob1 through IdP B and Browser B (IdP triangle for Browser B).

8. Upon successful authentication of Bob, both session-a and session-b are authenti-cated, and the call is established between the two browsers.

During the call, the authentication chain for Alice is (Browser A, Site A, IdP B, bob1), and the authentication chain for Bob is (Browser B, Site B, IdP A, alice1).

In this architecture, the IdP proxy is optional if the browsers implement an IdP protocol, such as WebID. When the proxy is used, it need only sign the fingerprint because the website, the IdP, and the browsers can verify the signature without involving the proxy.

The security of this process heavily depends on the chosen IdP’s security properties. This architecture is more efficient than the IdAP approach because there’s no additional IdAP layer. It’s also extensible because a website can implement different IdP protocols.

Web-of-Trust Identity SystemThe two proposed WebRTC security architec-tures depend on a hierarchical identity model through which only one IdP can authenticate identity. If the IdP is compromised or shut down, all the previously valid identities will become unverifiable.

To address these limitations, we must move away from the hierarchical security model and use instead the WoT model, in which multiple IdPs can authenticate an identity based on Pretty Good Privacy (PGP) certificates.5 Unlike an X.509 certificate, which signs only one public key and identity pair, a PGP certificate can associate mul-tiple identities to a public key and allow multiple IdPs to sign each association. As Figure 5 shows, this flexibility lets a browser find multiple authen-tication chains. For example, having two disjoint chains from Browser A to Browser B — (Browser A, IdP A, IdP D, Browser B) and (Browser A, IdP C, IdP B, Browser B) — makes the authentication process much more robust than the hierarchical identity model, which permits only single chains.

Figure 5. WebRTC security architecture based on the Web-of-Trust (WoT) model. Multiple authentication chains can exist between a browser and an identity based on PGP certificates endorsed by multiple IdPs.

Figure 4. WebRTC security architecture using the mixed layer approach. The signaling and authentication layers are combined to bridge the gap between the WebRTC security architecture and the IdP protocols.

Site A Site B

Page A Page B

Browser A Browser B

IdP BIdP A

BobAlice

Signalingchannel

Proxy A Proxy B

Mediachannel(SRTP)

Site A Site B

Page A Page B

Browser A Browser B

IdP BIdP A

Bob 1Bob 2

Alice 1 Alice 2

Mediachannel(SRTP)

Signalingchannel

Proxy A Proxy B

IdP C

IdP D



Users can incrementally build a PGP certifi-cate based on their existing identities on mul-tiple IdPs. In Figure 5, for example, we assume Alice has an identity Alice1 on IdP A and an identity Alice2 on IdP C, and that her goal is to build a PGP certificate with both IdP A and IdP C. To start, Browser A generates a PGP certificate and signs the public key and iden-tity Alice1. At this point, the PGP certificate looks like the tree in Figure 6a. Alice then uses Browser A to ask IdP A to sign her PGP certifi-cate after she authenticates as Alice1 to IdP A. Upon success, Browser A receives a PGP certifi-cate from IdP A and merges it with its PGP cer-tificate to produce the PGP certificate in Figure 6b, in which the identity Alice1 is signed by both Browser A and IdP A.

Alice then authenticates to IdP C and asks it to cross-certify the PGP certificate in Figure 6b with IdP A. In this process, IdP C will validate and sign the PGP certificate in Figure 6b to first produce the PGP certificate in Figure 7a, and then send it to IdP A, which will validate and sign it to produce a new PGP certificate. Finally, the new PGP certificate is returned to Browser A, which produces the final PGP certificate in Figure 7b.

Alice can repeat this process on N IdPs one by one to produce a PGP certificate with N dis-tinct identities, each signed by at most N IdPs. The PGP certification can occur automatically when Alice logs in to the websites for any pur-pose. Alice simply clicks a checkbox on the login page to activate the PGP certification and enters her username and password, or whatever is required to log in, and the rest happens in the background.

When Alice calls Bob using identity Alice1, Browser A signs the fingerprint with the PGP certificate’s private key and sends the signature along with the relevant part of the PGP certifi-cate to Browser B. Browser B checks to see if any of the certificate’s signers are trusted by its circle of trust (that is, IdP B and IdP D). In this case, no direct trust relations exist, so Browser B checks for indirect trust relations. If it hap-pens that IdP D endorses IdP A, then Browser B can follow the chain (Browser B, IdP D, IdP A, Browser A) to verify the certificate.

Once Browser B verifies the certificate, it can use the certificate’s public key to verify the fingerprint signature. It can even add its own signature to the PGP certificate so that it can

directly authenticate Alice in the future with-out going through any IdP. Generally, Alice can select any of her identities from a PGP certifi-cate for a call — such as using Alice1 to call Bob, and Alice2 to call Carol — by sending the PGP certificate’s relevant subtrees.

Some email systems use the WoT model, but websites haven’t widely adopted it. The techni-cal challenge is to develop standard protocols for websites to cross-certify certificates in a secure, efficient, and automated manner. Web-scale key servers are also needed for websites to establish trust chains based on PGP certifi-cates. Finally, the WoT’s complexity should be carefully managed, without compromising its usability and flexibility.

Identity ResolutionIdentity resolution’s goal is to locate the pages users are visiting based on their identities so that a call to a user can be routed to the correct page. Identity resolution is difficult for two reasons. First, users move between pages and websites in unpredictable ways. Second, identity alone

Figure 6. First steps in building a PGP certificate. (a) PGP certificate before IdP A. (b) PGP certificate after IdP A.

Figure 7. Achieving a PGP certificate. (a) PGP certificate after IdP C. (b) The final PGP certificate.

Key

Alice 1

Browser A

Key

Alice 1

Browser A IdP A

(a) (b)

Key

Alice 1Alice 2

BrowserA

IdP A IdP C

Key

Alice 1

BrowserA

IdP A

Alice 2

IdP C IdP C

(a) (b)



isn’t always enough to derive the website a user is visiting. To illustrate this second problem, we examine two common Web identity schemes.

Common Authentication ApproachesWebsites typically use one of two schemes to authenticate users: authoritative or federated. In an authoritative identity system, a website authenticates a Web identity directly without a third-party IdP. For example, a user can log in at www.yahoo.com with a Yahoo email address, or at www.games.com with a local name, such as player123. This scheme ties a user identity to the websites on which it is used. To make a call to this identity, the calling browser must know the user identity (such as email address) if it can be resolved to a routable IP address; or the user identity plus the website URI, if the user identity (such as player123) isn’t resolvable to a routable IP address.

In a federated identity system, such as Open ID, WebID, BrowserID, and OAuth, the user’s iden-tity is decoupled from the websites that use it, so the website can’t be derived from the user identity. For example, let’s say that Alice logs on at the website www.games.com with a feder-ated identity alice.identity-a.com. When Bob calls this identity, the call shouldn’t be routed to identity-a.com, because it’s neither the intended destination nor a site that knows Alice’s current location (www.games.com). To make a call to this identity, the calling browser must know the iden-tity plus the website the user is visiting.

Given the Web’s decentralized nature, it’s unlikely that websites will adopt a hierarchical name resolution system such as DNS. Without a central identity system, most users maintain

several identities on different websites, each for a particular communication service and social context. For example, a user might have a Gmail identity for personal emails, a Twitter identity for fans, a Facebook identity for friends, and a LinkedIn identity for professional relations. In other words, users typically maintain a circle of websites and related identities.

The Mirror-Presence ApproachThe mirror-presence system lets users create per-sonal identity-resolution systems based on their circle of websites and identities. The system resolves an identity to a page based on the user’s presence events — such as available, busy, away, or in a meeting — which indicate the user’s avail-ability and willingness to communicate.

Figure 8 illustrates this idea: Bob has a circle of four websites and identities, and whenever he visits a website in this circle, his presence is reflected (mirrored) to other websites in the circle. In Figure 8, Bob is visiting page P3 from Site 3 using identity Id3, and his presence on Site 3 is reflected on Sites 1 and 2 following the dotted arrows, as if he were visiting those sites at the same time. To Bob’s friends on Sites 1 and 2, Bob appears online as Id1 and Id2, respec-tively, and he can be contacted through those sites even though he’s actually on Site 3.

When Alice calls Id1 on Site 1, the call will follow a call-routing path represented by the solid arrows in the reverse direction of the pres-ence flows. The call will be parked at Site 1 while an alert message is routed to Site 3 and then to page P3. To answer the call, Bob will click a link included in the alert message. The link will bring Bob back to Site 1. After Bob logs in to Site 1, he can pick up the call and talk to Alice.

For the mirror-presence system to work, users must be able to connect their identities on different websites with presence subscriptions. For instance, Id1 must subscribe to the pres-ence events of Id3, and Id2 must subscribe to the presence events from Id3 and Id4. For Id1 on Site 1 to subscribe to Id3 on Site 3, Bob must authorize Id1 to access resource Id3. For Id3 to send presence events to Id1 after the subscrip-tion, Bob must authorize Id3 to access resource Id1. Thus, to connect the identities by presence subscriptions requires mutual resource authori-zations between the websites.

To perform these mutual resource authoriza-tions safely and efficiently, we modify OAuth

Figure 8. A mirror-presence system. A user’s multiple identities on several websites are connected by presence subscriptions; the presence events flow along the dashed arrows between the identities.

Browser B(Bob)

Site 3

Site 2

Site 1

Id1 Id3

Id2Site 4

Id4

P3

Browser A

P1



2.0,4 which is designed for unilateral resource authorization, to perform bilateral resource authorization. With bilateral OAuth 2.0, a user can grant two websites access to each other’s resources using the same number of messages as the unilateral OAuth 2.0. Furthermore, a user can start the bilateral authorization process from either website, and the end result for the sites will be the same. During the mutual authoriza-tions, user’s secrets on both sites won’t leak to each other, and both sites will obtain each other’s access tokens, which can be used in the presence subscription and notification messages.

After connecting the identities, Bob can visit both Site 1 and Site 3 at the same time. Fig-ure 8 shows this: Browser B opens page P1 from Site 1 and page P3 from Site 3. In this case, Id1 must resolve the conflicts between presence events. For example, page P3 says Bob is busy while page P1 says Bob is available. To favor the direct connection, we can just keep presence events from P1 as Bob’s presence on Site 1. (We describe the mirror-presence system’s architec-ture and implementation in more detail else-where,6 and also offer experimental results that demonstrate its feasibility and efficacy.)

A mirror-presence system might raise pri-vacy concerns for users because it allows fed-erated websites to track a user’s identity and presence. However, unlike current Web track-ing technologies — which leave users out of the control loop — mirror presence is based on a user’s own decisions. If a website isn’t trusted, the user can remove it from the circle at any time. To further protect user privacy, websites can enforce privacy policies on the federation. It’s also possible to use technical solutions, such as end-to-end message encryptions and Web proxies, to hide user presence and loca-tions from federated websites. Still, protecting user privacy without losing good services that depend on user behavior patterns remains an important and ongoing Web research area.

T he Web is a fast-changing space in terms of its infrastructure and the information users

create upon it. WebRTC is a new set of technolo-gies that will enrich the Web infrastructure and lead to new ways to create and share informa-tion. Web identity authentication and resolu-tion mechanisms provide the basic means for us to communicate and collaborate safely and

efficiently. We hope the technologies we’ve described here can enhance our understand-ing of the challenges in this space and open the possibilities for better solutions to come.

References1. A. Bergkvist et al., eds., “WebRTC 1.0: Real-Time Com-

munication between Browsers,” W3C draft, work in

progress, June 2013.

2. H. Story, ed., “WebID-TLS, WebID Authentication over

TSL,” W3C draft, work in progress, July 2013.

3. E. Rescorla, ed., “RTCWEB Security Architecture,”

IETF Internet draft, work in progress, Jan. 2013.

4. D. Hardt, ed., The OAuth 2.0 Authorization Framework,

IETF RFC 6749, Oct. 2012; http://tools.ietf.org/html/

rfc6749.

5. J. Callas et al., eds., OpenPGP Message Format, IETF

RFC 4880, May 2014; http://tools.ietf.org/html/rfc4880.

6. L. Li et al., “Mirror Presence: Secure Web Identity Res-

olution and Call Control for WebRTC,” Proc. 15th Int’l

Conf. Information Integration and Web-based Applica-

tions & Services, 2013, pp. 523–531.

Li Li is a principal engineer at Huawei Shannon (IT) Lab

in Bridgewater, New Jersey. His research interests

include service computing and real-time communica-

tion. Li received a PhD in computer science from the

University of Alabama at Birmingham. He is a member

of IEEE and ACM. Contact him at [email protected].

Wu Chou is vice-president, chief IT scientist, and head of

Huawei Shannon (IT) Lab in Bridgewater, New Jersey.

His research interests include IT, cloud computing, net-

working, Internet computing, big data, and software-

defined networks. Chou received a PhD in electrical

engineering from Stanford University, and he is an

IEEE Fellow. Contact him at [email protected].

Zhihong Qiu is a research scientist at Huawei Shannon (IT)

Lab in Shenzhen, China. His research interests include

future Web and Internet technologies and big data ana-

lytics. Contact him at [email protected].

Tao Cai is a research scientist at Huawei Shannon (IT) Lab in

Shenzhen, China. His research interests include service

computing, WebRTC, HTML5, software-defined networks,

Web browsers, and distributed systems. Cai received an

MS in applied mathematics from the Beijing Institute of

Technology. Contact him at [email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

2014_who is calling which page on the web

Documents