idnits 2.17.1 draft-copeland-rtcweb-p2p-idp-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 26, 2016) is 2762 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4949' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'JeffSayreHenryStory' is defined on line 1210, but no explicit reference was found in the text == Unused Reference: 'WebRTC' is defined on line 1230, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Copeland, Ed. 3 Internet-Draft Institut Mines Telecom-Telecom Sud Paris 4 Intended status: Informational K. Corre 5 Expires: March 30, 2017 Orange Labs 6 I. Friese 7 Deutsche Telekom AG 8 S. El Jaouhari 9 Institut Mines Telecom-Telecom Bretagne 10 September 26, 2016 12 Requirements for Trust and Privacy in WebRTC Peer-to-peer Authentication 13 draft-copeland-rtcweb-p2p-idp-auth-00 15 Abstract 17 This document studies the relationships of WebRTC communication users 18 with their web Calling Services (CS) and their Identity Providers 19 (IdPs), in order to identify requirements for IdP based peer-to-peer 20 authentication. This study focuses in particular on issues of 21 privacy, security and trust that are raised by the introduction of 22 the IdP into the WebRTC call model, and by a different browser-based 23 calling paradigm, compared with Mobile networks or traditional VoIP 24 systems. The document lists privacy and trust scenarios for WebRTC 25 authentication for individuals as well as organizations. This 26 contribution is proposed to the RTCWEB working group. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 30, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Call Context Aspects . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Existing Protocols and Drafts . . . . . . . . . . . . . . 6 66 3.2. WebRTC Architecture Components . . . . . . . . . . . . . 7 67 3.3. WebRTC Call Models . . . . . . . . . . . . . . . . . . . 7 68 3.3.1. Single-CS Call Model . . . . . . . . . . . . . . . . 7 69 3.3.2. Dual-CS Call Model . . . . . . . . . . . . . . . . . 7 70 3.4. Service Types and their Trust Models . . . . . . . . . . 9 71 3.5. Destination Categories . . . . . . . . . . . . . . . . . 10 72 4. Architecture Vulnerabilities . . . . . . . . . . . . . . . . 10 73 4.1. Untrusted Parties . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Network Messages Across Multiple Parties . . . . . . . . 10 75 4.3. Confidentiality of Call Logs . . . . . . . . . . . . . . 11 76 4.4. Dependency of Identifiers . . . . . . . . . . . . . . . . 12 77 4.5. IdP Selection Issues . . . . . . . . . . . . . . . . . . 12 78 5. Identity Privacy . . . . . . . . . . . . . . . . . . . . . . 12 79 5.1. Desirable and Undesirable Identity Privacy . . . . . . . 13 80 5.2. Undetectable Calling . . . . . . . . . . . . . . . . . . 13 81 5.3. Pseudonymous Calling . . . . . . . . . . . . . . . . . . 13 82 5.4. Unlinkable Calling . . . . . . . . . . . . . . . . . . . 14 83 5.5. Potential Methods of Identity Protection . . . . . . . . 14 84 5.5.1. Sensitive User Information . . . . . . . . . . . . . 14 85 5.5.2. Proposed Surrogated identities with Pseudonyms . . . 14 86 6. Trust Relationships . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. Three-Way Trust: User-CSP-IdP . . . . . . . . . . . . . . 15 88 6.2. Choice Indicates Trust . . . . . . . . . . . . . . . . . 16 89 6.3. User trust in Calling Services . . . . . . . . . . . . . 16 90 6.4. User trust in Identity Providers . . . . . . . . . . . . 17 91 6.5. Communication Service trust in Identity Providers . . . . 17 92 6.6. Trusted Identities for non-Browser Interworking . . . . . 18 94 7. Use Cases for Privacy Requirements . . . . . . . . . . . . . 18 95 7.1. Anonymous Caller Connecting to Call-Centers . . . . . . . 18 96 7.2. Call Center Worker's Privacy . . . . . . . . . . . . . . 19 97 7.3. Online Gaming Calling by Pseudonyms . . . . . . . . . . . 19 98 7.4. Hosted Enterprise WebRTC Conferencing Service . . . . . . 20 99 7.5. Variable Trust modes for Employee's Calls . . . . . . . . 20 100 7.6. Employee using untrusted WebRTC service . . . . . . . . . 20 101 7.7. WebRTC service Interworking with SIP users . . . . . . . 21 102 8. Requirements Summary . . . . . . . . . . . . . . . . . . . . 21 103 8.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 21 104 8.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 22 105 8.3. Independent IdP . . . . . . . . . . . . . . . . . . . . . 22 106 8.4. User Information Confidentiality . . . . . . . . . . . . 23 107 8.5. Calling Services . . . . . . . . . . . . . . . . . . . . 23 108 8.6. Usability and Notification . . . . . . . . . . . . . . . 23 109 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 12.1. Normative references . . . . . . . . . . . . . . . . . . 25 114 12.2. Informative references . . . . . . . . . . . . . . . . . 26 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 117 1. Introduction 119 This study provides requirements for supporting identity privacy in 120 peer-to-peer (P2P) WebRTC calling services. While the WebRTC 121 specification aims to manage the media flow, it does not include 122 procedures for call initiation and privacy setting. However, WebRTC 123 architecture supports peer authentication that is performed 124 separately from the calling service, decoupling user authentication 125 from the granting of service resources. The authentication is 126 performed by a third party Identity Provider (IdP), while service 127 resources are granted by each Calling Services Provider (CSP). 129 WebRTC calling creates a different paradigm from 'traditional' VoIP 130 services or Telecom, because it is browser-based. All that is needed 131 for a website to support WebRTC calling is to download a client to 132 the device to access the user-agent JavaScript APIs. This simplicity 133 will encourage many websites to add calling facilities to their 134 'shop-window'. In turn, such easy click-to-link services will entice 135 occasional website visitors to initiate 'opportunistic' calls, often 136 using unknown, maybe untrusted calling services, giving little 137 thought to the risk of leaking personal information. Hence, this 138 paradigm increases risks of abuse of user data, identity theft and 139 commercial exploitation. This necessitates establishing appropriate 140 privacy protection, even without user explicit input of preferences. 141 It is possible to achieve this by attaching privacy rules to the 142 IdP's maintained user identity, so that the IdP will support 143 anonymity where required. 145 An independent identity should prevent the undesirable lock-in effect 146 of 'service-bound' identities and allow for a single identity, with 147 its linked pseudonyms identifiers (with same credentials), to be used 148 instead of numerous identifiers and separate passwords. Users should 149 be able to specify particular privacy rules that are applied during 150 authentication across all services, or for a particular service type, 151 since the privacy rules are attached to the identifier, not to the 152 service. 154 The current peer authentication procedure provides some flexibility 155 for the choice of IdP, but does not allow users to determine privacy 156 requirements for different circumstances. There are no means of 157 evaluating trust models and required privacy between calling parties, 158 their CSs and IdPs. The call model (single or dual CS model) affects 159 the level of trust in the other parties. Users may trust their 160 chosen IdPs and CS, but the same cannot be assumed for CS and IdPs of 161 their communication partners. The service type and the means of 162 activating it also influence the trust level, e.g. a social media 163 contact may be more trusted than a call to an unknown website. 164 Similarly, the type of destination (e.g. public organizations versus 165 unfamiliar websites) also impacts the trust level. Such destinations 166 have their own privacy requirements that need to be negotiated, e.g. 167 callers' traceability may be mandated in order to avoid nuisance 168 calls, but at the same time, unlinkability is required for employees 169 when they respond to public enquiries. 171 The accumulated record of calls is a precious commodity in the 172 monetized web space, but many users wish to exercise better control 173 of what is divulged. To solve this, it is argued that by using 174 context-based privacy to obscure certain details or to present 175 surrogate identities, the calling service logs will contain only 176 filtered information, in accordance with users' wishes. 178 Hence, this study proposes requirements for user-controlled, multi- 179 purpose, identity, with service-independent authentication by IdPs, 180 which is protected not only by preferences and negotiated privacy 181 rules, but also by detected context-based privacy settings. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119] 188 Privacy and data minimization terms, such as Anonymity, 189 Unlinkability, Undetectability, and Pseudonymity, follow the 190 definitions by Pfitzmann et al. [TerminologyForPrivacy], but refer 191 to inter-party interactions, not user-to-server, where the 'sender' 192 (Caller) and the Destination (called party) are separate entities 193 from their own services and endpoint clients. Table 1 contains 194 further terms that convey a particular meaning or an extension 195 meaning in this document. 197 Terms Definitions 199 +----------------+--------------------------------------------------+ 200 | Term | Description | 201 +----------------+--------------------------------------------------+ 202 | Called-party, | A target destination, as nominated by the | 203 | Destination or | caller, who is an individual called party, an | 204 | Callee | organization representative or an intelligent | 205 | | object, with a WebRTC valid identity. | 206 | Caller or | An individual, an organization representative or | 207 | Sender | an intelligent object with a valid identity who | 208 | | is initiating a WebRTC call or session by using | 209 | | a WebRTC-enabled browser. | 210 | Calling | The WebRTC based service that is used to connect | 211 | Service (CS) | calling parties. This service may provide | 212 | | calling features and group calling management, | 213 | | as well as users' preferences and group privacy | 214 | | policies. A CS is assumed to be server-side | 215 | | software from a CS Provider, with clients | 216 | | downloaded to the users' endpoints. | 217 | IdP (Identity | IdP (Identity Provider) creates, maintains, and | 218 | provider) | manages identity information for entities | 219 | | (users, services, or systems) and provides | 220 | | authentication to other service providers. It | 221 | | is a trusted third party that can be relied upon | 222 | | by users and servers when they establish a | 223 | | dialog that must be authenticated. | 224 | IdP Proxy | A client (user agent) constructed by each IdP | 225 | | for its own operation, and is downloaded to | 226 | | users' endpoints when they wish to verify a | 227 | | given 'assertion' for a user. | 228 | Unlinkability | While the definition in [TerminologyForPrivacy] | 229 | or | refers to unlinkability of subject to a message | 230 | Untraceability | or a particular attribute, in this document it | 231 | | is defined as the inability to link calling | 232 | | parties to their routable address for calling | 233 | | back. | 234 | Privacy Rules | Rules containing parameters for service delivery | 235 | | that are compiled from preferences of the | 236 | | involved individuals, groups, or institutions, | 237 | | to determine when, how, and to what extent | 238 | | information is divulged. | 239 | Surrogated | Identities that identify a real person uniquely | 240 | Identities | through their association with a universal | 241 | | unique surrogate key (a database indexing key | 242 | | that is system-generated as an artificial | 243 | | primary key value, independent of any | 244 | | attribute). Such identities need not have their | 245 | | own credentials, and can use either meaningful | 246 | | pseudonyms or meaningless (anonymous) | 247 | | identifiers. | 248 +----------------+--------------------------------------------------+ 250 Table 1 252 3. Call Context Aspects 254 This section describes the dependency of privacy settings on the call 255 model (single/dual CS), service type and destination category, in the 256 light of the P2P authentication procedure. 258 3.1. Existing Protocols and Drafts 260 WebRTC calls connect two browsers that are exchanging media and data, 261 as presented in the "WebRTC Overview" [I-D.ietf-rtcweb-overview]. 262 Prior to the media connection, the calling parties may authenticate 263 each other, in a possibly reciprocal peer-to-peer authentication 264 process, as described in "WebRTC Security Architecture" 265 [I-D.ietf-rtcweb-security-arch]. 267 The RFC "Privacy Considerations for Internet Protocols" [RFC6973] 268 offers guidance for privacy considerations in Internet protocols. 269 This RFC identifies privacy threats and threat mitigation solutions 270 which includes data minimization. 272 The Internet draft "Security Considerations" 273 [I-D.ietf-rtcweb-security] for WebRTC identifies two threats to 274 privacy in WebRTC. These are the correlation of anonymous calls 275 through persistent identifiers such as DTLS certificates, or the risk 276 of browser fingerprinting through the WebRTC API itself. 278 Examples of WebRTC binding to specific identity protocols are given 279 in "WebRTC Security Architecture", such as OAuth 2.0 [RFC6749] (or 280 OpenID Connect [OIDC] ). However, these protocols do not address 281 privacy and identity management for peer-to-peer authentication. 283 3.2. WebRTC Architecture Components 285 Current WebRTC communications rely on standard browser APIs 286 (getUserMedia) that execute at both endpoints to enable media 287 streaming, and WebRTC APIs (RTCPeerConnection and RTCDatachannel) 288 that execute at the endpoints to manage the flow. The endpoints also 289 execute a CS client, which drives the initial call setup. 291 To enable decoupling of the CS from the identity authentication 292 process, WebRTC security architecture [I-D.ietf-rtcweb-security-arch] 293 proposes that the WebRTC PeerConnection component interacts directly 294 with the IdP, to initiate and manage the authentication process. It 295 negotiates Session Description Protocol (SDP) with the other party by 296 sending an SDP offer and accepting, rejecting or offering a counter 297 offer. 299 Both parties set up their own PeerConnection instances and download 300 an IdP proxy from their own IdP. Each IdP authenticates its user's 301 and returns an identity assertion containing the identity and session 302 key fingerprint as claims. When a party receives an SDP offer or 303 answer containing an identity assertion, that party also downloads 304 the IdP proxy from the other party's IdP. This proxy is then used to 305 verify the received identity assertion. Each IdP Proxy only connects 306 to its own IdP server. This architecture is presented in Figure 1. 308 3.3. WebRTC Call Models 310 3.3.1. Single-CS Call Model 312 In a single-CS model, which is the dominant model in the current 313 Internet Voice services, only one calling service is involved, where 314 both the caller and the called party are registered to the same 315 service. The service manages the subscribing users' privacy policy 316 via a set of options, which are then reconciled for the call. These 317 services utilize 'service-bound' identities, where users must log on 318 with the service-specific credentials. By contrast, the WebRTC 319 Single-CS call model permits users to select their own identities, 320 and perform user-to-user mutual authentication, even though both 321 users are logged on to the same service. 323 3.3.2. Dual-CS Call Model 325 While early implementations of WebRTC calling between individuals go 326 no further than the single-CS model, it is expected that the dual-CS 327 model will become more common if WebRTC services are adopted in 328 business, especially for small-to-medium enterprises. In dual-CS 329 model, the calling parties log on to two different CSs, with their 330 own sets of privacy rules and security policies, so CSs must discover 331 the respective privacy/security requirements and negotiate an 332 acceptable set of rules for both parties per session. 334 Figure 1 shows the calling parties (A and B) using different services 335 (CS-A and CS-B) and different IdPs (IdP-1 and IdP-2). It shows the 336 mutual P2P authentication that is performed by each side 337 symmetrically. A gets its own identity assertion from IdP-1 and 338 verifies B via a downloaded IdP-2 proxy. B gets its own assertion 339 from IdP-2 and verifies A by the downloaded IdP-1 proxy. Each proxy 340 runs in its own sandbox to protect it from interference. The 341 mechanism for interaction between calling Services can be, for 342 example, SIP or XMPP. 344 +----------+ +----------+ 345 | Caller's |Unspecified| Called | 346 +----------+ | Service | Protocol | Service | +----------+ 347 | IdP-1 | | CS-A |<--------->| CS-B | | IdP-2 | 348 | | | (caller) |(SIP, | (callee) | | | 349 +-v------^-+ +-----^----+ XMPP,...)+-------^--+ +--^-----v-+ 350 | | / \ | | 351 | | / \ | | 352 | | / \ | | 353 | +----|----------------+ +-----------------|---+ | 354 | | | | Media | | | | 355 | | | Browser A |<----------->| Browser B | | | 356 | | +-------+ +-------+ | | +-------+ +-------+ | | 357 | | | IdP-1 | | IdP-2 | | | | IdP-1 | | IdP-2 | | | 358 | | | Proxy | | Proxy | | | | Proxy | | Proxy | | | 359 | | |sandbox| |sandbox| | | |sandbox| |sandbox| | | 360 | | +-------+ +---^---+ | | +----^--+ +-------+ | | 361 | +---------------|-----+ +------|--------------+ | 362 | | | | 363 | | | | 364 +-----------------|--------------------------+ | 365 B verifies A | | 366 +-------------------------------------------+ 367 A Verifies B 369 Figure 1: Dual CS Calling Model 371 Calling parties may connect to unknown parties who are using 372 unfamiliar services across the globe, and are authenticated by IdPs 373 that the caller may not know or even be aware of. In such cases, 374 many users would prefer to prevent unnecessary data disclosure. 376 3.4. Service Types and their Trust Models 378 In order to understand the privacy requirements for WebRTC 379 architecture, it is important to classify calling services by the 380 manner of initiating the sessions, choosing destinations (called 381 parties), and consulting the other party CS. The following is a 382 classification of web calling service types that may have varying 383 privacy requirements, due to different trust models: 385 a. Contact-List-Service: The service enables users to maintain their 386 contact list, and make or receive calls from them. This service 387 type is used by social media, VoIP OTT, and internal enterprise 388 call servers. 390 b. Click-to-Link Service: Browsing users activate this service type 391 when they click on a website link to talk to anyone at that 392 destination, not to an individual person. The 'linked' party in 393 the visited website uses its own CS in a single-CS call model. 394 This service type is common for shopping websites and customers' 395 enquiries, which today are mostly chat services only. The caller 396 may not trust such services, and users often wish for anonymity 397 to be preserved. On the other hand, unlinkability is often 398 required for the responding individuals at the website. 400 c. Negotiated Service: This type of service, which is common for 401 business-to-business, allows both calling parties to have their 402 own privacy rules. In a single-CS call model, the service 403 reconciles the differences, but in a dual-CS call model, the 404 calling services should conduct a dialogue resulting in 405 negotiated privacy rules per call. 407 d. Interworking Service: WebRTC calling services should enable 408 connecting to other types of services, using temporary or 409 'interworking' special identities. This service type is used, 410 for example, for interworking with SIP servers and telephony. 411 Although users cannot authenticate each other, the interworking 412 depends on one-sided IdP authentication. 414 e. Conferencing Multi-Party Service: Services that connect several 415 parties in one call need different mechanisms to mix the media, 416 such as a bridge, router/mixer or a matrix, but they also need to 417 reconcile privacy needs of several parties. This is often a 418 single-CS service between subscribing participants, but it may 419 also support multiple calling services, where each call leg is 420 managed by the caller's own CS. Peer authentication could still 421 be performed between the conferencing shared identity and each 422 participant. 424 These service types influence the required privacy, since they are 425 correlated to particular trust models, e.g. contact-List calling 426 permits full information exchange, but Clink-to-Link sets the 427 strictest privacy level. 429 3.5. Destination Categories 431 The destination category influences the level of security and privacy 432 that the calling parties require. The destination may be an 433 untrusted web site in click-to-link service type that users prefer to 434 connect while preserving anonymity and/or unlinkability, but such a 435 destination may also be a completely trusted, often used website. 436 Businesses often wish to apply different confidentiality rules for 437 internal or external calls, i.e. distinguishing between classes of 438 destinations. Hence, privacy rules should be determined per 439 destination category, by: the addressing mode (click-to-link or 440 contact list); the domain (government etc.); or previously logged 441 calls. In the absence of explicit user preference, context-based 442 privacy level can be set by the CS according to the destination 443 category. The IdP can also perform such a service, based on the call 444 log and the target domain names. 446 4. Architecture Vulnerabilities 448 This section considers the new paradigm that webRTC creates, which 449 gives rise to different trust models between the parties and other 450 stakeholders. 452 4.1. Untrusted Parties 454 The decoupling of the authentication from the service logic, both in 455 networked functions and in business entities, increases 456 vulnerability, but also the variety of trust models that are needed 457 to support permissive and intuitive web calling patterns. This 458 environment encourages users to take more risks and launch 459 interactions without careful considerations of the information that 460 may leak to various parties. In additions, not only a casually 461 invoked service may receive user data, but also the IdP and the CS of 462 the other party, who may not be trusted. 464 4.2. Network Messages Across Multiple Parties 466 WebRTC architecture relies on the IdP to perform the authentication 467 independently from the call initiation process. This entails further 468 network based interactions and more parties gaining knowledge of 469 them. The additional network messaging between more parties increase 470 the risk of Man-in-the-Middle (MITM) attacks. The number of involved 471 parties in person-to-person calls rises in peer authentication, 472 depending on the call model. A single-CS call model with service- 473 bound identification involves only one CS with two parties. In the 474 dual-CS call model with independent IdPs, there are two calling 475 parties, two service providers and two IdPs, i.e. double the number 476 of involved parties. This increases the risk of leaking information 477 and abuse of call history, as well as MitM attacks. 479 4.3. Confidentiality of Call Logs 481 Currently, both IdPs and calling services acquire user knowledge, 482 which is a) contextual; b) historical; and c) subscription-based. 483 This information can be static (user personal details, additional 484 email identities) or dynamic (calling patterns, frequent 485 destinations, preferred services/websites, and more). Every time a 486 new call is set up, the exchanged information can provide means of 487 tracking user activity or linking back to the parties. The 488 accumulation of such information reveals trends, habits, preferences 489 and behavior patterns that are highly valuable to traders and 490 marketeers. Exploiting this data is often the only monetization 491 methods available to web service providers, but it is a cause for 492 concern for users who regard it as compromised privacy. 494 The IdP gains knowledge of personal details (to enhance user 495 profile), and associated identities (to enhance identity resilience), 496 which users may be reluctant to share with numerous websites. In 497 addition, the IdP can log authentication requests of every CS using 498 its identity service, while the CS only has visibility of calls made 499 to and from that service. Since users' calling activities are now 500 spread over a number of web communications services, an IdP will have 501 wider perspective on the user's intelligence. 503 IdP is not able to know much about the involved CS, as the Peer- 504 Connection method interfaces between the endpoint's client and the 505 IdP Proxy directly, not via a CSP server. On the other hand, the CS 506 has better understanding of the call context in the preamble before 507 initiating a call request. 509 As the IdP Proxies are deployed on both calling parties'devices, the 510 IdPs can log identity verification requests for incoming as well as 511 outgoing calls. It may be possible for an IdP to track call history 512 for a particular destination user who is using another IdP, even if 513 an pseudonymous identity is given, and perhaps eventually link the 514 records with the real identity. However, this risk only arises with 515 habitual pseudonymous calling to the same destination. 517 4.4. Dependency of Identifiers 519 The aim of providing completely independent and portable identities 520 is not easy to achieve. While the IdP-generated identity (with an 521 IdP domain) is not related to any specific calling service, i.e. 522 portable between services, it is still dependent on the IdP. If 523 users wish to keep their well-known published identifiers when moving 524 to another IdP, they need identities that ensure both CS and IdP 525 independence. This requires users to use a global user identifier, 526 such as a Universally Unique Identifier (UUID) [RFC4122] that would 527 acts as a unifying key for all identities. This globally unique 528 identifier could link several identifiers, both IdP-generated and CS- 529 generated. 531 4.5. IdP Selection Issues 533 In WebRTC, each CS client in the device is responsible for setting up 534 the authentication requests for its own party. The CS client decides 535 what form of authentication to apply, i.e. peer authentication, 536 server-side Single Sign-On, or service-specific authentication. This 537 means that the CS controls the selection process, and may restrict 538 the choices of IdP to choose from, or even prevent an IdP to be 539 involved. 541 Current WebRTC specifications define two options for the CS to select 542 an IdP for an identity assertion request: 544 o If the setIdentityProvider() method has been called by the CS, the 545 provided IdP will be used. 547 o If the setIdentityProvider() method has NOT been called, the 548 browser may use a pre-configured IdP. 550 Pre-configuring an IdP via the browser means that yet another party - 551 the browser vendor - is a stakeholder in the WebRTC call initiation. 552 It is argued that currently, users do not have sufficient control on 553 the selection of the IdP with these facilities. 555 5. Identity Privacy 557 This section sheds a new light on the privacy requirements for 558 undetectable, pseudonymous, and unlinkable callers that arise from 559 the webRTC peer calling. Although these terms do exist, the 560 associated privacy requirements have not been previously identified. 562 5.1. Desirable and Undesirable Identity Privacy 564 Many websites may be content to receive enquiries from anonymous 565 callers, because this may generate impulse-buying, so they only 566 request user details before completing a transaction. Such websites 567 also require some privacy rules themselves, to protect specific 568 personnel serving at a call center. Web calling encourages 569 opportunistic calling by users who are merely visiting the websites, 570 where users identities are 'incognito', i.e. their status is 571 'undetectable' or 'unobservable'. In certain circumstances, calls 572 from undetectable identities should always be supported, e.g. calls 573 to emergency services that are passed through without any 574 authentication. While undetectable status is passive, in other cases 575 callers may specifically wish to withhold their personal details for 576 a variety of legitimate reasons, e.g. to avoid revealing interests in 577 sensitive material or avoid personal embarrassment. In such cases, 578 users can choose to use assumed names (pseudonyms). Similarly, there 579 are good reasons to support the requirement of unlinkability that 580 prevents tracing back previous calls, e.g. to avoid traders chasing 581 business. 583 The contrasting requirements to prevent anonymity should also be 584 considered, in order to prevent abuse, e.g. for nuisance calls or 585 malicious disruption of service. The solution to block all callers 586 who are not on the personal contact list may suffice for individual 587 users, but this is too restrictive for a business. 589 Therefore, since privacy protection is both desirable and undesirable 590 depending on context and point of view, privacy rules need finer 591 granularity, so that they can be applied judiciously, according to 592 context and circumstances. Hence, the requirements are for WebRTC 593 authentication to support different states of user privacy and 594 anonymity: Undetectable (undisclosed identity), Pseudonymous (false 595 or fictitious identity) or unlinkable (untraceable address/path). 597 5.2. Undetectable Calling 599 Undetectable calling may be initiated without logging to any CS, 600 while the user is unknown. When a call is made without logging to 601 the CS, a call request may be processed without any authentication. 603 5.3. Pseudonymous Calling 605 Pseudonymous calling means that the username identifier is replaced 606 with an assumed name that hides the user's identity. The 607 authentication can be performed by an IdP who is aware of the 608 pseudonym owner. Hence, the other parties can be reassured that the 609 identity is verified. Such authentication may not be sufficient for 610 monetized transaction and non-repudiation, but is considered 611 acceptable for web calling. 613 5.4. Unlinkable Calling 615 Unlinkability prevents other parties from calling back, or from 616 tracing the user's cyber activities, such as visited websites and 617 calling patterns. Unlinkable callers seek to hide the originating 618 website or redirected services. Unlinkability is also both desirable 619 and undesirable, depending on the context. Preventing linkability is 620 often needed to protect individual employees who respond to enquiries 621 from the public. Conversely, linkability is highly desirable by 622 emergency and health services, to locate incapacitated callers in 623 distress. 625 5.5. Potential Methods of Identity Protection 627 5.5.1. Sensitive User Information 629 User information that may be subject to privacy includes: 631 o Forename and last names, which are often incorporated in the 632 username part of the identifier. 634 o Domain name of associated organization, which often incorporates 635 the organization name in the @domain part. 637 o Message path and IP address, which are revealed in the SDP 638 (Session Description Protocol). 640 5.5.2. Proposed Surrogated identities with Pseudonyms 642 Using pseudonyms avoids undesirable disclosure of the identity and/or 643 incidental private information. However, pseudonyms should still be 644 associated by a common key to the real user. This is achieved by a 645 fully independent identifier that acts as a 'surrogate' key, i.e. an 646 indexing key that is not based on any meaningful personal details, as 647 described in [SurrogateKeys] for indexing data. Such surrogate keys 648 provide stability, because they are not affected by users changing 649 circumstances (e.g. married names) and personal attributes (e.g. 650 changing employer domain name). 652 The surrogate key for identities is a Global User ID (GUID) that 653 uniquely identifies a particular user. GUIDs can be generated by a 654 number of known algorithms. They may inject user-specific variable 655 attributes as 'salt' to the otherwise random number generator, to 656 ensure uniqueness. It is proposed that this GUID/surrogate key will 657 link the IdP-based identity, service-bound identities and pseudonym 658 identities, at the discretion of the user. All the linked identities 659 (i.e. the 'surrogate identities') can share the same credentials that 660 the IdP has verified. Service-bound identities from a variety of 661 calling services that do have their own credentials (usually just 662 passwords) can also link to the surrogate key, thus benefiting from 663 deeper user verification and from the SSO effect that such 664 arrangement brings. 666 6. Trust Relationships 668 This section analyzes discernible trust models which are proposed as 669 the basis of setting up appropriate privacy levels. 671 6.1. Three-Way Trust: User-CSP-IdP 673 The current WebRTC security architecture only assumes that users 674 trust their CSP, or that an IdP is used in P2P authentication if the 675 CS is untrusted. Trust in the IdP is only considered regarding its 676 verified, https origin. In this model, the browser constitutes the 677 trust anchor. However, this simple trust model does not describe 678 trust in the privacy context, nor the difference between a user's own 679 IdP and the other IdP. 681 Users need to trust other involved actors, i.e. CSs and IdPs, to 682 manage their privacy and provide solid identity claims. The CS in 683 turn may need to trust both IdPs regarding user authentication and 684 identity claims. However, IdPs do not require particular trust 685 relations with the CS, as they merely provide a service, without risk 686 to themselves. Figure 2 and subsequent sections details this trust 687 model. 689 +---------+ 690 +-------------------> CSP | 691 | +---------+ 692 +---------+ | 693 | Alice | | 694 +---------+ +-------+ 695 | | | | 696 | | +-------v-+ +--v------+ 697 | +------------> IdP A | | IdP B | 698 | +---------+ +-^-------+ 699 | | 700 +------------------------------+ 702 Figure 2: Trust relationships between communication setup actors 704 6.2. Choice Indicates Trust 706 The purpose of establishing trust is to make a decision in situations 707 where an action with an inherent risk depends on informed judgement. 708 Explicit choice can be interpreted as a measure of trust. Users' 709 chosen IdPs are more trusted than mandated IdPs imposed by the 710 communication services, though enterprise mandated IdPs are trusted 711 by virtue of the enterprise selection. Similarly, calling services 712 that are casually invoked by click-to-Link in a visited website are 713 less trustworthy than those which the user has registered to. 715 Trust is also assumed towards a call-party that is known to the user, 716 but there is no implied trust level for the calling services and IdPs 717 of that party. Trust may be associated with the type of the call 718 destination, which can be categorized as: 720 o Fully trusted parties (government, public organization, known 721 business) 723 o Inner-circle of a social network or family members 725 o Uncertain (not-in-contact-list, no information) 727 o Untrusted (known as unreliable). 729 6.3. User trust in Calling Services 731 Traditionally, CSP had access to full user profile information and 732 accumulated call history, but user habits now favor using different 733 services according to context, so the CS has only their own usage 734 records. While some CS may enjoy greater trust, in other cases, 735 users do not wish to share or even store their call history. These 736 preferences are usually agreed when users register with the CS, but 737 it is up to the CS to respect them. 739 Since the CS manages the call signaling, it is well placed to 740 intercept the peer-to-peer media stream that otherwise is deemed 741 private. Even if the caller's CS can be trusted not to do so, the CS 742 of the other party is not so well trusted. Trust in the CS also 743 varies between single-CS and dual-CS Call Model. In a single-CS call 744 model both parties use the same service to communicate, however this 745 does not guarantee that they have the same trust models and the same 746 privacy requirements. In a dual-CS call model, the other party's CS 747 merits even less trust, as it may not even be known (depending on 748 user-interface implementations). Hence, variable precautions and 749 privacy negotiations are necessary according to the context and the 750 involved parties. In cases where the CS is untrusted, enforcing 751 authentication by an independent IdP ensures that the exchange of 752 media key is on a third-party path (the identity path) between the 753 authenticated users. Therefore, the CS, who is not in control of 754 this path, cannot mount a MitM attack. However, the CS, not the 755 user, determines whether an IdP is to be used, and users have no 756 means of ensuring that they are protected by the IdP authentication. 758 6.4. User trust in Identity Providers 760 The IdP, more than the CS, is the custodian of user intelligence; 761 hence it must have trust relationship with users that subscribe to 762 its services. It is assumed that such services include storing and 763 linking service-bound identities, to allow for flexible means of 764 authentication of related identifiers. Using an IdP makes it easier 765 for users to control privacy, since a single agreement with their 766 chosen IdP is simpler than managing numerous web services, some of 767 which are use only rarely. 769 Users may have more than one IdP, perhaps different IdPs for special 770 purposes, e.g. most commonly, a separate IdP from an employer. They 771 may choose an IdP that they do not fully trust for private activities 772 that they wish to keep separate. In such cases, the user can limit 773 what personal details are disclosed to the IdP, but the IdP will 774 still know of any authentication request to this identity. 776 Trusting the IdP of the other party is a more difficult issue, since 777 this IdP may not be even known. The P2P authentication procedure 778 ensures that the IdP origin is not circumvented, but there are no 779 ways of assessing the strength and veracity of the origin statement. 781 Currently, called users have no way of controlling the downloading of 782 an 'alien' IdP Proxy (of the other party) to their device, since this 783 is performed automatically by the CS client at the behest of the 784 caller. Hence, both IdP proxies are subject to the same sandbox 785 restrictions, although they have different trust models. 787 6.5. Communication Service trust in Identity Providers 789 The CS may rely on a third-party IdP to authenticate users when they 790 log in, and link the given identity with its internal user account. 791 In such cases, the CSP must trust the IdP regarding the 792 authentication strength and the validity of the provided profile 793 information. 795 In most cases, the CSP provides a set of preferred IdPs for users to 796 choose from, through SSO implementations on the website and usage of 797 the setIdentityProvider function. However, users could also select 798 an IdP, e.g. with OIDC discovery. In dual-CS call model, the CS 799 could receive a SDP message containing an assertion from an unknown 800 IdP. The verification of the assertion could be performed using the 801 browser's default IdP, with the CS only receiving a confirmation that 802 the identity is authenticated. In these cases, the CS has only low 803 trust level in the IdP, while IdPs that have been vetted by the CS 804 are higly trusted. 806 6.6. Trusted Identities for non-Browser Interworking 808 WebRTC browser-based calling services may need to communicate with 809 users on non-browser services, including users of existing SIP 810 servers. The interworking should not be only at the level of 811 signaling and applications, but also at the authentication stage. 812 For a mobile network, as specified in 3GPP TS 23.228, mutual 813 authentication is not possible, but the WebRTC identities, which have 814 been authenticated by an IdP or a CS, are linked to the allocated SIP 815 identities. The 3GPP WebRTC-SIP Client at the device enables it to 816 contact the local network proxy. 818 7. Use Cases for Privacy Requirements 820 While [I-D.ietf-rtcweb-use-cases-and-requirements] provides use cases 821 for webRTC media, in this study, use cases demonstrate the calling 822 context scenarios that require different privacy settings, which 823 enhance the examples in [I-D.cazeaux-rtcweb-oauth-identity]. 825 7.1. Anonymous Caller Connecting to Call-Centers 827 Alice is surfing on websites of several insurance or healthcare 828 companies and wants to discuss matters of some sensitivity. She 829 clicks on links within these websites, in order to talk to their 830 experts. Alice is concerned with her privacy and prefers to remain 831 anonymous, especially towards her employer. Some websites treat her 832 identity as undetectable, since she has not logged in to the service, 833 but they allow such callers to visit. For websites that require 834 authentication, she will use a pseudonym and authenticate to her 835 personal IdP, to avoid her employer's IdP becoming aware of which 836 websites she calls. This use case demonstrates a single-CS call 837 model with the 'Link-to-Call' Service type. The privacy requirements 838 demonstrates undetectability, pseudonymity and unlinkability for the 839 caller. The alternative for Alice is to create unrelated identities 840 for each website, but this is much more laborious. Using an 841 independent IdP with surrogate pseudonyms, Alice can rely on the same 842 credentials, while reassuring the destination websites that she is 843 properly authenticated and is not making nuisance calls. 845 7.2. Call Center Worker's Privacy 847 Bob is a member of a company's product support group, working in a 848 customer support center. The company presents clickable icons on the 849 website that connect visitors to the right expert. Bob answers 850 Alice's call, but when Alice calls again, she cannot contact Bob 851 directly, and her call is answered by another group member. This use 852 case represents single-CS Click-to-Link service model from the called 853 destination point of view. Once Alice indicates that she would like 854 to talk, the called destination invokes its own calling service, so 855 the roles are reversed: the destination is the caller and Alice 856 becomes the called party. This enables the destination group members 857 (Bob) to remain unlinkable vis-a-vis Alice. On the other hand, Alice 858 is an undetectable identity, since she has not logged into the 859 service, so her call request uses the browser default IdP to retrieve 860 a surrogate pseudonym identity, but she is still traceable in terms 861 of IP address and path. Hence, this example also shows that 862 unlinkability is not necessarily attached to all other anonymity 863 states, e.g. detectability. 865 7.3. Online Gaming Calling by Pseudonyms 867 Alice is playing poker on a gaming website. Alice is a customer, 868 with an account which the gaming business administrator has verified 869 (e.g. via a credit card). Alice wishes to communicate with other 870 players through a voice channel provided by the gaming facility. She 871 is registered on the gaming site under her chosen pseudonym, which is 872 all she wants to reveal to the other players. The calling service 873 verifies the users and their accounts through a server-side IdP 874 validation, so the identities with their pseudonyms are strictly 875 service-bound. This use case demonstrates single-CS /Contact-List 876 call model, where the calls are placed between two registered and 877 logged-on users of the same service. The model is the same as 878 traditional OTT VoIP, where the CS manages the users' identities. 879 Callers and called-parties implicitly rely on the calling service to 880 provide anonymity, where the anonymity set is determined by the 881 number of players. 883 It should be possible for the gaming CS to permit P2P authentication 884 and independent IdPs, but the gaming host may still require 885 authorization of user accounts (if money changes hands). The IdP 886 authentication benefits the CS, since the IdP's identification is 887 coupled with deeper user verification. 889 7.4. Hosted Enterprise WebRTC Conferencing Service 891 Alice is working for a corporation that provides her with a 892 comprehensive web-based communication suite of internal and external 893 conferencing, which is hosted by a Service Provider. The 894 conferencing Service Provider uses the mandatory corporate IdP to 895 authenticate the employees. Alice calls Bob, who works for a 896 partnering company, and is logged on to his own company's CS. Alice 897 uses Bob's identity from his own CS, which is recorded in her contact 898 list. Although Alice's company does not insist on confidentiality, 899 Bob's company does, so Bob's calling service demands that all the 900 conferencing participants use the security level that matches Bob's. 901 This use case demonstrates dual-CS negotiated call model, where the 902 parties have their own preferences determined by their respective 903 organizations. The service providers need to agree on a common set 904 of privacy rules. Although an IdP is mandated by Alice's 905 organization, external calling parties may not have the same IdP, 906 hence external callers should be authenticated in the mutual peer-to- 907 peer authentication process. 909 7.5. Variable Trust modes for Employee's Calls 911 Employees can have different requirements of privacy depending on 912 type of calls and types of destinations. Alice is a Sales 913 representative calling Bob (a potential customer), to conduct a 914 consumer survey and she wishes to remain untraceable (unlinkable) and 915 unrecognised (pseudonymous). However, when she calls her colleague, 916 Charlie, to discuss invoices, she would like Charlie to call her 917 back. Thus, Alice needs unlinkability when calling Bob, but full 918 linkability when calling Charlie. This use case shows privacy 919 decision by context, according to destination type. Rules may be 920 defined per class of destinations (e.g. internal-colleague, external- 921 corporate, or external-personal). The privacy rules may be executed 922 by the IdP, but other rules may be executed by the CS, hence 923 discrepancies may occur, for example, when the destination-based 924 privacy rule conflicts with corporate policies for this customer. 925 Hence, this example also shows the need for privacy policy 926 negotiation and reconciliation. 928 7.6. Employee using untrusted WebRTC service 930 Alice is an employee making use of a WebRTC service that she 931 considers to be untrusted, in order to communicate some important 932 messages to Bob, while she is out of the office. Alice registers to 933 an untrusted CS with her corporate identity. Bob can 'discover' 934 Alice's address when he logs into the same untrusted service, because 935 her corporate identity was linked with the CS service-bound identity, 936 when she registered. This use case is an example of single-CS call 937 model, using an untrusted calling service in combination with a 938 trusted IdP. Mutual peer authentication can take place, with each 939 party authenticating the CS based identity via surrogate or explicit 940 corporate identities. Alice wants to be sure that her trusted 941 corporate IdP is used, in order to minimize risks of an MitM attack 942 by the CS, and ensure that the media flow is confidential. 943 Currently, the decision to use an IdP, or a particular user-chosen 944 IdP, is in the hands of the CS, so the possible attacker is 945 responsible for setting the protection! Hence, it is very important 946 that users gain the power to proactively protect their communication 947 by opting to use IdP authentication. 949 7.7. WebRTC service Interworking with SIP users 951 Alice uses a social media website to connect to her friends, and her 952 contact list includes people with mobile numbers only. Alice can 953 initiate and receive web calls from her mobile, to connect with 954 mobile phones. Users receiving calls from Alice will see Alice's 955 phone number displayed, or her IdP identity. Alice can also call 956 Bob's mobile number from her laptop using a social media service. To 957 connect to Bob, Alice is authenticated by her social media service 958 provider (her CS), who also provides her with a SIP identity that is 959 linked to her other identities. Her SIP identity [RFC3261] is 960 authenticated by the mobile service provider, who had provided a pool 961 of SIP identities to the social media calling service. This use case 962 demonstrates dual-CS Call Model with the interworking service type, 963 using server-side authentication. 965 8. Requirements Summary 967 This section lists the new requirements, as discussed above. These 968 requirements call for greater user's autonomy, greater transparency, 969 and greater variety of trust models that affect the level of divulged 970 information. 972 8.1. Anonymity 974 1. It should be possible to set different anonymity rules by 975 standard service types, call models and destination categories. 977 2. Personal information must not leak via identity assertions. 979 3. IdP should facilitate pseudonimity via surrogate linked 980 identities. 982 8.2. Unlinkability 984 1. It should be possible to set different unlinkability rules by 985 standard service types, call models and destination categories. 987 2. Callers should be able to request and enforce unlinkability with 988 respect of a called party, separately from other anonymity 989 states. 991 3. Called destinations should be able to refuse unlinkability 992 requests (e.g. to avoid nuisance calls), while respecting 993 pseudonimity. 995 4. Unlinkability (e.g. via "origin" in the SDP) should be subject to 996 pre-defined policy, whether that policy is CS-based or IdP-based. 997 Currently, such policies are not transparent to users. 999 5. Non-disclosure of organization domains is a type of 1000 unlinkability, as well as anonymity. 1002 8.3. Independent IdP 1004 1. Users should be able to choose an IdP independently from any 1005 calling service, though some services will still mandate or 1006 restrict the choice of IdP. In particular, authentication by a 1007 trusted IdP must be an option for users who activate untrusted 1008 services. 1010 2. IdPs must not lock-in users through non-portable identifiers. 1012 3. Users should be able to create and link surrogate identities and 1013 pseudonyms to a globally unique identifier that is portable 1014 between IdPs. 1016 4. Users should be able to associate service-bound identities with 1017 their independent identity (albeit with distinctive assertion 1018 tokens), thus achieving Single-Sign-On. 1020 5. Browsers should allow users to set their chosen default IdPs and 1021 log in on browser start-up. Currently browsers select their own 1022 factory-set IdPs. 1024 6. User-chosen IdPs should be able to prompt users to log in. 1025 Currently, IdP proxies cannot open a dialogue with the user. 1027 7. Users should be able to set IdP-based privacy rules for untrusted 1028 CS. 1030 8.4. User Information Confidentiality 1032 1. Linked identifiers and supporting personal verification data must 1033 be subject to users' privacy preference. 1035 2. Session setup messages, as well as identity assertions, should be 1036 protected to prevent tampering and eavesdropping. 1038 3. Users' affiliations with organizations should be subject to 1039 privacy preferences. Currently, corporate requirements are not 1040 addressed. 1042 8.5. Calling Services 1044 1. Users should be able to set privacy rules for untrusted CS or 1045 destinations websites acting as calling services, regardless of 1046 the service own parameters. 1048 2. CS should be able to determine privacy parameters per 1049 organizations, for data confidentiality and anonymity. 1051 3. Despite users' choice of IdP, calling services should not be 1052 precluded from mandating their choice of IdPs, or offering a 1053 preferred IdP list. 1055 4. There must be a transparent method of resolving conflicting 1056 privacy requirements arising from the respective CS options. 1058 5. The original website that redirects to a calling service should 1059 not be named as 'origin', if users wish to avoid divulging it. 1061 6. To distinguish between withheld identity and undetected identity, 1062 the "origin" field should only provide a status indicator. 1064 8.6. Usability and Notification 1066 1. Users should be informed how their privacy will be handled by the 1067 calling service, and which identity and IdP are used. 1069 2. It should be possible to request unlinkability and pseudonimity 1070 for a shared group identity, but allow members to maintain 1071 separate identities with personal privacy preferences. 1073 3. The IdP must notify users (or CS clients) if it is not possible 1074 to support undetectable, pseudonymous or unlinkable calling. 1075 Currently, there are no IdP notifications to the user. 1077 4. Users should be notified if a default IdP is assigned, and if 1078 other than their chosen IdP is assigned. 1080 9. Conclusions 1082 The web calling paradigm is transformed by browser-based calling 1083 facilities that are easily added to shop windows websites. However, 1084 this encourages opportunistic calling with increased risks from 1085 untrusted parties. The spread of such calling services means users 1086 have to maintain numerous identities/passwords, while established 1087 services lock-in users to the service-bound identity. Users need to 1088 manage their own structured identities, independently of any service. 1089 They also need to control their privacy preferences, and vary such 1090 preferences for high-risk connections. A solution is needed not only 1091 to allow users to control their privacy requirements according to 1092 web-calling context, but also to protect destination websites from 1093 abuse of anonymity. 1095 10. Contributors 1097 This document is the result of a very fruitful work within the 1098 reThink project, with also the following contributors: 1100 I. Tariq Javed 1101 Institut Mines Telecom-Telecom Sud Paris 1102 9 rue C.Fourier 1103 Evry 91011 1104 France 1105 Email: ibrahim_tariq.javed@telecom-sudparis.eu 1107 N. Crespi 1108 Institut Mines Telecom-Telecom Sud Paris 1109 9 rue C.Fourier 1110 Evry 91011 1111 France 1112 Email: noel.crespi@mines-telecom.fr 1114 A. Bouabdallah 1115 Institut Mines Telecom-Telecom Bretagne 1116 2 rue de la Chataigneraie 1117 Cesson Sevigne 35576 1118 France 1119 Email: ahmed.bouabdallah@telecom-bretagne.eu 1121 S. Becot 1122 Orange Labs 1123 4, rue du Clos Courtel 1124 Cesson Sevigne 35510 1125 France 1126 Email: simon.becot@orange.com 1128 J.-M. Crom 1129 Orange Labs 1130 4, rue du Clos Courtel 1131 Cesson Sevigne 35510 1132 France 1133 Email: jeanmichel.crom@orange.com 1135 11. Acknowledgements 1137 This document was inspired by a draft authored by Victoria Beltran, 1138 Orange (Email: vicbelma@gmail.com); Emmanuel Bertin, Orange (Email: 1139 emmanuel.bertin@orange.com); Stephane Cazeaux, Orange (Email: 1140 stephane.cazeaux@orange.com). 1142 Thank you to Ricardo Chaves (INESC-ID) who provided us with his 1143 interesting feedback and comments. 1145 This work has received funding from the European Union's Horizon 2020 1146 research and innovation program under grant agreement No 645342, 1147 project reTHINK. 1149 12. References 1151 12.1. Normative references 1153 [I-D.ietf-rtcweb-overview] 1154 Alvestrand, H., "Overview: Real Time Protocols for 1155 Browser-based Applications", draft-ietf-rtcweb-overview-15 1156 (work in progress), January 2016. 1158 [I-D.ietf-rtcweb-security-arch] 1159 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1160 rtcweb-security-arch-12 (work in progress), June 2016. 1162 [I-D.ietf-rtcweb-use-cases-and-requirements] 1163 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 1164 Time Communication Use-cases and Requirements", draft- 1165 ietf-rtcweb-use-cases-and-requirements-16 (work in 1166 progress), January 2015. 1168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1169 Requirement Levels", BCP 14, RFC 2119, 1170 DOI 10.17487/RFC2119, March 1997, 1171 . 1173 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1174 A., Peterson, J., Sparks, R., Handley, M., and E. 1175 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1176 DOI 10.17487/RFC3261, June 2002, 1177 . 1179 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1180 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1181 DOI 10.17487/RFC4122, July 2005, 1182 . 1184 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1185 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1186 . 1188 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1189 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1190 . 1192 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1193 Morris, J., Hansen, M., and R. Smith, "Privacy 1194 Considerations for Internet Protocols", RFC 6973, 1195 DOI 10.17487/RFC6973, July 2013, 1196 . 1198 12.2. Informative references 1200 [I-D.cazeaux-rtcweb-oauth-identity] 1201 Beltran, V., Bertin, E., and S. Cazeaux, "Additional Use- 1202 cases and Requirements for WebRTC Identity Architecture", 1203 draft-cazeaux-rtcweb-oauth-identity-00 (work in progress), 1204 March 2015. 1206 [I-D.ietf-rtcweb-security] 1207 Rescorla, E., "Security Considerations for WebRTC", draft- 1208 ietf-rtcweb-security-08 (work in progress), February 2015. 1210 [JeffSayreHenryStory] 1211 Sayre, J. and H. Story, "The WebID Protocol & Browsers", 1212 May 2011, . 1215 [OIDC] "OpenID Connect Core 1.0 incorporating errata set 1", 1216 . 1219 [SurrogateKeys] 1220 Carter, B., "Intelligent Versus Surrogate Keys", 1997, 1221 . 1223 [TerminologyForPrivacy] 1224 Pfitzmann, A., Hansen, M., and H. Tschofenig , "A 1225 terminology for privacy by data minimization: Anonymity, 1226 Unlinkability, Undetectability, 1227 Unobservability,Pseudonymity, and Identity Management - 1228 V0.34", August 2010. 1230 [WebRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. 1231 Narayanan, "WebRTC 1.0: Real-time Communication Between 1232 Browsers. World Wide Web Consortium WD WD-webrtc- 1233 20120821.", August 2012. 1235 Authors' Addresses 1237 Rebecca Copeland (editor) 1238 Institut Mines Telecom-Telecom Sud Paris 1239 9 rue C.Fourier 1240 Evry 91011 1241 France 1243 Email: rebecca.copeland@coreviewpoint.com 1245 Kevin Corre 1246 Orange Labs 1247 4, rue du Clos Courtel 1248 Cesson Sevigne 35510 1249 France 1251 Email: kevin1.corre@orange.com 1253 Ingo Friese 1254 Deutsche Telekom AG 1255 Winterfeldtstr. 21 1256 Berlin 10781 1257 Germany 1259 Email: Ingo.Friese@telekom.de 1260 Saad El Jaouhari 1261 Institut Mines Telecom-Telecom Bretagne 1262 2 rue de la Chataigneraie 1263 Cesson Sevigne 35576 1264 France 1266 Email: saad.eljaouhari@telecom-bretagne.eu