<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2818 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3264 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3711 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC3986 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4566 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4568 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY RFC4648 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5479 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5479.xml">
<!ENTITY RFC5705 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5705.xml">
<!ENTITY RFC5763 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml">
<!ENTITY RFC5764 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY RFC5785 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC5890 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC6265 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY RFC6347 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6454 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC6455 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml">
<!ENTITY RFC6943 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6943.xml">
<!ENTITY RFC7022 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml">
<!ENTITY RFC6120 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml">
<!ENTITY RFC7617 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml">
<!ENTITY RFC7675 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml">
<!ENTITY RFC7918 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7918.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8122 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8122.xml">
<!ENTITY RFC8259 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
<!ENTITY RFC8261 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.xml">
<!ENTITY RFC8445 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">

<!ENTITY I-D.ietf-rtcweb-overview SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml">
<!ENTITY I-D.ietf-rtcweb-jsep SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-jsep.xml">
<!ENTITY I-D.ietf-rtcweb-security SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security.xml">
<!ENTITY I-D.ietf-rtcweb-rtp-usage SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-rtp-usage.xml">
<!ENTITY I-D.ietf-mmusic-sdp-uks SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-uks">

]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     number="8827" docName="draft-ietf-rtcweb-security-arch-20"
     ipr="pre5378Trust200902">
     ipr="pre5378Trust200902" obsoletes="" updates="" submissionType="IETF"
     consensus="true" xml:lang="en" tocInclude="true" tocDepth="4"
     symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.33.0 -->
  <front>
    <title abbrev="WebRTC Sec. Arch.">WebRTC Security Architecture</title>
    <seriesInfo name="RFC" value="8827"/>
    <author fullname="Eric Rescorla" initials="E.K." initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
      <address>
        <postal>
          <street>2064 Edgewood Drive</street>
          <city>Palo Alto</city>
          <region>CA</region>
          <code>94303</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 650 678 2350</phone>
        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date/>

    <area>ART</area>

    <workgroup>RTCWEB</workgroup>
    <date month="June" year="2020"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search -->

    <abstract>
      <t>
<!-- [rfced] In this cluster, we have been expanding WebRTC in the body of the
document (but not the title) as Web Real-Time Communication.  Do you want to
include this expansion somewhere, or is not needed with the current
explanatory text?

Original (first occurrence):
   This document defines the security architecture for WebRTC, a
   protocol suite intended for use with real-time applications that can
   be deployed in browsers - "real time communication on the Web".
-->

      <t>
        This document defines the security architecture for WebRTC, a protocol
        suite intended for use with real-time applications that can be deployed
        in browsers -- "real-time communication on the Web".
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sec.introduction"> anchor="sec.introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The Real-Time Communications on the Web (RTCWEB) working group Working Group
        standardized protocols for real-time communications between Web
        browsers, generally called "WebRTC" <xref target="I-D.ietf-rtcweb-overview"/>. target="RFC8825" format="default"/>.
        The major use cases for WebRTC technology are real-time audio
        and/or video calls, Web conferencing, and direct data transfer. Unlike
        most conventional real-time systems, systems (e.g., SIP-based <xref
        target="RFC3261"></xref> target="RFC3261" format="default"/> soft phones) phones), WebRTC communications are directly
        controlled by some Web server, via a JavaScript (JS) API as shown in
        <xref target="fig.simple"/>. target="fig.simple" format="default"/>.
      </t>
      <figure title="A simple WebRTC system" anchor="fig.simple">
        <artwork><![CDATA[
        <name>A Simple WebRTC System</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                         +----------------+
                         |                |
                         |   Web Server   |
                         |                |
                         +----------------+
                             ^        ^
                            /          \
                    HTTP   /            \   HTTP
                          /              \
                         /                \
                        v                  v
                     JS API              JS API
               +-----------+            +-----------+
               |           |    Media   |           |
               |  Browser  |<---------->|  Browser  |
               |           |            |           |
               +-----------+            +-----------+ ]]></artwork>
      </figure>
      <t>
        A more complicated system might allow for interdomain calling, as shown
        in <xref target="fig.multidomain"/>. target="fig.multidomain" format="default"/>.  The protocol to be used between
        the domains is not standardized by WebRTC, but given the installed base
        and the form of the WebRTC API is likely to be something SDP-based like
        SIP or something like the Extensible Messaging and Presence Protocol (XMPP)
        <xref target="RFC6120"/>. target="RFC6120" format="default"/>.
      </t>
      <figure title="A multidomain WebRTC system" anchor="fig.multidomain">
        <artwork><![CDATA[
        <name>A Multidomain WebRTC System</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          +--------------+                +--------------+
          |              | SIP,XMPP,...| SIP, XMPP, ... |              |
          |  Web Server  |<----------->|  |<-------------->|  Web Server  |
          |              |                |              |
          +--------------+                +--------------+
                 ^                                ^
                 |                                |
           HTTP  |                                |  HTTP
                 |                                |
                 v                                v
                 JS API                       JS API
           +-----------+                     +-----------+
           |           |        Media        |           |
           |  Browser  |<---------------->|  |<------------------->|  Browser  |
           |           |                     |           |
           +-----------+                     +-----------+ ]]></artwork>
      </figure>
      <t>
        This system presents a number of new security challenges, which are
        analyzed in <xref target="I-D.ietf-rtcweb-security"/>. target="RFC8826" format="default"/>.  This document
        describes a security architecture for WebRTC which addresses the threats
        and requirements described in that document.
      </t>
    </section>
    <section anchor="sec-term" title="Terminology">
      <t>
        The numbered="true" toc="default">
      <name>Terminology</name>
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
    "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
    "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t> here.</t>

    </section>
    <section title="Trust Model" anchor="sec.proposal.trusthierarchy"> anchor="sec.proposal.trusthierarchy" numbered="true" toc="default">
      <name>Trust Model</name>
      <t>
        The basic assumption of this architecture is that network resources
        exist in a hierarchy of trust, rooted in the browser, which serves as
        the user's Trusted Computing Base (TCB). Any security property which the
        user wishes to have enforced must be ultimately guaranteed by the
        browser (or transitively by some property the browser
        verifies). Conversely, if the browser is compromised, then no security
        guarantees are possible.  Note that there are cases (e.g., Internet
        kiosks) where the user can't really trust the browser that much. In
        these cases, the level of security provided is limited by how much they
        trust the browser.
      </t>
      <t>
        Optimally, we would not rely on trust in any entities other than the
        browser. However, this is unfortunately not possible if we wish to have
        a functional system.  Other network elements fall into two categories:
        those which can be authenticated by the browser and thus can be granted
        permissions to access sensitive resources, and those which cannot be
        authenticated and thus are untrusted.
      </t>
      <section title="Authenticated Entities" anchor="sec.proposal.authenticated"> anchor="sec.proposal.authenticated" numbered="true" toc="default">
        <name>Authenticated Entities</name>
        <t>
          There are two major classes of authenticated entities in the system:
        </t>
        <t>
          <list style="symbols">
            <t>
              Calling services: Web
        <dl newline="false" spacing="normal">
          <dt>Calling services:</dt>
           <dd>Web sites whose origin we can verify (optimally
              via HTTPS, but in some cases because we are on a topologically
              restricted network, such as behind a firewall, and can infer
              authentication from firewall behavior).
            </t>
            <t>
              Other users: WebRTC behavior).</dd>
           <dt>Other users:</dt>
            <dd>WebRTC peers whose origin we can verify
              cryptographically (optimally via DTLS-SRTP).
            </t>
          </list>
        </t> DTLS-SRTP).</dd>
        </dl>
        <t>
          Note that merely being authenticated does not make these entities
          trusted. For instance, just because we can verify that
          https://www.example.org/
          &lt;https://www.example.org/&gt; is owned by Dr. Evil does not mean that we can
          trust Dr. Evil to access our camera and microphone. However, it gives
          the user an opportunity to determine whether he wishes to trust
          Dr. Evil or not; after all, if he desires to contact Dr. Evil (perhaps
          to arrange for ransom payment), it's safe to temporarily give him
          access to the camera and microphone for the purpose of the call, but
          he doesn't want Dr. Evil to be able to access his camera and
          microphone other than during the call. The point here is that we must
          first identify other elements before we can determine whether and how
          much to trust them. Additionally, sometimes we need to identify the
          communicating peer before we know what policies to apply.
        </t>

      </section>

      <section title="Unauthenticated Entities" anchor="sec.proposal.unauthenticated">
        <t>
          Other than the above entities, we are not generally able to identify
          other network elements, thus we cannot trust them.  This does not mean
          that it is not possible to have any interaction with them, but it
          means that we must assume that they will behave maliciously and design
          a system which is secure even if they do so.
        </t>
      </section>
    </section>
    <!-- Not layered ? -->

    <section title="Overview" anchor="sec.proposal.overview">

<!-- TODO: Federated -->
      <t>
        This section describes a typical WebRTC session [rfced] Sections 3.1 and shows how subsequent:  Per the
        various security elements interact "Gender-Specific
Language" section of <https://www.rfc-editor.org/styleguide/part2/>,
please let us know if we may change these instances of "he," "him,"
and what guarantees are provided "his" to "they," "them," and "their."

Original:
 However, it
 gives the user. The example in this section is a "best case" scenario in which
        we provide the maximal amount of user authentication and media privacy
        with the minimal level of an opportunity to determine whether he wishes to trust in the calling service. Simpler versions
        with lower levels of security are also possible and are noted in the
        text where applicable. It's also important
 Dr. Evil or not; after all, if he desires to contact Dr. Evil
 (perhaps to arrange for ransom payment), it's safe to temporarily
 give him access to recognize the tension
        between security (or performance) camera and privacy. The example shown here is
        aimed towards settings where we are more concerned about secure calling
        than about privacy, but as we shall see, there are settings where one
        might wish to make different tradeoffs--this architecture is still
        compatible with those settings.
      </t>
      <t>
        For microphone for the purposes purpose of this example, we assume the topology shown in the
        figures below. This topology is derived from the topology shown in <xref
        target="fig.simple"/>,
 call, but separates Alice he doesn't want Dr. Evil to be able to access his camera
 and Bob's identities from microphone other than during the
        process call.
...
 The
 idea behind this type of signaling.  Specifically, Alice and Bob have relationships
        with some Identity Provider (IdP) permissions is that supports a protocol (such as
        OpenID Connect) that can be used to demonstrate their identity to
        other parties. For instance, Alice user might have an account with a social
        network which she can then use to authenticate to other web sites
        without explicitly having an account with those sites; this is a
 fairly
        conventional pattern on the Web. <xref
        target="sec.trust-relationships"/> provides an overview narrow list of Identity
        Providers and peers he is willing to communicate with, e.g.,
 "my mother" rather than "anyone on Facebook".
...
 Note that this
 does not mean that the relevant terminology.  Alice and Bob IdP might have
        relationships with different IdPs as well.
      </t>
      <t>
        This separation of identity provision and signaling isn't particularly
        important not lie, but that is a
 trustworthiness judgement that the user can make at the time he looks
 at the identity.
...
 Note that
 this requires user consent in "closed world" many cases where Alice and Bob are users on but because the
        same social network and have identities based on that domain (<xref
        target="fig.proposal.idp"/>). However, there are important settings where data channel
 does not need consent, he can use that directly.
...
 Fundamentally, the IdP proxy is not just a piece of HTML and JS loaded by
 the case, such as federation (calls browser, so nothing stops a Web attacker from one domain to
        another; <xref target="fig.proposal-federated.idp"/>) creating their own
 IFRAME, loading the IdP proxy HTML/JS, and calling on
        untrusted sites, such as where two users who have a relationship via a
        given social network want to call each other on another, untrusted,
        site, such as requesting a poker site. signature
 over his own keys rather than those generated in the browser. -->

        </t>
      </section>
      <section anchor="sec.proposal.unauthenticated" numbered="true" toc="default">
        <name>Unauthenticated Entities</name>
        <t>
        Note that
          Other than the servers themselves above entities, we are also authenticated by an external
        identity service, the SSL/TLS certificate infrastructure (not shown).
        As not generally able to identify
          other network elements; thus, we cannot trust them.  This does not mean
          that it is conventional in the Web, all identities are ultimately rooted in
        that system. For instance, when an IdP makes an identity assertion, the
        Relying Party consuming that assertion is able to verify because it is
        able to connect not possible to the IdP via HTTPS.
      </t>
      <figure title="A call have any interaction with IdP-based identity" anchor="fig.proposal.idp">
        <artwork><![CDATA[
                            +----------------+
                            |                |
                            |     Signaling  |
                            |     Server     |
                            |                |
                            +----------------+
                                ^        ^
                               /          \
                       HTTPS  /            \   HTTPS
                             /              \
                            /                \
                           v                  v
                        JS API              JS API
                  +-----------+            +-----------+
                  |           |    Media   |           |
            Alice |  Browser  |<---------->|  Browser  | Bob
                  |           | (DTLS+SRTP)|           |
                  +-----------+            +-----------+
                        ^      ^--+     +--^     ^
                        |         |     |        |
                        v         |     |        v
                  +-----------+   |     |  +-----------+
                  |           |<--------+  |           |
                  |   IdP1    |   |        |    IdP2   |
                  |           |   +------->|           |
                  +-----------+            +-----------+
]]></artwork>
      </figure>
      <t>
        <xref target="fig.proposal-federated.idp"/> shows essentially the same
        calling scenario them, but with a call between two separate domains (i.e., it
          means that we must assume that they will behave maliciously and design
          a
        federated case), as system which is secure even if they do so.
        </t>
      </section>
    </section>
    <section anchor="sec.proposal.overview" numbered="true" toc="default">
      <name>Overview</name>

<!-- [rfced] Section 4:  We found these comments in <xref target="fig.multidomain"/>. As mentioned
        above, the domains communicate by some unspecified protocol original
approved XML file.  Were these items resolved?

Original:
    </section>
    <!- - Not layered ? - ->

    <section title="Overview" anchor="sec.proposal.overview">
      <!- - TODO: Federated - -> -->

      <t>
        This section describes a typical WebRTC session and
        providing separate signaling shows how the
        various security elements interact and identity allows for calls what guarantees are provided to be
        authenticated regardless of
        the details of user. The example in this section is a "best case" scenario in which
        we provide the inter-domain protocol.
      </t>
      <figure title="A federated call maximal amount of user authentication and media privacy
        with IdP-based identity" anchor="fig.proposal-federated.idp">
        <artwork><![CDATA[
        +----------------+    Unspecified    +----------------+
        |                |      protocol     |                |
        |    Signaling   |<----------------->|    Signaling   |
        |    Server      |  (SIP, XMPP, ...) |    Server      |
        |                |                   |                |
        +----------------+                   +----------------+
                 ^                                   ^
                 |                                   |
           HTTPS |                                   | HTTPS
                 |                                   |
                 |                                   |
                 v                                   v
              JS API                               JS API
        +-----------+                             +-----------+
        |           |             Media           |           |
  Alice |  Browser  |<--------------------------->|  Browser  | Bob
        |           |           DTLS+SRTP         |           |
        +-----------+                             +-----------+
              ^      ^--+                      +--^     ^
              |         |                      |        |
              v         |                      |        v
        +-----------+   |                      |  +-----------+
        |           |<-------------------------+  |           |
        |   IdP1    |   |                         |    IdP2   |
        |           |   +------------------------>|           |
        +-----------+                             +-----------+
]]></artwork>
      </figure>

      <section title="Initial Signaling">
        <t>
          For simplicity, assume the topology in <xref
          target="fig.proposal.idp"/>.  Alice and Bob are both users minimal level of a common
          calling service; they both have approved trust in the calling service to make
          calls (we defer the discussion service. Simpler versions
        with lower levels of device access permissions until
          later).  They security are both connected to the calling service via HTTPS also possible and
          so know are noted in the origin with some level of confidence. They
        text where applicable. It's also have
          accounts with some identity provider.  This sort of identity service
          is becoming increasingly common in important to recognize the Web environment (with technologies
          such as Federated Google Login, Facebook Connect, OAuth,
          OpenID, WebFinger), tension
        between security (or performance) and privacy. The example shown here is often provided as a side effect service of
          a user's ordinary accounts with some service. In this example,
        aimed towards settings where we show
          Alice and Bob using a separate identity service, though the identity
          service may be the same entity as the are more concerned about secure calling service or
        than about privacy, but as we shall see, there may be
          no identity service at all. are settings where one
        might wish to make different trade&nbhy;offs -- this architecture is still
        compatible with those settings.
      </t>
      <t>
          Alice is logged onto
        For the calling service and decides to call Bob.  She
          can see from purposes of this example, we assume the calling service that he topology shown in the
        figures below. This topology is online and derived from the calling
          service presents a JS UI topology shown in <xref target="fig.simple" format="default"/>, but separates Alice's and Bob's identities from the form
        process of a button next to Bob's name
          which says "Call". signaling.  Specifically, Alice clicks the button, which initiates a JS
          callback and Bob have relationships
        with some Identity Provider (IdP) that instantiates supports a PeerConnection object. This does not
          require protocol (such as
        OpenID Connect) that can be used to demonstrate their identity to
        other parties. For instance, Alice might have an account with a security check: JS from any origin is allowed social
        network which she can then use to get this
          far.
        </t>

        <t>
          Once the PeerConnection is created, the calling service JS needs authenticate to
          set up some media. Because other Web sites
        without explicitly having an account with those sites; this is an audio/video call, it creates a
          MediaStream with two MediaStreamTracks, one connected to fairly
        conventional pattern on the Web. &nbsp;<xref target="sec.trust-relationships" format="default"/> provides an audio
          input overview of Identity
        Providers and one connected to a video input. At this point the first
          security check is required: untrusted origins are not allowed to
          access the camera and microphone, so the browser prompts relevant terminology.  Alice for
          permission. and Bob might have
        relationships with different IdPs as well.
      </t>
      <t>
          In
        This separation of identity provision and signaling isn't particularly
        important in "closed world" cases where Alice and Bob are users on the current W3C API, once some streams
        same social network and have been added, Alice's
          browser + JS generates a signaling message <xref
          target="I-D.ietf-rtcweb-jsep"/> containing:
        </t>
        <t>
          <list style="symbols">
            <t>
              Media channel information
            </t>
            <t>
              Interactive Connectivity Establishment (ICE) <xref
              target="RFC8445"/> candidates
            </t>
            <t>
              A fingerprint attribute binding identities based on that domain (<xref target="fig.proposal.idp" format="default"/>). However, there are important settings where
        that is not the communication case, such as federation (calls from one domain to a key pair
        another; see <xref target="RFC5763"/>. Note that this key may simply be
              ephemerally generated for this call or specific to this domain, target="fig.proposal-federated.idp" format="default"/>) and Alice may calling on
        untrusted sites, such as where two users who have a large number of relationship via a
        given social network want to call each other on another, untrusted,
        site, such keys.
            </t>
          </list> as a poker site.
      </t>
      <t>
          Prior to sending out
        Note that the signaling message, servers themselves are also authenticated by an external
        identity service, the PeerConnection code
          contacts SSL/TLS certificate infrastructure (not shown).
        As is conventional in the identity service and obtains Web, all identities are ultimately rooted in
        that system. For instance, when an IdP makes an assertion binding Alice's identity assertion, the
        Relying Party consuming that assertion is able to verify because it is
        able to connect to her fingerprint. The exact details depend on the identity
          service (though as discussed in <xref target="sec.generic.idp"/>
          PeerConnection can be agnostic to them), but for now it's easiest to
          think of as an OAuth token.  The assertion may bind other
          information to the identity besides the fingerprint, but at minimum it
          needs to bind the fingerprint. IdP via HTTPS.
      </t>
      <figure anchor="fig.proposal.idp">
        <name>A Call with IdP-Based Identity</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                            +----------------+
                            |                |
                            |     Signaling  |
                            |     Server     |
                            |                |
                            +----------------+
                                ^        ^
                               /          \
                       HTTPS  /            \   HTTPS
                             /              \
                            /                \
                           v                  v
                        JS API              JS API
                  +-----------+            +-----------+
                  |           |    Media   |           |
            Alice |  Browser  |<---------->|  Browser  | Bob
                  |           | (DTLS+SRTP)|           |
                  +-----------+            +-----------+
                        ^      ^--+     +--^     ^
                        |         |     |        |
                        v         |     |        v
                  +-----------+   |     |  +-----------+
                  |           |<--------+  |           |
                  |   IdP1    |   |        |    IdP2   |
                  |           |   +------->|           |
                  +-----------+            +-----------+ ]]></artwork>
      </figure>
      <t>
          This message is sent to the signaling server, e.g., by XMLHttpRequest
          <xref target="XmlHttpRequest"/> or by WebSockets
        <xref
          target="RFC6455"/>, over TLS <xref target="RFC5246"/>.
          The signaling server processes target="fig.proposal-federated.idp" format="default"/> shows essentially the message from Alice's browser,
          determines that this is same
        calling scenario but with a call to Bob and sends between two separate domains (i.e., a signaling message to
          Bob's browser (again, the format is currently undefined).  The JS on
          Bob's browser processes it, and alerts Bob to
        federated case), as in <xref target="fig.multidomain" format="default"/>. As mentioned
        above, the incoming call domains communicate by some unspecified protocol, and to
          Alice's identity. In this case, Alice has provided an identity
          assertion
        providing separate signaling and so Bob's browser contacts Alice's identity provider
          (again, this is done in a generic way so the browser has no specific
          knowledge allows for calls to be
        authenticated regardless of the IdP) to verify details of the assertion. It is also possible
          to have IdPs inter-domain protocol.
      </t>
      <figure anchor="fig.proposal-federated.idp">
        <name>A Federated Call with which IdP-Based Identity</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        +----------------+    Unspecified    +----------------+
        |                |      protocol     |                |
        |    Signaling   |<----------------->|    Signaling   |
        |    Server      |  (SIP, XMPP, ...) |    Server      |
        |                |                   |                |
        +----------------+                   +----------------+
                 ^                                   ^
                 |                                   |
           HTTPS |                                   | HTTPS
                 |                                   |
                 |                                   |
                 v                                   v
              JS API                               JS API
        +-----------+                             +-----------+
        |           |             Media           |           |
  Alice |  Browser  |<--------------------------->|  Browser  | Bob
        |           |           DTLS+SRTP         |           |
        +-----------+                             +-----------+
              ^      ^--+                      +--^     ^
              |         |                      |        |
              v         |                      |        v
        +-----------+   |                      |  +-----------+
        |           |<-------------------------+  |           |
        |   IdP1    |   |                         |    IdP2   |
        |           |   +------------------------>|           |
        +-----------+                             +-----------+ ]]></artwork>
      </figure>
      <section numbered="true" toc="default">
        <name>Initial Signaling</name>
        <t>
          For simplicity, assume the browser has a specific trustrelationship,
          as described topology in <xref target="sec.trust-relationships"/>.
          This allows the browser
          to display a trusted element in the browser chrome indicating that a
          call is coming in from Alice. If target="fig.proposal.idp" format="default"/>.  Alice is in Bob's address book, then
          this interface might also include her real name, and Bob are both users of a picture, etc.  The common
          calling site will also provide some user interface element (e.g., a
          button) to allow Bob service; they both have approved the calling service to answer make
          calls (we defer the call, though this is most likely
          not part discussion of device access permissions until
          later).  They are both connected to the trusted UI.
        </t>
        <t>
          If Bob agrees a PeerConnection is instantiated with calling service via HTTPS and
          so know the message from
          Alice's side.  Then, a similar process occurs as on Alice's browser:
          Bob's browser prompts him for device permission, origin with some level of confidence. They also have
          accounts with some identity provider.  This sort of identity service
          is becoming increasingly common in the media streams are
          created, and a return signaling message containing media information,
          ICE candidates, Web environment (with technologies
          such as Federated Google Login, Facebook Connect, OAuth,
          OpenID, WebFinger), and a fingerprint is sent back to Alice via the
          signaling service.  If Bob has often provided as a relationship with an IdP, the message
          will also come side effect service of
          a user's ordinary accounts with an identity assertion.
        </t>
        <t>
          At some service. In this point, example, we show
          Alice and Bob each know that the other party wants to
          have using a secure call with them. Based purely on the interface provided
          by separate identity service, though the signaling server, they know that identity
          service may be the signaling server claims
          that same entity as the call is from calling service or there may be
          no identity service at all.
        </t>
        <t>
          Alice to Bob. This level of security is provided
          merely by having the fingerprint in logged onto the message calling service and having that
          message received securely decides to call Bob. &nbsp;She
          can see from the signaling server.  Because the far
          end sent an identity assertion along with their message, they know calling service that this he is verifiable from the IdP as well. Note that if online and the call is
          federated, as shown calling
          service presents a JS UI in <xref target="fig.proposal-federated.idp"/>
          then Alice is able the form of a button next to verify Bob's identity in name
          which says "Call". Alice clicks the button, which initiates a way JS
          callback that is instantiates a PeerConnection object. This does not
          mediated by either her signaling server or Bob's. Rather, she verifies
          it directly with Bob's IdP.
          require a security check: JS from any origin is allowed to get this
          far.
        </t>
        <t>
          Of course,
          Once the call works perfectly well if either Alice or Bob
          doesn't have a relationship with an IdP; they just get a lower level
          of assurance. I.e., they simply have whatever information their
          calling site claims about PeerConnection is created, the caller/callee's identity.  Moreover,
          Alice might wish calling service JS needs to make
          set up some media. Because this is an anonymous call through audio/video call, it creates a
          MediaStream with two MediaStreamTracks, one connected to an anonymous
          calling site, in which case she would of course just not provide any
          identity assertion and the calling site would mask her identity from
          Bob.
        </t>
      </section>

      <section title="Media Consent Verification">
        <t>
          As described in (<xref target="I-D.ietf-rtcweb-security"/>; Section
          4.2) media consent verification is provided via ICE.  Thus, Alice audio
          input and
          Bob perform ICE checks with each other.  At the completion of these
          checks, they are ready one connected to send non-ICE data.
        </t>
        <t> a video input. At this point, Alice knows that (a) Bob (assuming he is verified via
          his IdP) or someone else who the signaling service is claiming is Bob first
          security check is willing required: untrusted origins are not allowed to exchange traffic with her
          access the camera and (b) that either Bob is at microphone, so the IP address which she has verified via ICE or there is an attacker
          who is on-path to that IP address detouring the traffic. Note that it
          is not possible for an attacker who is on-path between browser prompts Alice and Bob
          but not attached to the signaling service to spoof these checks
          because they do not have the ICE credentials. Bob has the same
          security guarantees with respect to Alice. for
          permission.
        </t>
      </section>

      <section title="DTLS Handshake">
        <t>
          Once
          In the requisite ICE checks current W3C API, once some streams have completed, Alice and Bob can set
          up been added, Alice's
          browser + JS generates a secure channel or channels. This is performed via DTLS <xref target="RFC6347"/>
          and DTLS-SRTP signaling message <xref target="RFC5763"/> keying for SRTP target="RFC8829" format="default"/> containing:
        </t>
        <ul spacing="normal">
          <li>
              Media channel information
            </li>
          <li>
              Interactive Connectivity Establishment (ICE) <xref target="RFC3711"/> for target="RFC8445" format="default"/> candidates
            </li>
          <li>
              A "fingerprint" attribute binding the media channel and SCTP over DTLS communication to a key pair
              <xref target="RFC8261"/> target="RFC5763" format="default"/>. Note that this key may simply be
              ephemerally generated for data
          channels. Specifically, Alice this call or specific to this domain,
              and Bob perform Alice may have a DTLS handshake on
          every component which has been established by ICE. The total large number of
          channels depends on such keys.
            </li>
        </ul>
        <t>
          Prior to sending out the amount of muxing; in signaling message, the most likely case we
          are using both RTP/RTCP mux PeerConnection code
          contacts the identity service and muxing multiple media streams obtains an assertion binding Alice's
          identity to her fingerprint. The exact details depend on the
          same channel, identity
          service (though as discussed in which case there is only one DTLS handshake. Once the
          DTLS handshake has completed, the keys are exported <xref
          target="RFC5705"/> and used target="sec.generic.idp" format="default"/>
          PeerConnection can be agnostic to key SRTP them), but for the media channels.
        </t>
        <t>
          At this point, Alice and Bob know that they share a set of secure data
          and/or media channels with keys which are not known now it's easiest to any third-party
          attacker. If Alice and Bob authenticated via their IdPs, then they
          also know that the signaling service is not mounting a
          man-in-the-middle attack on their traffic. Even if they do not use an
          IdP, as long
          think of as they have minimal trust in the signaling service not an OAuth token.  The assertion may bind other
          information to perform a man-in-the-middle attack, they know that their
          communications are secure against the signaling service as well (i.e.,
          that identity besides the signaling service cannot mount a passive attack on fingerprint, but at minimum it
          needs to bind the
          communications). fingerprint.
        </t>

      </section>

      <section title="Communications and Consent Freshness">
        <t>
          From a security perspective, everything from here on in
          This message is a little
          anticlimactic: Alice and Bob exchange data protected by sent to the keys
          negotiated signaling server, e.g., by DTLS. XMLHttpRequest
          <xref target="XmlHttpRequest" format="default"/> or by WebSockets
	  <xref target="RFC6455" format="default"/>, over TLS <xref
	  target="RFC5246" format="default"/>.

<!-- [rfced] Section 4.1:  Because of RFC 5246 has been obsoleted by
RFC 8446, would you like to (1) cite and list RFC 8446 instead,
(2) list both documents, or (3) leave the security guarantees discussed obsolete citation in
          the previous sections, they know that the communications are encrypted
          and authenticated.
        </t>
        <t>
          The one remaining security property we need to establish place
(i.e., no changes)?

Original:
 This message is "consent
          freshness", i.e., allowing Alice sent to verify the signaling server, e.g., by XMLHttpRequest
 [XmlHttpRequest] or by WebSockets [RFC6455], over TLS [RFC5246]. -->

          The signaling server processes the message from Alice's browser,
          determines that Bob this is still prepared a call to receive her communications so that Alice does not continue to send
          large traffic volumes Bob, and sends a signaling message to entities which went abruptly offline. ICE
          specifies periodic STUN keepalives but only if media is not flowing.
          Because
          Bob's browser (again, the consent issue format is more difficult here, we require WebRTC
          implementations to periodically send keepalives.  As described in
          Section 5.3, these keepalives MUST be based currently undefined).  The JS on the consent freshness
          mechanism specified in <xref target="RFC7675"/>.  If a
          keepalive fails
          Bob's browser processes it, and no new ICE channels can be established, then alerts Bob to the
          session is terminated.
        </t>
      </section>
    </section>

    <section title="SDP Identity Attribute" anchor="sec.sdp-id-attr">
      <t>
        The SDP 'identity' attribute is a session-level attribute that
        is used by an endpoint incoming call and to convey its
          Alice's identity. In this case, Alice has provided an identity
          assertion to its
        peer. The and so Bob's browser contacts Alice's identity assertion value provider
          (again, this is encoded as Base-64, as described done in Section 4 a generic way so the browser has no specific
          knowledge of <xref target="RFC4648"/>.
      </t>
      <t>
        The procedures in this section are based on the assumption
        that IdP) to verify the identity assertion of an endpoint assertion. It is bound also possible
          to have IdPs with which the
        fingerprints of the endpoint. browser has a specific trust relationship,
          as described in <xref target="sec.trust-relationships" format="default"/>.
          This does not preclude allows the definition of
        alternative means of binding an assertion browser
          to display a trusted element in the endpoint, but such
        means are outside the scope of this specification.
      </t>
      <t>
        The semantics of multiple 'identity' attributes within an
        offer or answer are undefined.  Implementations SHOULD only include browser chrome indicating that a
        single 'identity' attribute
          call is coming in an offer or answer and relying parties
        MAY elect to ignore all but the first 'identity' attribute.
      </t>
      <t>
        <list style="hanging">
        <t hangText="Name:">identity</t>
        <t hangText="Value:">identity-assertion</t>
        <t hangText="Usage Level:">session</t>
        <t hangText="Charset Dependent:">no</t>
        <t hangText="Default Value:">N/A</t>
        <t hangText="Name:">identity</t>
        </list>
      </t>
      <figure>
      <artwork type="inline"><![CDATA[
Syntax:

  identity-assertion        = identity-assertion-value
                              *(SP identity-extension)
  identity-assertion-value  = base64
  identity-extension        = extension-name [ "=" extension-value ]
  extension-name            = token
  extension-value           = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
                              ; byte-string from [RFC4566]

  <ALPHA and DIGIT as defined in [RFC4566]>
  <base64 as defined in [RFC4566]>

 Example:

  a=identity:\
    eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
    In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
    IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
    aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9

  Note that long lines Alice. If Alice is in the example are folded to meet the column
  width constraints of Bob's address book, then
          this document; the backslash ("\") at the end of interface might also include her real name, a line, picture, etc.  The
          calling site will also provide some user interface element (e.g., a
          button) to allow Bob to answer the carriage return that follows, and whitespace shall be ignored.

      ]]></artwork>
       </figure>
       <t>
         This specification does call, though this is most likely
          not define any extensions for part of the attribute. trusted UI.
        </t>
        <t>
         The identity-assertion value
          If Bob agrees, a PeerConnection is instantiated with the message from
          Alice's side.  Then, a JSON <xref target="RFC8259"/> encoded string. The JSON object
         contains two keys: "assertion" similar process occurs as on Alice's browser:
          Bob's browser prompts him for device permission, the media streams are
          created, and "idp". The <spanx style="verb">assertion</spanx> key value contains
         an opaque string that a return signaling message containing media information,
          ICE candidates, and a fingerprint is consumed by sent back to Alice via the IdP. The <spanx style="verb">idp</spanx> key value contains
          signaling service.  If Bob has a
         dictionary relationship with one or two further values that identify an IdP, the IdP. See
         <xref target="sec.request-assert"/> for more details.
       </t>
       <section title="Offer/Answer Considerations" anchor="sec.sdp-id-attr-oa">
         <t>
           This section defines the SDP Offer/Answer <xref target="RFC3264"/> considerations for the SDP
           'identity' attribute. message
          will also come with an identity assertion.
        </t>
        <t>
           Within
          At this section, 'initial offer' refers to the first offer in the
           SDP session point, Alice and Bob each know that contains an SDP <spanx style="verb">identity</spanx> attribute.
         </t>
         <section title="Generating the Initial SDP Offer" anchor="sec.sdp-id-attr-oa-inio">
         <t>
           When an offerer sends an offer, in order to provide its
           identity assertion other party wants to
          have a secure call with them. Based purely on the peer, it includes an 'identity' attribute in
           the offer. In addition, the offerer includes one or more SDP
           'fingerprint' attributes.  The 'identity' attribute MUST be bound to
           all interface provided
          by the 'fingerprint' attributes in signaling server, they know that the session
           description.
         </t>
         </section>
         <section title="Generating of SDP Answer" anchor="sec.sdp-id-attr-oa-ansa">
           <t>
             If signaling server claims
          that the answerer elects call is from Alice to include an 'identity' attribute, it follows Bob. &nbsp;This level of security is provided
          merely by having the same steps as those fingerprint in <xref target="sec.sdp-id-attr-oa-inio"/>.
             The answerer can choose to include or omit an 'identity' attribute independently,
             regardless of whether the offerer did so.
           </t>
         </section>
         <section title="Processing an SDP Offer or Answer" anchor="sec.sdp-id-attr-oa-offa">
           <t>
             When an endpoint receives an offer or answer message and having that contains an 'identity'
             attribute, the answerer can use the the attribute information to
             contact
          message received securely from the IdP and verify signaling server.  Because the far
          end sent an identity of the peer. If assertion along with their message, they know
          that this is verifiable from the identity
             requires a third-party IdP as described well. Note that if the call is
          federated, as shown in <xref target="sec.trust-relationships"/> target="fig.proposal-federated.idp" format="default"/>,
          then that IdP will need Alice is able to have been specifically configured.
             If the verify Bob's identity verification fails, the answerer MUST discard the
             offer or answer as malformed.
           </t>
         </section>
         <section title="Modifying the Session" anchor="sec.sdp-id-attr-oa-modi">
           <t>
             When modifying in a session, if the set of fingerprints is
             unchanged, then the sender MAY send the same 'identity' attribute. In
             this case, the established identity MUST be applied to existing DTLS
             connections as well as new connections established using one of those
             fingerprints. Note that <xref target="I-D.ietf-rtcweb-jsep"/>, Section
             5.2.1 requires way that each media section use the same set of
             fingerprints for every media section.
             If a new identity attribute is received, then the receiver MUST
             apply that identity to all existing connections. not
          mediated by either her signaling server or Bob's. Rather, she verifies
          it directly with Bob's IdP.
        </t>
        <t>
             If the set of fingerprints changes, then
          Of course, the sender MUST call works perfectly well if either send a new 'identity' attribute Alice or none at all.
             Because Bob
          doesn't have a change in fingerprints also causes relationship with an IdP; they just get a new DTLS
             connection lower level
          of assurance. That is, they simply have whatever information their
          calling site claims about the caller/callee's identity.  Moreover,
          Alice might wish to be established, make an anonymous call through an anonymous
          calling site, in which case she would of course just not provide any
          identity assertion and the receiver MUST discard
             all previously established identities. calling site would mask her identity from
          Bob.
        </t>
      </section>
        </section>
    </section>

    <section title="Detailed Technical Description" anchor="sec.proposal.detailed">
      <section title="Origin and Web Security Issues" anchor="sec.proposal.origin"> numbered="true" toc="default">
        <name>Media Consent Verification</name>
        <t>
          The basic unit of permissions for WebRTC is the origin
          As described in <xref
          target="RFC6454"/>. Because the security of the origin depends on
          being able to authenticate content from that origin, the origin can
          only be securely established if data target="RFC8826" sectionFormat="comma"
	  section="4.2"/>, media consent verification is transferred over HTTPS <xref
          target="RFC2818"/>. provided via ICE.
  Thus, clients MUST treat HTTP Alice and HTTPS origins as
          different permissions domains. Note: this follows directly from
          Bob perform ICE checks with each other.  At the
          origin security model and is stated here merely for clarity. completion of these
          checks, they are ready to send non-ICE data.
        </t>
        <t>
          Many web browsers currently forbid by default any active mixed content
          on HTTPS pages. That is, when JavaScript
          At this point, Alice knows that (a) Bob (assuming he is loaded from an HTTP origin
          onto an HTTPS page, an error verified via
          his IdP) or someone else who the signaling service is displayed claiming is Bob
          is willing to exchange traffic with her and the HTTP content (b) either Bob is not
          executed unless the user overrides at
          the error. Any browser IP address which
          enforces such a policy will also not permit access she has verified via ICE or there is an attacker
          who is on-path to WebRTC
          functionality from mixed content pages (because they never display
          mixed content).  Browsers which allow active mixed content MUST
          nevertheless disable WebRTC functionality in mixed content settings.
        </t>
        <t> that IP address detouring the traffic. Note that it
          is not possible for a page which was an attacker who is on-path between Alice and Bob
          but not mixed content attached to
          become mixed content during the duration of signaling service to spoof these checks
          because they do not have the call.  The major risk
          here is that the newly arrived insecure JS might redirect media to a
          location controlled by the attacker.  Implementations MUST either
          choose to terminate the call or display a warning at that point.
        </t>
        <t>
          Also note that ICE credentials. Bob has the same
          security architecture depends on the keying material
          not being available to move between origins.  But, it is assumed that
          the identity assertion can be passed guarantees with respect to anyone that the page cares to. Alice.
        </t>
      </section>
      <section title="Device Permissions Model" anchor="sec.proposal.device.permissions"> numbered="true" toc="default">
        <name>DTLS Handshake</name>
        <t>
          Implementations MUST obtain explicit user consent prior to providing
          access to the camera and/or microphone. Implementations MUST at
          minimum support
          Once the following two permissions models for HTTPS
          origins.
        </t>
        <t>
          <list style="symbols">
            <t>
              Requests for one-time camera/microphone access.
            </t>
            <t>
              Requests for permanent access.
            </t>
          </list>
        </t>
        <t>
          Because HTTP origins cannot be securely established against network
          attackers, implementations MUST refuse all permissions grants for
          HTTP origins.
        </t>
        <t>
          In addition, they SHOULD support requests for access that promise that
          media from this grant will be sent to requisite ICE checks have completed, Alice and Bob can set
          up a single communicating peer
          (obviously there could be other requests secure channel or channels. This is performed via DTLS <xref target="RFC6347" format="default"/>
          and DTLS-SRTP <xref target="RFC5763" format="default"/> keying for SRTP
          <xref target="RFC3711" format="default"/> for other peers), eE.g.,
          "Call customerservice@example.org".  The semantics of this request are
          that the media stream from channel and
	  the camera Stream Control Transmission Protocol (SCTP) over DTLS
          <xref target="RFC8261" format="default"/> for data
          channels. Specifically, Alice and microphone will only be
          routed through Bob perform a connection DTLS handshake on
          every component which has been cryptographically verified
          (through established by ICE. The total number of
          channels depends on the IdP mechanism or an X.509 certificate amount of muxing; in the DTLS-SRTP
          handshake) as being associated with the stated identity. Note that it
          is unlikely that browsers would have X.509 certificates, but servers
          might.  Browsers servicing such requests SHOULD clearly indicate that
          identity to the user when asking for permission.  The idea behind this
          type of permissions is that a user might have a fairly narrow list of
          peers he is willing to communicate with, e.g., "my mother" rather than
          "anyone most likely case, we
          are using both RTP/RTCP mux and muxing multiple media streams on Facebook". Narrow permissions grants allow the browser to
          do that enforcement.
        </t>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">
              The API MUST provide a mechanism for
          same channel, in which case there is only one DTLS handshake. Once the requesting JS to
              relinquish
          DTLS handshake has completed, the ability keys are exported <xref target="RFC5705" format="default"/> and used to see or modify key SRTP for the media (e.g., via
              MediaStream.record()).  Combined with secure authentication of the
              communicating peer, channels.
        </t>
        <t>
          At this allows point, Alice and Bob know that they share a user set of secure data
          and/or media channels with keys which are not known to be sure any third-party
          attacker. If Alice and Bob authenticated via their IdPs, then they
          also know that the calling
              site signaling service is not accessing or modifying mounting a
          man-in-the-middle attack on their conversion.
            </t>
          </list>
        </t>

        <t>
          <list style="hanging">
            <t hangText="UI Requirement:">
              The UI MUST clearly indicate when the user's camera and microphone
              are traffic. Even if they do not use an
          IdP, as long as they have minimal trust in use.  This indication MUST NOT be suppressable by the JS
              and MUST clearly indicate how signaling service not
          to terminate device access, and
              provide perform a UI means to immediately stop camera/microphone input
              without the JS being able to prevent it.
            </t>
          </list>
        </t>

        <t>
          <list style="hanging">
            <t hangText="UI Requirement:">
              If the UI indication of camera/microphone use man-in-the-middle attack, they know that their
          communications are displayed in secure against the
              browser such signaling service as well (i.e.,
          that minimizing the browser window would hide the
              indication, or the JS creating an overlapping window would hide the indication, then signaling service cannot mount a passive attack on the browser SHOULD stop camera
          communications).
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Communications and microphone
              input when the indication Consent Freshness</name>
        <t>
          From a security perspective, everything from here on in is hidden.  [Note: this may not be
              necessary a little
          anticlimactic: Alice and Bob exchange data protected by the keys
          negotiated by DTLS. Because of the security guarantees discussed in systems
          the previous sections, they know that the communications are non-windows-based but that have good
              notifications support, such as phones.]
            </t>
          </list> encrypted
          and authenticated.
        </t>
        <t>
          <list style="symbols">
            <t>
              Browsers MUST NOT permit permanent screen or application sharing
              permissions
          The one remaining security property we need to be installed as a response establish is "consent
          freshness", i.e., allowing Alice to a JS request for
              permissions. Instead, they must require some other user action
              such as a permissions setting or an application install experience verify that Bob is still prepared
          to grant permission receive her communications so that Alice does not continue to a site.
            </t>
            <t>
              Browsers MUST provide a separate dialog request send
          large traffic volumes to entities which went abruptly offline. ICE
          specifies periodic Session Traversal Utilities for
              screen/application sharing permissions even NAT (STUN) keepalives but only if the media request is made at not flowing.
          Because the same time as camera and microphone.
            </t>

            <t>
              The browser MUST indicate any windows which are currently being
              shared consent issue is more difficult here, we require WebRTC
          implementations to periodically send keepalives.  As described in some unambiguous way. Windows which are
          Section 5.3, these keepalives <bcp14>MUST</bcp14> be based on the consent freshness
          mechanism specified in <xref target="RFC7675" format="default"/>.

<!-- [rfced] Section 4.4:  This document does not visible have a Section 5.3.
Please let us know which section should be cited here.

Original:
 As described in
 Section 5.3, these keepalives MUST
              NOT be shared even if based on the application is being shared. consent freshness
 mechanism specified in [RFC7675]. -->

  If a
          keepalive fails and no new ICE channels can be established, then the
              screen
          session is being shared, then that MUST be indicated. terminated.
        </t>
          </list>
      </section>
    </section>
    <section anchor="sec.sdp-id-attr" numbered="true" toc="default">
      <name>SDP Identity Attribute</name>
      <t>
        The SDP "identity" attribute is a session-level attribute that
        is used by an endpoint to convey its identity assertion to its
        peer. The identity assertion value is encoded as base64, as described
        in <xref target="RFC4648" sectionFormat="of" section="4"/>.
      </t>
      <t>
          Browsers MAY permit
        The procedures in this section are based on the formation assumption
        that the identity assertion of data channels without any direct
          user approval. Because sites can always tunnel data through an endpoint is bound to the
          server, further restrictions on
        fingerprints of the data channel do endpoint. This does not provide any
          additional security.  (See <xref
          target="sec.proposal.communications.consent"/> for a related issue).
        </t>
        <t>
          Implementations which support some form preclude the definition of direct user authentication
          SHOULD also provide a policy by which a user can authorize calls only
        alternative means of binding an assertion to specific communicating peers. Specifically, the implementation
          SHOULD provide endpoint, but such
        means are outside the following interfaces/controls:
        </t>
        <t>
          <list style="symbols">
            <t>
              Allow future calls to scope of this verified user. specification.
      </t>
      <t>
              Allow future calls to any verified user who is in my system
              address book (this only works with address book integration,
        The semantics of
              course).
            </t>
          </list>
        </t>
        <t> multiple "identity" attributes within an
        offer or answer are undefined.  Implementations SHOULD also provide <bcp14>SHOULD</bcp14> only include a different user interface
          indication when calls are
        single "identity" attribute in progress to users whose identities are
          directly verifiable.  <xref target="sec.proposal.comsec"/> provides
          more on this.
        </t>
      </section>

      <section title="Communications Consent" anchor="sec.proposal.communications.consent">

        <t>
          Browser client implementations of WebRTC MUST implement ICE.  Server
          gateway implementations which operate only at public IP addresses MUST
          implement either full ICE an offer or ICE-Lite <xref target="RFC8445"/>.
        </t>
        <t>
          Browser implementations MUST verify reachability via ICE prior to
          sending any non-ICE packets to a given destination.  Implementations
          MUST NOT provide the ICE transaction ID answer, and relying parties
        <bcp14>MAY</bcp14> elect to JavaScript during ignore all but the
          lifetime of first "identity" attribute.
      </t>
      <dl newline="false" spacing="normal">
        <dt>Name:</dt>
        <dd>identity</dd>
        <dt>Value:</dt>
        <dd>identity-assertion</dd>
        <dt>Usage Level:</dt>
        <dd>session</dd>
        <dt>Charset Dependent:</dt>
        <dd>no</dd>
        <dt>Default Value:</dt>
        <dd>N/A</dd>
        <dt>Name:</dt>
        <dd>identity</dd>
      </dl>

<!-- [rfced] Section 5:  Are both "Name:  identity" entries needed in
this list?

Original:
 Name:  identity

 Value:  identity-assertion

 Usage Level:  session

 Charset Dependent:  no

 Default Value:  N/A

 Name:  identity -->

<t>Syntax:</t>
      <sourcecode name="abnf-1" type="abnf" ><![CDATA[
 identity-assertion       = identity-assertion-value
                            *(SP identity-extension)
 identity-assertion-value = base64
 identity-extension       = extension-name [ "=" extension-value ]
 extension-name           = token
 extension-value          = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
                            ; byte-string from [RFC4566]

 <ALPHA and DIGIT as defined in [RFC4566]>
 <base64 as defined in [RFC4566]>
]]></sourcecode>

<t>Example:</t>
<!-- [rfced] Section 5: We have split the transaction (i.e., during <artwork> into 2 pieces: the period when
first has been tagged as <sourcecode type="abnf"> and the ICE
          stack would accept a new response second as
<sourcecode type="sdp" >. See
<https://www.rfc-editor.org/materials/sourcecode-types.txt> for that transaction).  The JS MUST
          NOT be permitted to control the local ufrag and password, though it preferred
list of
          course knows it.
        </t>
        <t> <!-- FIXME: phrasing "type" attributes.  Please review and let us know if ay updates are
needed.

For the definitions of first sentence still awkward -->
          While continuing consent is required, the ICE <xref
          target="RFC8445"/>; Section 10 keepalives use STUN Binding Indications which are
          one-way ALPHA and therefore not sufficient.  The current WG consensus is to
          use ICE Binding Requests for continuing consent freshness. ICE already
          requires that implementations respond DIGIT, RFC 4566 refers to such requests, so RFC 4234, which has
been obsoleted by RFC 5234.  Should this
          approach is maximally compatible. A separate document reference RFC 5234 for ALPHA
and DIGIT?   Also, RFC 4566 will profile the
          ICE timers to soon be used; see <xref target="RFC7675"/>.
        </t>
      </section>

      <section title="IP Location Privacy" anchor="sec.proposal.ip.location.privacy">
        <t>
          A side effect of the default ICE behavior is that the peer learns
          one's IP address, which leaks large amounts of location
          information. This has negative privacy consequences in some
          circumstances. The API requirements in obsoleted by RFC-to-be 8866
<draft-ietf-mmusic-rfc4566bis-37>; should this section are intended document be updated to
          mitigate this issue. Note that these requirements are not intended point to
          protect the user's IP address
RFC 8866?

Original:

      <artwork type="inline"><![CDATA[
Syntax:

  identity-assertion        = identity-assertion-value
                              *(SP identity-extension)
  identity-assertion-value  = base64
  identity-extension        = extension-name [ "=" extension-value ]
  extension-name            = token
  extension-value           = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
                              ; byte-string from a malicious site. In general, [RFC4566]

  <ALPHA and DIGIT as defined in [RFC4566]>
  <base64 as defined in [RFC4566]>

 Example:

  a=identity:\
    eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
    In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
    IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
    aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
-->

<sourcecode name="sdp-1" type="sdp" ><![CDATA[
 a=identity:\
   eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
   In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
   IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
   aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 ]]></sourcecode>

  <aside><t>Note that long lines in the
          site will learn at least a user's server reflexive address from any
          HTTP transaction.  Rather, these requirements example are intended to allow a
          site to cooperate with the user folded to hide the user's IP address from meet the
          other side column
  width constraints of this document; the call. Hiding the user's IP address from backslash ("\") at the server
          requires some sort end of explicit privacy preserving mechanism on
  a line, the
          client (e.g., Tor Browser [https://www.torproject.org/projects/torbrowser.html.en]) carriage return that follows, and
          is out of scope whitespace shall be ignored.</t></aside>
      <t>
         This specification does not define any extensions for this specification. the attribute.
      </t>
      <t>
          <list style="hanging">
            <t hangText="API Requirement:">
         The API MUST provide a mechanism to allow the JS to suppress ICE
              negotiation (though perhaps to allow candidate gathering) until
              the user has decided to answer the call [note: determining when
              the call has been answered identity-assertion value is a question for JSON <xref target="RFC8259" format="default"/> encoded string. The JSON object
         contains two keys: "assertion" and "idp". The "assertion" key value contains
         an opaque string that is consumed by the JS.]  This
              enables a user to prevent a peer from learning their IP address if
              they elect not to answer IdP. The "idp" key value contains a call and also from learning whether
         dictionary with one or two further values that identify the
              user is online.
            </t>
          </list> IdP. See
         <xref target="sec.request-assert" format="default"/> for more details.
      </t>
      <section anchor="sec.sdp-id-attr-oa" numbered="true" toc="default">
        <name>Offer/Answer Considerations</name>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">
              The API MUST provide a mechanism
           This section defines the SDP offer/answer <xref target="RFC3264" format="default"/> considerations for the calling application JS to
              indicate that only TURN candidates are SDP
           "identity" attribute.
        </t>
        <t>
           Within this section, 'initial offer' refers to be used. This prevents the peer from learning one's IP address at all.  This mechanism
              MUST also permit suppression of first offer in the related address field, since
           SDP session that leaks local addresses.
            </t>
          </list> contains an SDP "identity" attribute.
        </t>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">
              The API MUST provide a mechanism for
        <section anchor="sec.sdp-id-attr-oa-inio" numbered="true" toc="default">
          <name>Generating the calling application to
              reconfigure Initial SDP Offer</name>
          <t>
           When an existing call offerer sends an offer, in order to provide its
           identity assertion to add non-TURN candidates.  Taken
              together, this and the previous requirement allow ICE negotiation
              to start immediately on incoming call notification, thus reducing
              post-dial delay, but also to avoid disclosing peer, it includes an "identity" attribute in
           the user's IP
              address until they have decided to answer. They also allow users offer. In addition, the offerer includes one or more SDP
           "fingerprint" attributes.  The "identity" attribute <bcp14>MUST</bcp14> be bound to completely hide their IP address for
           all the duration of "fingerprint" attributes in the
              call. Finally, they allow a mechanism for session
           description.
          </t>
        </section>
        <section anchor="sec.sdp-id-attr-oa-ansa" numbered="true" toc="default">
          <name>Generating an SDP Answer</name>
          <t>
             If the user to optimize
              performance by reconfiguring answerer elects to allow non-TURN candidates during include an active call if "identity" attribute, it follows
             the user decides they no longer need same steps as those in <xref target="sec.sdp-id-attr-oa-inio" format="default"/>.
             The answerer can choose to hide
              their IP address
            </t>
          </list> include or omit an "identity" attribute independently,
             regardless of whether the offerer did so.
          </t>
        </section>
        <section anchor="sec.sdp-id-attr-oa-offa" numbered="true" toc="default">
          <name>Processing an SDP Offer or Answer</name>
          <t>
          Note
             When an endpoint receives an offer or answer that some enterprises may operate proxies and/or NATs designed to
          hide internal IP addresses from contains an "identity"
             attribute, the outside world. WebRTC provides no
          explicit mechanism to allow this function. Either such enterprises
          need answerer can use the attribute information to proxy
             contact the HTTP/HTTPS IdP and modify verify the SDP and/or identity of the JS, or
          there needs to be browser support peer. If the identity
             requires a third-party IdP as described in <xref target="sec.trust-relationships" format="default"/>,
             then that IdP will need to set have been specifically configured.
             If the "TURN-only" policy
          regardless of identity verification fails, the site's preferences. answerer <bcp14>MUST</bcp14> discard the
             offer or answer as malformed.
          </t>
        </section>
        <section title="Communications Security" anchor="sec.proposal.comsec"> anchor="sec.sdp-id-attr-oa-modi" numbered="true" toc="default">
          <name>Modifying the Session</name>
          <t>
          Implementations MUST support SRTP <xref target="RFC3711"/>.
          Implementations MUST support DTLS <xref target="RFC6347"/> and
          DTLS-SRTP <xref target="RFC5763"/><xref target="RFC5764"/> for SRTP
          keying. Implementations MUST support SCTP over
             When modifying a session, if the set of fingerprints is
             unchanged, then the sender <bcp14>MAY</bcp14> send the same "identity" attribute. In
             this case, the established identity <bcp14>MUST</bcp14> be applied to existing DTLS
             connections as well as new connections established using one of those
             fingerprints. Note that <xref
          target="RFC8261"/>.
        </t>
        <t>
          All media channels MUST be secured via SRTP and SRTCP.  Media traffic MUST NOT
          be sent over plain (unencrypted) RTP or RTCP; target="RFC8829" sectionFormat="comma" section="5.2.1"/> requires that is, implementations MUST
          NOT negotiate cipher suites with NULL encryption modes.  DTLS-SRTP
          MUST be offered each media section use the same set of
             fingerprints for every media channel.  WebRTC implementations MUST NOT
          offer SDP Security Descriptions <xref target="RFC4568"/> or select it if offered.
          A SRTP MKI MUST NOT be used.
        </t>
        <t>
          All data channels MUST be secured via DTLS. section.
             If a new "identity" attribute is received, then the receiver <bcp14>MUST</bcp14>
             apply that identity to all existing connections.
          </t>
          <t>
         All Implementations MUST support
             If the set of fingerprints changes, then the sender <bcp14>MUST</bcp14>
             either send a new "identity" attribute or none at all.
             Because a change in fingerprints also causes a new DTLS 1.2 with
             connection to be established, the
          TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite receiver <bcp14>MUST</bcp14> discard
             all previously established identities.
          </t>
        </section>
      </section>
    </section>
    <section anchor="sec.proposal.detailed" numbered="true" toc="default">
      <name>Detailed Technical Description</name>
      <section anchor="sec.proposal.origin" numbered="true" toc="default">
        <name>Origin and Web Security Issues</name>
        <t>
          The basic unit of permissions for WebRTC is the origin <xref target="FIPS186">P-256 curve</xref>.
          Earlier drafts target="RFC6454" format="default"/>. Because the security of this specification required
          DTLS 1.0 with the cipher suite
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at origin depends on
          being able to authenticate content from that origin, the time of this
          writing some implementations do not support DTLS 1.2;
          endpoints which support origin can
          only DTLS 1.2 might encounter
          interoperability issues.
          The DTLS-SRTP protection profile
          SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for
          SRTP.
          Implementations
          MUST favor cipher suites which support (Perfect Forward Secrecy) PFS
          over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
        </t>

        <t>
          Implementations MUST NOT implement DTLS renegotiation and MUST reject
          it with a "no_renegotiation" alert securely established if offered.</t>

        <t>
          Endpoints MUST NOT implement TLS False Start <xref target="RFC7918"/>.</t>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">
              The API MUST generate a new authentication key pair for every new
              call by default.  This data is intended to allow for unlinkability.
            </t>
            <t hangText="API Requirement:">
              The API MUST provide a means to reuse a key pair for calls.  This
              can be used to enable key continuity-based authentication, transferred over HTTPS <xref target="RFC2818" format="default"/>. Thus, clients <bcp14>MUST</bcp14> treat HTTP and
              could be used to amortize key generation costs.
            </t>
            <t hangText="API Requirement:">
              Unless
              the user specifically configures an external key pair, HTTPS origins as
          different
              key pairs MUST be used for each origin. (This avoids creating a
              super-cookie.)
            </t>
            <t hangText="API Requirement:">
              When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain
              the negotiated keying material. permissions domains. Note: This requirement preserves follows directly from the
              end-to-end
          origin security of the media.
            </t>
          </list> model and is stated here merely for clarity.
        </t>
        <t>
          <list style="hanging">
            <t hangText="UI Requirements: ">
              A user-oriented client MUST provide
          Many Web browsers currently forbid by default any active mixed content
          on HTTPS pages. That is, when JavaScript is loaded from an "inspector" interface which
              allows the user to determine HTTP origin
          onto an HTTPS page, an error is displayed and the security characteristics of HTTP content is not
          executed unless the
              media.
            </t>
            <t>
              The following properties SHOULD be displayed "up-front" in user overrides the error. Any browser chrome, i.e., without requiring the user to ask for them:
            </t>
            <t>
              <list style="symbols">
                <t>
                  A client MUST provide a user interface through which
          enforces such a user
                  may determine the security characteristics for
                  currently-displayed audio and video stream(s) policy will also not permit access to WebRTC
          functionality from mixed content pages (because they never display
          mixed content).  Browsers which allow active mixed content <bcp14>MUST</bcp14>
          nevertheless disable WebRTC functionality in mixed content settings.
        </t>
        <t>
                  A client MUST provide a user interface through which
          Note that it is possible for a user
                  may determine page that was not mixed content to
          become mixed content during the security characteristics for transmissions duration of their microphone audio and camera video.
                </t>

                <t>
                  If the far endpoint was directly verified, either via a
                  third-party verifiable X.509 certificate or via call.  The major risk
          here is that the newly arrived insecure JS might redirect media to a Web IdP
                  mechanism (see <xref target="sec.generic.idp"/>)
          location controlled by the "security
                  characteristics" MUST include attacker.  Implementations <bcp14>MUST</bcp14> either
          choose to terminate the verified information.  X.509
                  identities and Web IdP identities have similar semantics and
                  should be displayed in call or display a similar way.
                </t>
              </list>
            </t>
            <t> warning at that point.
        </t>
        <t>
              The following properties are more likely
          Also note that the security architecture depends on the keying material
          not being available to require some
              "drill-down" from move between origins.  But it is assumed that
          the user:
            </t>
            <t>
              <list style="symbols">
                <t>
                  The "security characteristics" MUST indicate identity assertion can be passed to anyone that the cryptographic
                  algorithms in use (For example: "AES-CBC".) page cares to.
        </t>
      </section>
      <section anchor="sec.proposal.device.permissions" numbered="true" toc="default">
        <name>Device Permissions Model</name>
        <t>
                  The "security characteristics" MUST indicate whether PFS is
                  provided.
                </t>

                <t>
                  The "security characteristics" MUST include some mechanism
          Implementations <bcp14>MUST</bcp14> obtain explicit user consent prior to providing
          access to
                  allow an out-of-band verification of the peer, such as a
                  certificate fingerprint or a Short Authentication String (SAS).
                  These are compared by camera and/or microphone. Implementations <bcp14>MUST</bcp14> at
          minimum support the peers to authenticate one another.
                </t>
              </list> following two permissions models for HTTPS
          origins.
        </t>
          </list>
        <ul spacing="normal">
          <li>
              Requests for one-time camera/microphone access.
            </li>
          <li>
              Requests for permanent access.
            </li>
        </ul>
        <t>
          Because HTTP origins cannot be securely established against network
          attackers, implementations <bcp14>MUST</bcp14> refuse all permissions grants for
          HTTP origins.
        </t>
      </section>
    </section>

      <section title="Web-Based Peer Authentication" anchor="sec.generic.idp">
        <t>
          In a number of cases, it is desirable addition, they <bcp14>SHOULD</bcp14> support requests for the endpoint (i.e., the
          browser) to access that promise that
          media from this grant will be able to directly identify the endpoint on the other
          side without trusting the signaling service sent to which they are
          connected. For instance, users may be making a call via a federated
          system where they wish to get direct authentication single communicating peer
          (obviously there could be other requests for other peers), e.g.,
          "Call customerservice@example.org".  The semantics of this request are
          that the other
          side. Alternately, they may media stream from the camera and microphone will only be making a call on
          routed through a site connection which they
          minimally trust (such as a poker site) but to someone who has been cryptographically verified
          (through the IdP mechanism or an
          identity on a site they do trust (such X.509 certificate in the DTLS-SRTP
          handshake) as a social network.)
        </t>
        <t>
          Recently, a number of Web-based identity technologies (OAuth,
          Facebook Connect etc.) have been developed. While being associated with the
          details vary, what these technologies share stated identity. Note that it
          is unlikely that they browsers would have a
          Web-based (i.e., HTTP/HTTPS) X.509 certificates, but servers
          might.  Browsers servicing such requests <bcp14>SHOULD</bcp14> clearly indicate that
          identity provider which attests to Alice's
          identity. For instance, if Alice has an account at example.org, Alice could
          use the example.org identity provider to prove to others that Alice is
          alice@example.org. user when asking for permission.  The development idea behind this
          type of these technologies allows us to
          separate calling from identity provision: Alice could call you on a
          poker site but identify herself as alice@example.org.
        </t>
        <t>
          Whatever the underlying technology, the general principle permissions is that the
          party which is being authenticated is NOT the signaling site but
          rather the a user (and their browser). Similarly, the relying party might have a fairly narrow list of
          peers he is willing to communicate with, e.g., "my mother" rather than
          "anyone on Facebook". Narrow permissions grants allow the browser and not the signaling site.  Thus, the browser MUST
          generate to
          do that enforcement.
        </t>
        <dl newline="false" spacing="normal">
          <dt>API Requirement:</dt>
          <dd>
              The API <bcp14>MUST</bcp14> provide a mechanism for the input requesting JS to
              relinquish the IdP assertion process and
          display ability to see or modify the results media (e.g., via
              MediaStream.record()).  Combined with secure authentication of the verification process to the user
          in
              communicating peer, this allows a way which cannot user to be imitated by sure that the calling site.
        </t>
        <t>
              site is not accessing or modifying their conversion.
            </dd>
        </dl>
        <dl newline="false" spacing="normal">
          <dt>UI Requirement:</dt>
          <dd>
              The mechanisms defined UI <bcp14>MUST</bcp14> clearly indicate when the user's camera and microphone
              are in this document do not require use.  This indication <bcp14>MUST NOT</bcp14> be suppressible by the browser to
          implement any particular identity protocol or JS
              and <bcp14>MUST</bcp14> clearly indicate how to support any
          particular IdP. Instead, this document provides a generic interface
          which any IdP can implement. Thus, new IdPs terminate device access, and protocols can be
          introduced without change to either the browser or the calling
          service. This avoids the need to make a commitment to any particular
          identity protocol, although browsers may opt to directly implement
          some identity protocols in order to
              provide superior performance or a UI
          properties.
        </t>

        <section title="Trust Relationships: IdPs, APs, and RPs" anchor="sec.trust-relationships">
          <t>
            Any federated identity protocol has three major participants:
          </t>
          <t>
            <list style="hanging">
              <t hangText="Authenticating Party (AP):">
                The entity which is trying means to establish its identity.
              </t>
              <t>
              </t>

              <t hangText="Identity Provider (IdP):">
                The entity which is vouching for immediately stop camera/microphone input
              without the AP's identity.
              </t>

              <t>
              </t>

              <t hangText="Relying Party (RP):">
                The entity which is trying JS being able to verify the AP's identity.
              </t>
            </list>
          </t>
          <t>
            The AP and prevent it.
            </dd>
        </dl>
        <dl newline="false" spacing="normal">
          <dt>UI Requirement:</dt>
          <dd>
              If the IdP have an account relationship UI indication of some kind: the AP
            registers with the IdP and camera/microphone use is able to subsequently authenticate
            directly to displayed in the IdP (e.g., with a password). This means
              browser such that minimizing the browser must somehow know which IdP(s) window would hide the user has
              indication, or the JS creating an account
            relationship with.  This can either be something that overlapping window would hide
              the user
            configures into indication, then the browser or that is configured at the calling
            site <bcp14>SHOULD</bcp14> stop camera and then provided to the PeerConnection by the Web application
            at the calling site. The use case for having this information
            configured into microphone
              input when the browser indication is that the user may "log into" the
            browser to bind it to some identity. hidden.  (Note: This is becoming common in new
            browsers. However, it should also may not be possible for
              necessary in systems that are non-windows-based but that have good
              notifications support, such as phones.)
            </dd>
        </dl>

<!-- [rfced] Section 6.2:  Is the IdP
            information bullet list after this "UI
Requirement:" list item supposed to simply be provided by the calling application.
          </t>
          <t>
            At a high level there are two kinds of IdPs:
          </t>
          <t>
            <list style="hanging">
              <t hangText="Authoritative: ">
                IdPs which have verifiable control of some section of "sub-list" (as was done,
for example, after the
                identity space. For instance, "UI Requirements:" list item in Section 6.5),
or should it remain as a separate list?

Original:
 UI Requirement:  If the realm of e-mail, the
                operator of "example.com" has complete control UI indication of the namespace
                ending camera/microphone use are
    displayed in "@example.com". Thus, "alice@example.com" is whoever
                the operator says it is. Examples of systems with authoritative
                identity providers include DNSSEC, RFC 4474, and Facebook
                Connect (Facebook identities only make sense within the context
                of browser such that minimizing the Facebook system).
              </t>

              <t>
              </t>
              <t hangText="Third-Party: ">
                IdPs which don't have control of their section of browser window
    would hide the identity
                space but instead verify user's identities via some unspecified
                mechanism and then attest to it. Because indication, or the IdP doesn't
                actually control JS creating an overlapping
    window would hide the namespace, RPs need to trust that indication, then the IdP
                is correctly verifying AP identities, browser SHOULD stop
    camera and there can potentially
                be multiple IdPs attesting to the same section of the identity
                space. Probably microphone input when the best-known example of a third-party identity
                provider indication is SSL/TLS certificates, where there hidden.  [Note:
    this may not be necessary in systems that are a large number of
                CAs all of whom can attest to any domain name.
              </t>
            </list>
          </t>

          <t>
            If non-windows-based
    but that have good notifications support, such as phones.]

 o  Browsers MUST NOT permit permanent screen or application sharing
    permissions to be installed as a response to a JS request for
    permissions.  Instead, they must require some other user action
    such as a permissions setting or an AP is authenticating via application install experience
    to grant permission to a site.
... -->

        <ul spacing="normal">
          <li>
              Browsers <bcp14>MUST NOT</bcp14> permit permanent screen or application sharing
              permissions to be installed as a response to a JS request for
              permissions. Instead, they must require some other user action
              such as a permissions setting or an authoritative IdP, then the RP
            does not need application install experience
              to explicitly configure trust in the IdP at all.  The
            identity mechanism can directly verify that grant permission to a site.
            </li>
          <li>
              Browsers <bcp14>MUST</bcp14> provide a separate dialog request for
              screen/application sharing permissions even if the IdP indeed media request
              is made at the
            relevant identity assertion (a function provided by same time as camera and microphone.

<!-- [rfced] Section 6.2:  Please clarify the mechanisms
            in this document), meaning of "as camera
and any assertion it makes about an identity microphone."

Original:
 o  Browsers MUST provide a separate dialog request for
            which it is authoritative is directly verifiable. Note that this
            does not mean that screen/
    application sharing permissions even if the IdP might not lie, but that media request is a
            trustworthiness judgement that the user can make made
    at the same time he
            looks at as camera and microphone. -->

            </li>
          <li>
              The browser <bcp14>MUST</bcp14> indicate any windows which are currently being
              shared in some unambiguous way. Windows which are not visible <bcp14>MUST
              NOT</bcp14> be shared even if the identity.
          </t>
          <t>
            By contrast, if an AP application is authenticating via a third-party IdP, being shared.  If the
            RP needs to explicitly trust
              screen is being shared, then that IdP (hence <bcp14>MUST</bcp14> be indicated.
            </li>
        </ul>
        <t>
          Browsers <bcp14>MAY</bcp14> permit the need for an
            explicit trust anchor list in PKI-based SSL/TLS clients). The list formation of trustable IdPs needs to be configured directly into data channels without any direct
          user approval. Because sites can always tunnel data through the browser,
            either by
          server, further restrictions on the data channel do not provide any
          additional security.  (See <xref target="sec.proposal.communications.consent" format="default"/> for a related issue.)
        </t>
        <t>
          Implementations which support some form of direct user or potentially authentication
          <bcp14>SHOULD</bcp14> also provide a policy by which a user can authorize calls only
          to specific communicating peers. Specifically, the browser manufacturer. This implementation
          <bcp14>SHOULD</bcp14> provide the following interfaces/controls:
        </t>
        <ul spacing="normal">
          <li>
              Allow future calls to this verified user.
            </li>
          <li>
              Allow future calls to any verified user who is a significant advantage in my system
              address book (this only works with address book integration, of authoritative IdPs and implies that if
            third-party IdPs
              course).
            </li>
        </ul>
        <t>
          Implementations <bcp14>SHOULD</bcp14> also provide a different user interface
          indication when calls are in progress to be supported, the potential number needs to
            be fairly small. users whose identities are
          directly verifiable.  <xref target="sec.proposal.comsec" format="default"/> provides
          more on this.
        </t>
      </section>
      <section title="Overview anchor="sec.proposal.communications.consent" numbered="true" toc="default">
        <name>Communications Consent</name>
        <t>
          Browser client implementations of Operation" anchor="sec.overview"> WebRTC <bcp14>MUST</bcp14> implement ICE.  Server
          gateway implementations which operate only at public IP addresses <bcp14>MUST</bcp14>
          implement either full ICE or ICE-Lite <xref target="RFC8445" format="default"/>.
        </t>
        <t>
            In order
          Browser implementations <bcp14>MUST</bcp14> verify reachability via ICE prior to
          sending any non-ICE packets to a given destination.  Implementations
          <bcp14>MUST NOT</bcp14> provide security without trusting the calling site, ICE transaction ID to JavaScript during the
            PeerConnection component
          lifetime of the browser must interact directly with transaction (i.e., during the IdP. period when the ICE
          stack would accept a new response for that transaction).  The details JS <bcp14>MUST
          NOT</bcp14> be permitted to control the local ufrag and password, though it of
          course knows it.
        </t>
        <t>
          While continuing consent is required, the mechanism ICE <xref target="RFC8445" sectionFormat="comma" section="10"/> keepalives use STUN Binding Indications which are described in
          one-way and therefore not sufficient.

<!-- [rfced] Section 6.3:  Please advise regarding the W3C API
            specification, but following:

1. We do not see the general idea is word "keepalive" in Section 10 of RFC 8445, but
we do see it in 8445's Section 11.  Please confirm that "Section 10"
is correct here and will be clear to readers.

2. We found the PeerConnection
            component downloads JS from a specific location on use of "which" confusing here.  Are all STUN Binding
Indications one-way and therefore not sufficient (in which case "STUN
Binding Indications, which are" would be correct), or only some (in
which case "STUN Binding Indications that are" would be correct)?

3. We found this comment, in the IdP dictated
            by XML file, just prior to this
sentence:  "FIXME: phrasing of first sentence still awkward."
Please let us know how/if you want to fix the IdP domain name. That JS (the "IdP proxy") runs in an
            isolated security context within phrasing.

Original:
 While continuing consent is required, the browser ICE [RFC8445]; Section 10
 keepalives use STUN Binding Indications which are one-way and the PeerConnection
            talks
 therefore not sufficient. -->

  The current WG consensus is to it via a secure message passing channel.
          </t>
          <t>
            Note
          use ICE Binding Requests for continuing consent freshness. ICE already
          requires that there are two logically implementations respond to such requests, so this
          approach is maximally compatible. A separate functions here:
            <list style="symbols">
              <t>
                Identity assertion generation. document will profile the
          ICE timers to be used; see <xref target="RFC7675" format="default"/>.
        </t>
      </section>
      <section anchor="sec.proposal.ip.location.privacy" numbered="true" toc="default">
        <name>IP Location Privacy</name>
        <t>
                Identity assertion verification.
              </t>
            </list>
          </t>
          <t>
            The same IdP JS "endpoint"
          A side effect of the default ICE behavior is used for both functions but that the peer learns
          one's IP address, which leaks large amounts of course location
          information. This has negative privacy consequences in some
          circumstances. The API requirements in this section are intended to
          mitigate this issue. Note that these requirements are not intended to
          protect the user's IP address from a given IdP might behave differently malicious site. In general, the
          site will learn at least a user's server-reflexive address from any
          HTTP transaction.

<!-- [rfced] Section 6.4:  Per author feedback for RFC 8839 and load new JS per
other documents in this cluster, we hyphenated the term "server
reflexive".  Please let us know any objections.

Original:
 In general, the site will learn at
 least a user's server reflexive address from any HTTP transaction.

Currently:
 In general, the site will learn at
 least a user's server-reflexive address from any HTTP transaction. -->

  Rather, these requirements are intended to perform one
            function or allow a
          site to cooperate with the other.
          </t>
          <figure>
            <artwork><![CDATA[
     +--------------------------------------+
     | user to hide the user's IP address from the
          other side of the call. Hiding the user's IP address from the server
          requires some sort of explicit privacy-preserving mechanism on the
          client (e.g., Tor Browser                              |
     |                                      |
     | +----------------------------------+ |
     | | https://calling-site.example.com | |
     | |                                  | |
     | |        Calling JS Code           | |
     | |               ^                  | |
     | +---------------|------------------+ |
     |                 | API Calls          |
     |                 v                    |
     |          PeerConnection              |
     |                 ^                    |
     |                 | <eref brackets="angle" target="https://www.torproject.org/projects/torbrowser.html.en"/>) and
          is out of scope for this specification.
        </t>
        <dl newline="false" spacing="normal">
          <dt>API Requirement:</dt>
          <dd>
              The API Calls          |
     |     +-----------|-------------+      |   +---------------+
     |     |           v             |      |   |               |
     |     | <bcp14>MUST</bcp14> provide a mechanism to allow the JS to suppress ICE
              negotiation (though perhaps to allow candidate gathering) until
              the user has decided to answer the call. (Note: Determining when
              the call has been answered is a question for the JS.)  This
              enables a user to prevent a peer from learning their IP address if
              they elect not to answer a call and also from learning whether the
              user is online.
            </dd>
        </dl>
        <dl newline="false" spacing="normal">
          <dt>API Requirement:</dt>
          <dd>
              The API <bcp14>MUST</bcp14> provide a mechanism for the calling application JS to
              indicate that only TURN candidates are to be used. This prevents
              the peer from learning one's IP address at all.  This mechanism
              <bcp14>MUST</bcp14> also permit suppression of the related address field, since
              that leaks local addresses.
            </dd>
        </dl>
        <dl newline="false" spacing="normal">
          <dt>API Requirement:</dt>
          <dd>
              The API <bcp14>MUST</bcp14> provide a mechanism for the calling application to
              reconfigure an existing call to add non-TURN candidates.  Taken
              together, this and the previous requirement allow ICE negotiation
              to start immediately on incoming call notification, thus reducing
              post-dial delay, but also to avoid disclosing the user's IP
              address until they have decided to answer. They also allow users
              to completely hide their IP address for the duration of the
              call. Finally, they allow a mechanism for the user to optimize
              performance by reconfiguring to allow non-TURN candidates during
              an active call if the user decides they no longer need to hide
              their IP address.
            </dd>
        </dl>
        <t>
          Note that some enterprises may operate proxies and/or NATs designed to
          hide internal IP addresses from the outside world. WebRTC provides no
          explicit mechanism to allow this function. Either such enterprises
          need to proxy the HTTP/HTTPS and modify the SDP and/or the JS, or
          there needs to be browser support to set the "TURN-only" policy
          regardless of the site's preferences.
        </t>
      </section>
      <section anchor="sec.proposal.comsec" numbered="true" toc="default">
        <name>Communications Security</name>
        <t>
          Implementations <bcp14>MUST</bcp14> support SRTP <xref target="RFC3711" format="default"/>.
          Implementations <bcp14>MUST</bcp14> support DTLS <xref target="RFC6347" format="default"/> and
          DTLS-SRTP <xref target="RFC5763" format="default"/> <xref target="RFC5764" format="default"/> for SRTP
          keying. Implementations <bcp14>MUST</bcp14> support SCTP over DTLS <xref target="RFC8261" format="default"/>.
        </t>
        <t>
          All media channels <bcp14>MUST</bcp14> be secured via SRTP and the
	  Secure Real-time Transport Control Protocol (SRTCP).  Media traffic <bcp14>MUST NOT</bcp14>
          be sent over plain (unencrypted) RTP or RTCP; that is, implementations <bcp14>MUST
          NOT</bcp14> negotiate cipher suites with NULL encryption modes.  DTLS-SRTP
          <bcp14>MUST</bcp14> be offered for every media channel.  WebRTC implementations <bcp14>MUST NOT</bcp14>
          offer SDP security descriptions <xref target="RFC4568" format="default"/> or select it if offered.
          An SRTP Master Key Identifier (MKI) <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t>
          All data channels <bcp14>MUST</bcp14> be secured via DTLS.
        </t>
        <t>
         All implementations <bcp14>MUST</bcp14> support DTLS 1.2 with the
          TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the
          <xref target="FIPS186" format="default">P-256 curve</xref>.
          Earlier drafts of this specification required
          DTLS 1.0 with the cipher suite
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this
          writing some implementations do not support DTLS 1.2;
          endpoints that support only DTLS 1.2 might encounter
          interoperability issues.
          The DTLS-SRTP protection profile
          SRTP_AES128_CM_HMAC_SHA1_80 <bcp14>MUST</bcp14> be supported for
          SRTP.
          Implementations
          <bcp14>MUST</bcp14> favor cipher suites which support Perfect Forward Secrecy (PFS)
          over non-PFS cipher suites and <bcp14>SHOULD</bcp14> favor
	  Authenticated Encryption with Associated Data (AEAD) over non-AEAD cipher suites.
        </t>
        <t>
          Implementations <bcp14>MUST NOT</bcp14> implement DTLS renegotiation and <bcp14>MUST</bcp14> reject
          it with a "no_renegotiation" alert if offered.</t>
        <t>
          Endpoints <bcp14>MUST NOT</bcp14> implement TLS False Start <xref target="RFC7918" format="default"/>.</t>
        <dl newline="false" spacing="normal">
          <dt>API Requirement:</dt>
          <dd>
              The API <bcp14>MUST</bcp14> generate a new authentication key pair for every new
              call by default.  This is intended to allow for unlinkability.
            </dd>
          <dt>API Requirement:</dt>
          <dd>
              The API <bcp14>MUST</bcp14> provide a means to reuse a key pair for calls.  This
              can be used to enable key continuity-based authentication, and
              could be used to amortize key generation costs.
            </dd>
          <dt>API Requirement:</dt>
          <dd>
              Unless
              the user specifically configures an external key pair, different
              key pairs <bcp14>MUST</bcp14> be used for each origin. (This avoids creating a
              super-cookie.)
            </dd>
          <dt>API Requirement:</dt>
          <dd>
              When DTLS-SRTP is used, the API <bcp14>MUST NOT</bcp14> permit the JS to obtain
              the negotiated keying material. This requirement preserves the
              end-to-end security of the media.
            </dd>
        </dl>
        <dl newline="false" spacing="normal">
          <dt>UI Requirements:</dt>
          <dd>
              A user-oriented client <bcp14>MUST</bcp14> provide an "inspector" interface which
              allows the user to determine the security characteristics of the
              media.
            </dd>
          <dt/>
          <dd>
              The following properties <bcp14>SHOULD</bcp14> be displayed "up-front" in the
              browser chrome, i.e., without requiring the user to ask for them:
            </dd>
          <dt/>
          <dd>
            <ul spacing="normal">
              <li>
                  A client <bcp14>MUST</bcp14> provide a user interface through which a user
                  may determine the security characteristics for
                  currently displayed audio and video stream(s).
                </li>
              <li>
                  A client <bcp14>MUST</bcp14> provide a user interface through which a user
                  may determine the security characteristics for transmissions
                  of their microphone audio and camera video.
                </li>
              <li>
                  If the far endpoint was directly verified, either via a
                  third-party verifiable X.509 certificate or via a Web IdP
                  mechanism (see <xref target="sec.generic.idp" format="default"/>), the "security
                  characteristics" <bcp14>MUST</bcp14> include the verified information.  X.509
                  identities and Web IdP identities have similar semantics and
                  should be displayed in a similar way.
                </li>
            </ul>
          </dd>
          <dt/>
          <dd>
              The following properties are more likely to require some
              "drill-down" from the user:
            </dd>
          <dt/>
          <dd>
            <ul spacing="normal">
              <li>
                  The "security characteristics" <bcp14>MUST</bcp14> indicate the cryptographic
                  algorithms in use (for example, "AES-CBC").
                </li>
              <li>
                  The "security characteristics" <bcp14>MUST</bcp14> indicate whether PFS is
                  provided.
                </li>
              <li>
                  The "security characteristics" <bcp14>MUST</bcp14> include some mechanism to
                  allow an out-of-band verification of the peer, such as a
                  certificate fingerprint or a Short Authentication String (SAS).
                  These are compared by the peers to authenticate one another.
                </li>
            </ul>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="sec.generic.idp" numbered="true" toc="default">
      <name>Web-Based Peer Authentication</name>
      <t>
          In a number of cases, it is desirable for the endpoint (i.e., the
          browser) to be able to directly identify the endpoint on the other
          side without trusting the signaling service to which they are
          connected. For instance, users may be making a call via a federated
          system where they wish to get direct authentication of the other
          side. Alternately, they may be making a call on a site which they
          minimally trust (such as a poker site) but to someone who has an
          identity on a site they do trust (such as a social network).
      </t>
      <t>
          Recently, a number of Web-based identity technologies (OAuth,
          Facebook Connect, etc.) have been developed. While the
          details vary, what these technologies share is that they have a
          Web-based (i.e., HTTP/HTTPS) identity provider that attests to Alice's
          identity. For instance, if Alice has an account at example.org, Alice could
          use the example.org identity provider to prove to others that Alice is
          alice@example.org.  The development of these technologies allows us to
          separate calling from identity provision: Alice could call you on a
          poker site but identify herself as alice@example.org.
      </t>
      <t>
          Whatever the underlying technology, the general principle is that the
          party which is being authenticated is NOT the signaling site but
          rather the user (and their browser). Similarly, the relying party is
          the browser and not the signaling site.  Thus, the browser <bcp14>MUST</bcp14>
          generate the input to the IdP assertion process and
          display the results of the verification process to the user
          in a way which cannot be imitated by the calling site.
      </t>
      <t>
          The mechanisms defined in this document do not require the browser to
          implement any particular identity protocol or to support any
          particular IdP. Instead, this document provides a generic interface
          which any IdP can implement. Thus, new IdPs and protocols can be
          introduced without change to either the browser or the calling
          service. This avoids the need to make a commitment to any particular
          identity protocol, although browsers may opt to directly implement
          some identity protocols in order to provide superior performance or UI
          properties.
      </t>
      <section anchor="sec.trust-relationships" numbered="true" toc="default">
        <name>Trust Relationships: IdPs, APs, and RPs</name>
        <t>
            Any federated identity protocol has three major participants:
        </t>
        <dl newline="false" spacing="normal">
          <dt>Authenticating Party (AP):</dt>
          <dd>
                The entity which is trying to establish its identity.
              </dd>
          <dt>Identity Provider (IdP):</dt>
          <dd>
                The entity which is vouching for the AP's identity.
              </dd>
          <dt>Relying Party (RP):</dt>
          <dd>
                The entity which is trying to verify the AP's identity.
              </dd>
        </dl>
        <t>
            The AP and the IdP have an account relationship of some kind: the AP
            registers with the IdP and is able to subsequently authenticate
            directly to the IdP (e.g., with a password). This means that the
            browser must somehow know which IdP(s) the user has an account
            relationship with.  This can either be something that the user
            configures into the browser or that is configured at the calling
            site and then provided to the PeerConnection by the Web application
            at the calling site. The use case for having this information
            configured into the browser is that the user may "log into" the
            browser to bind it to some identity. This is becoming common in new
            browsers. However, it should also be possible for the IdP Proxy         |<-------->|   Identity    |
     |     |                         |      |   |   Provider    |
     |     | https://idp.example.org |      |   |               |
     |     +-------------------------+      |   +---------------+
     |                                      |
     +--------------------------------------+
]]></artwork>
          </figure>
            information to simply be provided by the calling application.
        </t>
        <t>
            When
            At a high level, there are two kinds of IdPs:
        </t>
        <dl newline="false" spacing="normal">
          <dt>Authoritative:</dt>
          <dd>
                IdPs which have verifiable control of some section of the PeerConnection object wants
                identity space. For instance, in the realm of email, the
                operator of "example.com" has complete control of the namespace
                ending in "@example.com". Thus, "alice@example.com" is whoever
                the operator says it is. Examples of systems with authoritative
                identity providers include DNSSEC, RFC 4474, and Facebook
                Connect (Facebook identities only make sense within the context
                of the Facebook system).

<!-- [rfced] Section 7.1:  May we cite RFC 8224 (which obsoletes
RFC 4474) here instead (with brackets, so that a hyperlink will be
available for the reader) and list it under Informative References?

Original:
 Examples of systems with authoritative
 identity providers include DNSSEC, RFC 4474, and Facebook Connect
 (Facebook identities only make sense within the context of the
 Facebook system).

Possibly:
 Examples of systems with authoritative
 identity providers include DNSSEC, an identity system for SIP
 (see [RFC8224]), and Facebook Connect (Facebook identities only make
 sense within the context of the Facebook system).
...

 [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
            "Authenticated Identity Management in the Session
            Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224,
            February 2018, <https://www.rfc-editor.org/info/rfc8224>. -->

              </dd>
          <dt>Third-Party:</dt>
          <dd>
                IdPs which don't have control of their section of the identity
                space but instead verify a user's identity via some unspecified
                mechanism and then attest to interact with the IdP, it. Because the
            sequence of events is as follows:
            <list style="numbers">
              <t>
                The browser (the PeerConnection component) instantiates an IdP
                proxy. This allows doesn't
                actually control the IdP namespace, RPs need to load whatever JS trust that the IdP
                is necessary into correctly verifying AP identities, and there can potentially
                be multiple IdPs attesting to the proxy.  The resulting code runs in same section of the IdP's security
                context.
              </t> identity
                space. Probably the best-known example of a third-party identity
                provider is SSL/TLS certificates, where there are a large number of
                certification authorities (CAs) all of whom can attest to any domain name.
              </dd>
        </dl>
        <t>
                The IdP registers
            If an object with AP is authenticating via an authoritative IdP, then the browser that conforms RP
            does not need to
                the API defined explicitly configure trust in <xref target="webrtc-api"/>.
              </t>
              <t>
                The browser invokes methods on the object registered by the IdP
                proxy to create or at all.  The
            identity mechanism can directly verify that the IdP indeed made the
            relevant identity assertions.
              </t>
            </list>
          </t>
          <t>
            This approach allows us to decouple assertion (a function provided by the browser from mechanisms
            in this document), and any particular assertion it makes about an identity provider; for
            which it is authoritative is directly verifiable. Note that this
            does not mean that the browser need only know how to load IdP might not lie, but that is a
            trustworthiness judgement that the IdP's
            JavaScript--the location of which user can make at the time he
            looks at the identity.
        </t>
        <t>
            By contrast, if an AP is determined based on authenticating via a third-party IdP, the IdP's
            identity--and
            RP needs to call explicitly trust that IdP (hence the generic API need for requesting and verifying
            identity assertions. an
            explicit trust anchor list in PKI-based SSL/TLS clients). The IdP provides whatever logic is necessary list
            of trustable IdPs needs to
            bridge be configured directly into the generic protocol to browser,
            either by the user or potentially by the IdP's specific
            requirements. Thus, a single browser can support any number manufacturer. This
            is a significant advantage of
            identity protocols, including being forward compatible with authoritative IdPs
            which did not exist at the time and implies that if
            third-party IdPs are to be supported, the browser was written. potential number needs to
            be fairly small.
        </t>
      </section>
      <section title="Items for Standardization" anchor="sec.standardized"> anchor="sec.overview" numbered="true" toc="default">
        <name>Overview of Operation</name>
        <t>
            There are two parts
            In order to this work:
          </t>
          <t>
            <list style="symbols">
              <t>
                The precise information from provide security without trusting the signaling message that calling site, the
            PeerConnection component of the browser must be
                cryptographically bound to interact directly with
            the user's identity and a mechanism
                for carrying assertions in JSEP messages. This is specified in
                <xref target="sec.jsep-binding"/>.
              </t>

              <t> IdP. The interface to details of the IdP, which is defined mechanism are described in the companion W3C
                WebRTC API specification <xref target="webrtc-api"/>.
              </t>
            </list>
          </t>
          <t>
            The WebRTC API specification also defines JavaScript interfaces that
            the calling application can use to specify which IdP to use.  That API also provides access to the assertion-generation capability and
            specification, but the status of general idea is that the validation process.
          </t>
        </section>

        <section title="Binding Identity Assertions to JSEP Offer/Answer Transactions" anchor="sec.jsep-binding">

          <t>
            An identity assertion binds PeerConnection
            component downloads JS from a specific location on the user's identity (as asserted IdP dictated
            by the
            IdP) to IdP domain name. That JS (the "IdP proxy") runs in an
            isolated security context within the SDP offer/answer exchange browser, and specifically to the
            media. In order to achieve this, the PeerConnection must provide the
            DTLS-SRTP fingerprint to be bound
            talks to the identity. This is provided
            as a JavaScript object (also known as a dictionary or hash) with it via a
            single <spanx style="verb">fingerprint</spanx> key, as shown below: secure message passing channel.
        </t>
          <figure>
            <artwork><![CDATA[
  {
    "fingerprint":
      [
        { "algorithm": "sha-256",
          "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" },
        { "algorithm": "sha-1",
          "digest": "74:E9:76:C8:19:...:F4:45:6B" }
      ]
  }
]]></artwork>
          </figure>
        <t>
            Note that there are two logically separate functions here:
        </t>
        <ul spacing="normal">
          <li>
                Identity assertion generation.
              </li>
          <li>
                Identity assertion verification.
              </li>
        </ul>
        <t>
            The <spanx style="verb">fingerprint</spanx> value same IdP JS "endpoint" is an array used for both functions, but of
            objects.  Each object in the array contains <spanx
            style="verb">algorithm</spanx> course
            a given IdP might behave differently and <spanx
            style="verb">digest</spanx> values, which correspond directly load new JS to perform one
            function or the algorithm and digest values in the <spanx
            style="verb">fingerprint</spanx> attribute of the SDP <xref
            target="RFC8122"/>. other.
        </t>
          <t>
            This object is encoded in a <xref target="RFC8259">JSON</xref>
            string for passing to the IdP.  The identity assertion returned by
            the IdP, which is encoded in
        <artwork name="" type="" align="left" alt=""><![CDATA[
     +--------------------------------------+
     | Browser                              |
     |                                      |
     | +----------------------------------+ |
     | | https://calling-site.example.com | |
     | |                                  | |
     | |        Calling JS Code           | |
     | |               ^                  | |
     | +---------------|------------------+ |
     |                 | API Calls          |
     |                 v                    |
     |          PeerConnection              |
     |                 ^                    |
     |                 | API Calls          |
     |     +-----------|-------------+      |   +---------------+
     |     |           v             |      |   |               |
     |     |       IdP Proxy         |<-------->|   Identity    |
     |     |                         |      |   |   Provider    |
     |     | https://idp.example.org |      |   |               |
     |     +-------------------------+      |   +---------------+
     |                                      |
     +--------------------------------------+ ]]></artwork>
        <t>
            When the <spanx
            style="verb">identity</spanx> attribute, is a JSON PeerConnection object that is
            encoded as described in <xref target="sec.carry-assertion"/>.
          </t>
          <t>
            This structure does not need wants to be interpreted by interact with the IdP or IdP, the
            IdP proxy. It
            sequence of events is consumed solely by the RP's browser.  The IdP
            merely treats it as an opaque value to be attested to.  Thus, new
            parameters can be added to the assertion without modifying the
            IdP. follows:
        </t>

          <section title="Carrying Identity Assertions" anchor="sec.carry-assertion">
            <t>
              Once
        <ol spacing="normal" type="1">
          <li>
                The browser (the PeerConnection component) instantiates an IdP has generated an assertion (see <xref
              target="sec.request-assert"/>), it is attached to the SDP
              offer/answer message.
                proxy. This is done by adding a new 'identity'
              attribute to the SDP. The sole contents of this value is the
              identity assertion.  The identity assertion produced by allows the IdP to load whatever JS is
              encoded necessary into a UTF-8 JSON text, then <xref
              target="RFC4648">Base64-encoded</xref> to produce this string.
              For example:
            </t>
            <figure>
              <artwork><![CDATA[
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=fingerprint:sha-1 \
  4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:\
  eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
  In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
  IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
  aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
a=...
t=0 0
m=audio 6056 RTP/SAVP 0
a=sendrecv
...

  Note that long lines in the example are folded to meet the column
  width constraints of this document; the backslash ("\") at the end of
  a line, the carriage return that follows, and whitespace shall be ignored.

]]></artwork>
            </figure>
            <t>
              The 'identity' attribute attests to all <spanx
              style="verb">fingerprint</spanx> attributes in
                the session
              description. It is therefore a session-level attribute.
            </t>
            <t>
              Multiple <spanx style="verb">fingerprint</spanx> values can be
              used to offer alternative certificates for a peer. proxy.  The <spanx
              style="verb">identity</spanx> attribute MUST include all
              fingerprint values that are included resulting code runs in <spanx
              style="verb">fingerprint</spanx> attributes of the session
              description.
            </t>
            <t> IdP's security
                context.
              </li>
          <li>
                The RP IdP registers an object with the browser MUST verify that conforms to
                the in-use certificate for a DTLS
              connection is API defined in <xref target="webrtc-api" format="default"/>.
              </li>
          <li>
                The browser invokes methods on the set of fingerprints returned from the IdP
              when verifying an assertion.
            </t>
          </section>
        </section>

            <section title="Determining object registered by the IdP URI" anchor="sec.idp-uri">
                proxy to create or verify identity assertions.
              </li>
        </ol>
        <t>
                In order
            This approach allows us to ensure that the IdP is under control of decouple the domain
                owner rather than someone who merely has an account on browser from any particular
            identity provider; the
                domain owner's server (e.g., in shared hosting scenarios), browser need only know how to load the
                IdP IdP's
            JavaScript is hosted at a deterministic -- the location of which is determined based on the IdP's domain name.  Each IdP proxy instance is associated
                with two values:
              </t>
              <t>
                <list style="hanging">
                  <t hangText="Authority:">
                       The <xref target="RFC3986"> authority</xref> at which
            identity -- and to call the
                       IdP's service is hosted.
                  </t>
                  <t hangText="protocol:"> generic API for requesting and verifying
            identity assertions. The specific IdP protocol which the IdP provides whatever logic is using. This is a
                    completely opaque IdP-specific string, but allows an IdP necessary to
                    implement two protocols in parallel. This value may be
            bridge the
                    empty string.  If no value for generic protocol is provided, to the IdP's specific
            requirements. Thus, a value single browser can support any number of "default" is used.
                  </t>
                </list>
              </t>
              <t>
                Each IdP MUST serve its initial entry page (i.e.,
            identity protocols, including being forward compatible with IdPs
            which did not exist at the one loaded
                by time the IdP proxy) browser was written.
        </t>
      </section>
      <section anchor="sec.standardized" numbered="true" toc="default">
        <name>Items for Standardization</name>
        <t>
            There are two parts to this work:
        </t>
        <ul spacing="normal">
          <li>
                The precise information from the signaling message that must be
                cryptographically bound to the user's identity and a mechanism
                for carrying assertions in JavaScript Session Establishment
		Protocol (JSEP) messages. This is specified in
                <xref target="RFC5785">well-known
                URI</xref>. target="sec.jsep-binding" format="default"/>.
              </li>
          <li>
                The well-known URI for an IdP proxy interface to the IdP, which is formed from defined in the following URI components:
                <list style="numbers">
                  <t>
                    The scheme, "https:".  An IdP MUST be loaded using companion W3C
                WebRTC API specification <xref
                    target="RFC2818">HTTPS</xref>.
                  </t> target="webrtc-api" format="default"/>.
              </li>
        </ul>
        <t>
            The <xref target="RFC3986">authority</xref>.  As noted above, WebRTC API specification also defines JavaScript interfaces that
            the authority MAY contain a  non-default port number or
                    userinfo sub-component.  Both are removed when determining
                    if an asserted identity matches calling application can use to specify which IdP to use.  That
            API also provides access to the name assertion-generation capability and
            the status of the IdP. validation process.
        </t>
      </section>
      <section anchor="sec.jsep-binding" numbered="true" toc="default">
        <name>Binding Identity Assertions to JSEP Offer/Answer Transactions</name>
        <t>
                    The path, starting with "/.well-known/idp-proxy/" and
                    appended with
            An identity assertion binds the IdP protocol.  Note that user's identity (as asserted by the separator
                    characters '/' (%2F)
            IdP) to the SDP offer/answer exchange and '\' (%5C) MUST NOT be permitted in specifically to the protocol field, lest an attacker
            media. In order to achieve this, the PeerConnection must provide the
            DTLS-SRTP fingerprint to be able bound to direct
                    requests outside the identity. This is provided
            as a JavaScript object (also known as a dictionary or hash) with a
            single "fingerprint" key, as shown below:
        </t>
<!-- [rfced] Please review the type attribute set for each <sourcecode> and let
us know if any updates are needed.
-->
        <sourcecode name="json-1" type="json"><![CDATA[
{
  "fingerprint":
    [
      { "algorithm": "sha-256",
        "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" },
      { "algorithm": "sha-1",
        "digest": "74:E9:76:C8:19:...:F4:45:6B" }
    ]
} ]]></sourcecode>
        <t>
            The "fingerprint" value is an array of
            objects.  Each object in the controlled "/.well-known/" prefix.
                    Query array contains "algorithm" and fragment values MAY be used by including '?' or
                    '#' characters.
                  </t>
                </list>
                For example, for "digest" values, which correspond directly to
            the IdP "identity.example.com" algorithm and digest values in the protocol
                "example", "fingerprint" attribute of the URL would be: SDP <xref target="RFC8122" format="default"/>.
        </t>
              <figure>
                <artwork><![CDATA[
  https://identity.example.com/.well-known/idp-proxy/example
  ]]></artwork>
              </figure>
        <t>
                The IdP MAY redirect requests to this URL, but they MUST retain
                the "https" scheme.
            This changes object is encoded in a <xref target="RFC8259" format="default">JSON</xref>
            string for passing to the effective origin of IdP.  The identity assertion returned by
            the IdP, but not the domain of which is encoded in the identities "identity" attribute, is a JSON object that the IdP is
                permitted
            encoded as described in <xref target="sec.carry-assertion" format="default"/>.
        </t>
        <t>
            This structure does not need to assert and validate. I.e., be interpreted by the IdP or the
            IdP proxy. It is still
                regarded consumed solely by the RP's browser.  The IdP
            merely treats it as authoritative for an opaque value to be attested to.  Thus, new
            parameters can be added to the original domain. assertion without modifying the
            IdP.
        </t>
        <section title="Authenticating Party"> anchor="sec.carry-assertion" numbered="true" toc="default">
          <name>Carrying Identity Assertions</name>
          <t>
                  How
              Once an AP determines the appropriate IdP domain has generated an assertion (see <xref target="sec.request-assert" format="default"/>), it is out of
                  scope attached to the SDP
              offer/answer message. This is done by adding a new "identity"
              attribute to the SDP. The sole contents of this specification. In general, however, value is the AP has
                  some actual account relationship with
              identity assertion.  The identity assertion produced by the IdP is
              encoded into a UTF-8 JSON text, then <xref target="RFC4648" format="default">Base64-encoded</xref> to produce this string.
              For example:
          </t>

          <sourcecode name="sdp-1" type="sdp" ><![CDATA[
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=fingerprint:sha-1 \
  4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:\
  eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
  In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
  IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
  aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
a=...
t=0 0
m=audio 6056 RTP/SAVP 0
a=sendrecv
... ]]></sourcecode>

  <aside><t>Note that long lines in the IdP, as this
                  identity is what example are folded to meet the IdP is attesting to. Thus, column
  width constraints of this document; the AP somehow
                  supplies backslash ("\") at the IdP information to end of
  a line, the browser. Some potential
                  mechanisms include:
                  <list style="symbols"> carriage return that follows, and whitespace shall be ignored.</t></aside>

          <t>
                      Provided by
              The "identity" attribute attests to all "fingerprint" attributes in the user directly. session
              description. It is therefore a session-level attribute.
          </t>
          <t>
                      Selected from some set of IdPs known
              Multiple "fingerprint" values can be
              used to the calling site.
                      E.g., offer alternative certificates for a button peer.  The "identity" attribute <bcp14>MUST</bcp14> include all
              "fingerprint" values that shows "Authenticate via Facebook
                      Connect"
                    </t>
                  </list> are included in "fingerprint" attributes of the session
              description.
          </t>
              </section>

              <section title="Relying Party">
          <t>
                  Unlike the AP, the
              The RP need not have any particular
                  relationship with browser <bcp14>MUST</bcp14> verify that the IdP. Rather, it needs to be able to
                  process whatever assertion in-use certificate for a DTLS
              connection is provided by the AP.  As the
                  assertion contains the IdP's identity in the <spanx
                  style="verb">idp</spanx> field set of the JSON-encoded object (see
                  <xref target="sec.request-assert"/>), the URI can be
                  constructed directly fingerprints returned from the assertion, and thus the RP can
                  directly verify the technical validity of the assertion with
                  no user interaction. Authoritative assertions need only be
                  verifiable. Third-party assertions also MUST be verified
                  against local policy, as described in <xref
                  target="sec.id-format"/>. IdP
              when verifying an assertion.
          </t>
        </section>
      </section>
      <section title="Requesting Assertions" anchor="sec.request-assert"> anchor="sec.idp-uri" numbered="true" toc="default">
        <name>Determining the IdP URI</name>
        <t>
                The input
                In order to identity assertion is the JSON-encoded object
                described in <xref target="sec.jsep-binding"/> ensure that contains the
                set IdP is under control of certificate fingerprints the browser intends to use.
                This string domain
                owner rather than someone who merely has an account on the
                domain owner's server (e.g., in shared hosting scenarios), the
                IdP JavaScript is treated as opaque from the perspective of hosted at a deterministic location based on
                the
                IdP. IdP's domain name.  Each IdP proxy instance is associated
                with two values:
        </t>
              <t>
        <dl newline="false" spacing="normal">
          <dt>authority:</dt>
          <dd>
                       The browser also identifies the origin that <xref target="RFC3986" format="default"> authority</xref> at which the PeerConnection
                       IdP's service is run in, hosted.
                  </dd>
          <dt>protocol:</dt>
          <dd>
                    The specific IdP protocol which allows the IdP to make decisions based on who is requesting the assertion.
              </t>
              <t>
                An application can optionally provide using. This is a user identifier hint
                when specifying
                    completely opaque IdP-specific string, but allows an IdP. IdP to
                    implement two protocols in parallel. This value may be the
                    empty string.  If no value for protocol is provided, a hint that value
                    of "default" is used.
                  </dd>
        </dl>
        <t>
                Each IdP <bcp14>MUST</bcp14> serve its initial entry page (i.e., the one loaded
                by the IdP can
                use to select amongst multiple identities, or to avoid providing
                assertions for unwanted identities.  The <spanx
                style="verb">username</spanx> is proxy) from a string that <xref target="RFC5785" format="default">well-known
                URI</xref>.

<!-- [rfced] Section 7.5:  RFC 5785 has no meaning been obsoleted by RFC 8615.
May we change both citations as well as the reference listing for
RFC 5785?

(It looks like <https://www.iana.org/assignments/well-known-uris/>
and <https://www.iana.org/assignments/uri-schemes/> might be related
to
                any entity other than this text, and we see that both have been updated to refer to
RFC 8615.)

Original:
 Each IdP MUST serve its initial entry page (i.e., the IdP, it can contain any data one loaded by
 the IdP
                needs in order to correctly generate an assertion.
              </t>
              <t>
                An identity assertion that is successfully provided proxy) from a well-known URI [RFC5785].
...
This section reqisters the "idp-proxy" well-known URI from [RFC5785].
...
 [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
            Uniform Resource Identifiers (URIs)", RFC 5785,
            DOI 10.17487/RFC5785, April 2010,
            <https://www.rfc-editor.org/info/rfc5785>.

Suggested ("reqisters" has been fixed):
 Each IdP MUST serve its initial entry page (i.e., the one loaded by
 the IdP
                consists of proxy) from a well-known URI [RFC8615].
...
 This section registers the following information:
              </t>
              <t>
                <list style="hanging">
                  <t hangText="idp:"> "idp-proxy" well-known URI from [RFC8615].
...
 [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
            (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
            <https://www.rfc-editor.org/info/rfc8615>. -->

  The domain name of well-known URI for an IdP and the protocol string.  This MAY
                    identify a different IdP or protocol proxy is formed from
                the one that
                    generated the assertion. following URI components:
        </t>
                  <t hangText="assertion:">
        <ol spacing="normal" type="1">
          <li>
                    The scheme, "https:".  An opaque value containing the assertion itself. This is
                    only interpretable by the identified IdP or the IdP code
                    running in the client.
                  </t>
                </list>
              </t>
              <t> <bcp14>MUST</bcp14> be loaded using <xref target="fig.assert-ex"/> shows an example assertion
                formatted as JSON.  In this case, the message has presumably
                been digitally signed/MACed in some way that target="RFC2818" format="default">HTTPS</xref>.
                  </li>
          <li>
                    The <xref target="RFC3986" format="default">authority</xref>.  As noted above,
                    the IdP can later
                verify it, but this is authority <bcp14>MAY</bcp14> contain a  non-default port number or
                    userinfo sub-component.  Both are removed when determining
                    if an implementation detail and out of scope asserted identity matches the name of this document.              </t>

              <figure title="Example assertion" anchor="fig.assert-ex">
                <artwork><![CDATA[
{
  "idp":{
    "domain": "example.org",
    "protocol": "bogus"
  },
  "assertion": "{\"identity\":\"bob@example.org\",
                 \"contents\":\"abcdefghijklmnopqrstuvwyz\",
                 \"signature\":\"010203040506\"}"
}
]]></artwork>
              </figure>

              <t>
                For use in signaling, the assertion is serialized into JSON,
                <xref target="RFC4648">Base64-encoded</xref>, IdP.
                  </li>
          <li>
                    The path, starting with "/.well-known/idp-proxy/" and used as the
                value of
                    appended with the <spanx style="verb">identity</spanx> attribute.
                IdPs SHOULD ensure IdP protocol.  Note that any assertions they
                generate cannot the separator
                    characters '/' (%2F) and '\' (%5C) <bcp14>MUST NOT</bcp14> be interpreted permitted in a different context. E.g.,
                they should use a distinct format or have separate cryptographic
                keys for assertion generation and other purposes.
                Line breaks are inserted solely for
                readability.
              </t>
            </section>

            <section title="Managing User Login" anchor="sec.user-login">
              <t>
                In order to generate an identity assertion,
                    the IdP needs proof protocol field, lest an attacker be able to direct
                    requests outside of the user's identity.  It is common practice to authenticate users
                (using passwords or multi-factor authentication), then use <xref
                target="RFC6265">Cookies</xref> controlled "/.well-known/" prefix.
                    Query and fragment values <bcp14>MAY</bcp14> be used by including '?' or <xref target="RFC7617">HTTP
                authentication</xref>
                    '#' characters.
                  </li>
        </ol>
        <t>
                For example, for subsequent exchanges. the IdP "identity.example.com" and the protocol
                "example", the URL would be:
        </t>

  <ul empty="true"><li>&lt;https://identity.example.com/.well-known/idp-proxy/example&gt;</li></ul>

        <t>
                The IdP proxy is able <bcp14>MAY</bcp14> redirect requests to access cookies, HTTP authentication or
                other persistent session data because it operates in this URL, but they <bcp14>MUST</bcp14> retain
                the security
                context "https" scheme.  This changes the effective origin of the
                IdP, but not the domain of the identities that the IdP origin.  Therefore, if a user is logged in,
                permitted to assert and validate. That is, the IdP could have all is still
                regarded as authoritative for the information needed to generate an
                assertion. original domain.
        </t>
        <section numbered="true" toc="default">
          <name>Authenticating Party</name>
          <t>
                An
                  How an AP determines the appropriate IdP proxy domain is unable to generate an assertion if out of
                  scope of this specification. In general, however, the user AP has
                  some actual account relationship with the IdP, as this
                  identity is
                not logged in, or what the IdP wants is attesting to. Thus, the AP somehow
                  supplies the IdP information to interact with the browser. Some potential
                  mechanisms include:
          </t>
          <ul spacing="normal">
            <li>
                      Provided by the user directly.
                    </li>
            <li>
                      Selected from some set of IdPs known to
                acquire more information before generating the assertion.  If calling site
                      (e.g., a button that shows "Authenticate via Facebook
                      Connect").
                    </li>
          </ul>
        </section>
        <section numbered="true" toc="default">
          <name>Relying Party</name>
          <t>
                  Unlike the IdP wants to interact AP, the RP need not have any particular
                  relationship with the user before generating an
                assertion, IdP. Rather, it needs to be able to
                  process whatever assertion is provided by the AP.  As the
                  assertion contains the IdP's identity in the "idp" field of the IdP proxy JSON-encoded object (see
                  <xref target="sec.request-assert" format="default"/>), the URI can fail to generate an assertion be
                  constructed directly from the assertion, and
                instead indicate a URL where login should proceed.
              </t>
              <t>
                The application thus the RP can then load
                  directly verify the provided URL to enable technical validity of the assertion with
                  no user to enter credentials.  The communication between the
                application and the IdP is interaction. Authoritative assertions need only be
                  verifiable. Third-party assertions also <bcp14>MUST</bcp14> be verified
                  against local policy, as described in <xref
                target="webrtc-api"/>. target="sec.id-format" format="default"/>.
          </t>
        </section>
      </section>
      <section title="Verifying Assertions" anchor="sec.verify-assert"> anchor="sec.request-assert" numbered="true" toc="default">
        <name>Requesting Assertions</name>
        <t>
                The input to identity validation assertion is the assertion string taken
                from a decoded 'identity' attribute.
              </t>
              <t>
                The IdP proxy verifies JSON-encoded object
                described in <xref target="sec.jsep-binding" format="default"/> that contains the assertion. Depending on
                set of certificate fingerprints the browser intends to use.

<!-- [rfced] Section 7.6:  Should "input to identity
                protocol, the proxy might contact the IdP server or other
                servers.  For instance, an OAuth-based protocol will likely
                require using the IdP as an oracle, whereas with a
                signature-based scheme might assertion" be able
"input to verify the assertion
                without contacting the IdP, provided that it has cached the
                relevant public key.
              </t>
              <t>
                Regardless of the mechanism, if verification succeeds, a
                successful response from the IdP proxy consists of the following
                information:
                <list style="hanging">
                  <t hangText="identity:">
                    The identity of the AP from the IdP's perspective. Details
                    of this are provided in <xref target="sec.id-format"/>.
                  </t>
                  <t hangText="contents:">
                    The original unmodified string provided by the AP as input assertion process" (per Section 7) or possibly
"input to the assertion generation process.
                  </t>
                </list>
              </t>
              <t>
                <xref target="fig.verify-ex"/> shows an example response,
                which is JSON-formatted.
              </t>

              <figure title="Example verification result" anchor="fig.verify-ex">
                <artwork>
                  <![CDATA[
{
  "identity": "bob@example.org",
  "contents": "{\"fingerprint\":[ ... ]}"
}
]]></artwork>
              </figure>

              <section title="Identity Formats" anchor="sec.id-format">
                <t> process" (per Section 8)?

Original:
 The identity provided from the IdP input to identity assertion is the RP browser MUST
                  consist JSON-encoded object described
 in Section 7.4 that contains the set of a string representing certificate fingerprints the user's identity.
 browser intends to use. -->

                This string is in the form "&lt;user>@&lt;domain>", where <spanx
                  style="verb">user</spanx> consists of any character,
                  and domain is aninternationalized
                  domain name <xref target="RFC5890"></xref> encoded treated as a sequence opaque from the perspective of U-labels. the
                IdP.
        </t>
        <t>
                The PeerConnection API MUST check this string as follows:
                  <list style="numbers">
                    <t>
                      If browser also identifies the "domain" portion of origin that the string PeerConnection
                is equal to the domain
                      name of run in, which allows the IdP proxy, then to make decisions based on who
                is requesting the assertion assertion.
        </t>
        <t>
                An application can optionally provide a user identifier hint
                when specifying an IdP.  This value is valid, as a hint that the IdP is authoritative can
                use to select amongst multiple identities, or to avoid providing
                assertions for this domain.  Comparison of
                      domain names unwanted identities.  The "username" is done using a string that has no meaning to
                any entity other than the label equivalence rule
                      defined IdP; it can contain any data the IdP
                needs in Section 2.3.2.4 of <xref target="RFC5890"/>. order to correctly generate an assertion.
        </t>
        <t>
                      If
                An identity assertion that is successfully provided by the "domain" portion IdP
                consists of the string is not equal to the following information:
        </t>
        <dl newline="false" spacing="normal">
          <dt>idp:</dt>
          <dd>
                    The domain name of an IdP and the protocol string.  This <bcp14>MAY</bcp14>
                    identify a different IdP proxy, then or protocol from the PeerConnection
                      object MUST reject one that
                    generated the assertion.
                  </dd>
          <dt>assertion:</dt>
          <dd>
                    An opaque value containing the assertion itself. This is
                    only interpretable by the identified IdP or the IdP code
                    running in the client.
                  </dd>
        </dl>
        <t>
                <xref target="fig.assert-ex" format="default"/> shows an example assertion
                formatted as JSON.  In this case, the assertion unless both:
                      <list style="numbers">
                        <t> message has presumably
                been digitally signed/MACed in some way that the IdP domain can later
                verify it, but this is trusted as an acceptable third-party
                          IdP; implementation detail and
                        </t>
                        <t>
                          local policy is configured to trust this IdP domain
                          for the domain portion out of the identity string.
                        </t>
                      </list>
                    </t>
                  </list> scope
                of this document.              </t>
        <figure anchor="fig.assert-ex">
          <name>Example Assertion</name>
          <sourcecode name="json-2" type="json"><![CDATA[
{
  "idp":{
    "domain": "example.org",
    "protocol": "bogus"
  },
  "assertion": "{\"identity\":\"bob@example.org\",
                 \"contents\":\"abcdefghijklmnopqrstuvwyz\",
                 \"signature\":\"010203040506\"}"
} ]]></sourcecode>
        </figure>
        <t>
                  Any "@" or "%" characters
                For use in signaling, the "user" portion assertion is serialized into JSON,
                <xref target="RFC4648" format="default">Base64-encoded</xref>, and used as the
                value of the
                  identity MUST "identity" attribute.
                IdPs <bcp14>SHOULD</bcp14> ensure that any assertions they
                generate cannot be escaped according to the "Percent-Encoding"
                  rules defined interpreted in Section 2.1 of <xref
                  target="RFC3986"/>. Characters other than "@" and "%" MUST NOT
                  be percent-encoded. a different context. For example, with
                they should use a "user" of "user@133" distinct format or have separate cryptographic
                keys for assertion generation and
                  a "domain" of "identity.example.com", the resulting string will
                  be encoded as "user%40133@identity.example.com". other purposes.
                Line breaks are inserted solely for
                readability.
        </t>
      </section>
      <section anchor="sec.user-login" numbered="true" toc="default">
        <name>Managing User Login</name>
        <t>
                  Implementations are cautioned to take care when displaying
                  user identities containing escaped "@" characters. If such
                  characters are unescaped prior
                In order to display, implementations
                  MUST distinguish between the domain of generate an identity assertion, the IdP proxy and any
                  domain that might be implied by the portion needs proof of
                the
                  "&lt;user&gt;" portion that appears after the escaped "@"
                  sign. user's identity.  It is common practice to authenticate users
                (using passwords or multi-factor authentication), then use <xref target="RFC6265" format="default">cookies</xref> or <xref target="RFC7617" format="default">HTTP
                authentication</xref> for subsequent exchanges.
        </t>
              </section>

            </section>

      <section title="Security Considerations" anchor="sec.sec-cons">
        <t>
          Much of the security analysis of this problem
                The IdP proxy is contained in <xref
          target="I-D.ietf-rtcweb-security"/> able to access cookies, HTTP authentication data, or
                other persistent session data because it operates in the discussion security
                context of the
          particular issues above. In order to avoid repetition, this section
          focuses on (a) residual threats that are not addressed by this
          document and (b) threats produced by failure/misbehavior of one of IdP origin.  Therefore, if a user is logged in, the
          components in
                IdP could have all the system. information needed to generate an
                assertion.
        </t>

        <section title="Communications Security">
        <t>
            IF HTTPS
                An IdP proxy is not used to secure communications unable to generate an assertion if the signaling
            server, and the identity mechanism used in
            <xref target="sec.generic.idp"/> user is
                not used,
            then any on-path attacker can replace the DTLS-SRTP fingerprints
            in logged in, or the handshake and thus substitute its own identity for that
            of either endpoint.
          </t>

          <t>
            Even if HTTPS is used, IdP wants to interact with the signaling server can
            potentially mount a man-in-the-middle attack unless implementations
            have some mechanism for independently verifying keys. The UI
            requirements in <xref target="sec.proposal.comsec"/> are designed user to
            provide such a mechanism for motivated/security conscious users, but
            are not suitable for general use.  The identity service mechanisms
            in <xref target="sec.generic.idp"/> are
                acquire more suitable for general
            use. Note, however, that a malicious signaling service can strip off
            any such identity assertions, though it cannot forge new ones.  Note
            that all of information before generating the third-party security mechanisms available (whether
            X.509 certificates or a third-party IdP) rely on assertion.  If
                the security of IdP wants to interact with the user before generating an
                assertion, the IdP proxy can fail to generate an assertion and
                instead indicate a URL where login should proceed.
        </t>
        <t>
                The application can then load the
            third party--this is of course also true of provided URL to enable the user's connection
                user to enter credentials.  The communication between the
            Web site itself. Users who wish
                application and the IdP is described in <xref target="webrtc-api" format="default"/>.
        </t>
      </section>
    </section>
    <section anchor="sec.verify-assert" numbered="true" toc="default">
      <name>Verifying Assertions</name>
      <t>
                The input to assure themselves of security
            against a malicious identity provider can only do so by verifying
            peer credentials directly, e.g., by checking validation is the peer's fingerprint
            against assertion string taken
                from a value delivered out of band. decoded "identity" attribute.
      </t>
      <t>
            In order to protect against malicious content JavaScript, that
            JavaScript MUST NOT be allowed to have direct access to---or perform
            computations with---DTLS keys.
                The IdP proxy verifies the assertion. Depending on the identity
                protocol, the proxy might contact the IdP server or other
                servers.  For instance, if content JS were able
            to compute digital signatures, then an OAuth-based protocol will likely
                require using the IdP as an oracle, whereas with a
                signature-based scheme it would might be possible for content
            JS able to get an identity verify the assertion for a browser's generated key and
            then use
                without contacting the IdP, provided that assertion plus a signature by it has cached the key to authenticate
                relevant public key.
      </t>
      <t>
                Regardless of the mechanism, if verification succeeds, a call protected under an ephemeral Diffie-Hellman (DH) key controlled by
                successful response from the content
            JS, thus violating IdP proxy consists of the security guarantees otherwise provided by following
                information:
      </t>
      <dl newline="false" spacing="normal">
        <dt>identity:</dt>
        <dd>
                    The identity of the
            IdP mechanism. Note that it is not sufficient merely to deny AP from the
            content JS direct access to IdP's perspective. Details
                    of this are provided in <xref target="sec.id-format" format="default"/>.
                  </dd>
        <dt>contents:</dt>
        <dd>
                    The original unmodified string provided by the keys, AP as some have suggested doing
            with input
                    to the WebCrypto API assertion generation process.
                  </dd>
      </dl>
      <t>
                <xref target="webcrypto"/>. target="fig.verify-ex" format="default"/> shows an example response,
                which is JSON-formatted.
      </t>
      <figure anchor="fig.verify-ex">
        <name>Example Verification Result</name>
        <sourcecode name="json-3" type="json"><![CDATA[
{
  "identity": "bob@example.org",
  "contents": "{\"fingerprint\":[ ... ]}"
} ]]></sourcecode>
      </figure>
      <section anchor="sec.id-format" numbered="true" toc="default">
        <name>Identity Formats</name>
        <t>
                  The JS must
            also not be allowed identity provided from the IdP to perform operations that would be valid for the RP browser <bcp14>MUST</bcp14>
                  consist of a
            DTLS endpoint. By far string representing the safest approach user's identity.  This
                  string is simply to deny in the
            ability to perform form "&lt;user&gt;@&lt;domain&gt;", where "user" consists of any operations that depend on secret information
            associated with the key. Operations that depend on public
            information, such character,
                  and domain is an internationalized
                  domain name <xref target="RFC5890" format="default"/> encoded as exporting the public key are a sequence of course safe. U-labels.
        </t>
        </section>

        <section title="Privacy">
        <t>
                  The requirements in PeerConnection API <bcp14>MUST</bcp14> check this document are intended to allow:
          </t>
          <t>
            <list style="symbols">
              <t>
                Users to participate in calls without revealing their location. string as follows:
        </t>
              <t>
                Potential callees to avoid revealing their location and even
                presence status prior to agreeing
        <ol spacing="normal" type="1">
          <li>
                      If the "domain" portion of the string is equal to answer a call.
              </t>
            </list>
          </t>
          <t>
            However, these privacy protections come at a performance cost in
            terms the domain
                      name of the IdP proxy, then the assertion is valid, as the
                      IdP is authoritative for this domain.  Comparison of
                      domain names is done using TURN relays and, the label equivalence rule
                      defined in <xref target="RFC5890" sectionFormat="of" section="2.3.2.4"/>.
                    </li>
          <li>
            <t>
                      If the latter case, delaying
            ICE. Sites SHOULD make users aware "domain" portion of the string is not equal to the
                      domain name of these tradeoffs.
          </t>
          <t>
            Note that the protections provided here assume a non-malicious
            calling service. As IdP proxy, then the calling service always knows PeerConnection
                      object <bcp14>MUST</bcp14> reject the users
            status assertion unless both:
            </t>
            <ol spacing="normal" type="1">
              <li>
                          the IdP domain is trusted as an acceptable third-party
                          IdP; and (absent
                        </li>
              <li>
                          local policy is configured to trust this IdP domain
                          for the use domain portion of a technology like Tor) their IP
            address, they can violate the users privacy at will.  Users who wish
            privacy against identity string.
                        </li>
            </ol>
          </li>
        </ol>
        <t>
                  Any '@' or '%' characters in the calling sites they are using must use separate
            privacy enhancing technologies such as Tor. Combined WebRTC/Tor
            implementations SHOULD arrange "user" portion of the
                  identity <bcp14>MUST</bcp14> be escaped according to route the media as well as "percent-encoding"
                  rules defined in <xref target="RFC3986" sectionFormat="of" section="2.1"/>. Characters other than '@' and '%' <bcp14>MUST NOT</bcp14>
                  be percent-encoded. For example, with a "user" of "user@133" and
                  a "domain" of "identity.example.com", the
            signaling through Tor. Currently this resulting string will produce very suboptimal
            performance.
                  be encoded as "user%40133@identity.example.com".
        </t>
        <t>
            Additionally, any identifier which persists across multiple calls is
            potentially a problem for privacy, especially for anonymous calling
            services. Such services SHOULD instruct the browser
                  Implementations are cautioned to use separate
            DTLS keys for each call and also take care when displaying
                  user identities containing escaped '@' characters. If such
                  characters are unescaped prior to use TURN throughout display, implementations
                  <bcp14>MUST</bcp14> distinguish between the
            call. Otherwise, domain of the other side will learn linkable information IdP proxy and any
                  domain that
            would allow them to correlate the browser across multiple calls.
            Additionally, browsers SHOULD implement might be implied by the privacy-preserving CNAME
            generation mode portion of <xref target="RFC7022"/>. the
                  "&lt;user&gt;" portion that appears after the escaped "@"
                  sign.
        </t>
      </section>
    </section>
    <section title="Denial of Service"> anchor="sec.sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
            The consent mechanisms described in this document are intended to
            mitigate denial
          Much of service attacks the security analysis of this problem is contained in which an attacker uses clients
            to send large amounts <xref target="RFC8826" format="default"/> or in the discussion of traffic the
          particular issues above.

<!-- [rfced] Section 9:  What does "this problem" refer to a victim without here?

Original:
 Much of the consent security analysis of this problem is contained in
 [I-D.ietf-rtcweb-security] or in the victim. While these mechanisms are sufficient discussion of the particular
 issues above. -->

 In order to protect victims
            who have avoid repetition, this section
          focuses on (a) residual threats that are not implemented WebRTC at all, WebRTC implementations need
            to be more careful.
          </t>
          <t>
            Consider the case addressed by this
          document and (b) threats produced by failure/misbehavior of one of a call center which accepts calls via
            WebRTC. An attacker proxies the call center's front-end and arranges
            for multiple clients
          components in the system.
      </t>
      <section numbered="true" toc="default">
        <name>Communications Security</name>
        <t>
            If HTTPS is not used to initiate calls secure communications to the call center. Note that
            this requires user consent in many cases but because signaling
            server, and the data
            channel does identity mechanism used in
            <xref target="sec.generic.idp" format="default"/> is not need consent, he used,
            then any on-path attacker can use replace the DTLS-SRTP fingerprints
            in the handshake and thus substitute its own identity for that directly. Since ICE
            will complete, browsers can then be induced to send large amounts
            of
            data to the victim call center if it supports either endpoint.

<!-- [rfced] Section 9.1:  Should "the identity mechanism used in
Section 7" be "the identity mechanism used in Section 7.1" or
"the identity mechanisms used in Section 7"?  We ask because we see
"identity service mechanisms in Section 7" in the data channel at
            all. Preventing this attack requires that automated WebRTC
            implementations implement sensible flow control and have next paragraph.

Also, we changed "IF" to "If"; please let us know if the ability
capitalization was intentional.

Original:
 IF HTTPS is not used to triage out (i.e., stop responding secure communications to ICE probes on) calls which
            are behaving badly, the signaling
 server, and especially to be prepared to remotely
            throttle the data channel identity mechanism used in Section 7 is not used,
 then any on-path attacker can replace the DTLS-SRTP fingerprints in
 the absence of plausible audio handshake and
            video (which the attacker cannot control). thus substitute its own identity for that of either
 endpoint. -->

        </t>
        <t>
            Another related attack
            Even if HTTPS is for used, the signaling service to swap the ICE
            candidates for the audio and video streams, thus forcing server can
            potentially mount a browser
            to send video man-in-the-middle attack unless implementations
            have some mechanism for independently verifying keys. The UI
            requirements in <xref target="sec.proposal.comsec" format="default"/> are designed to the sink
            provide such a mechanism for motivated/security conscious users, but
            are not suitable for general use.  The identity service mechanisms
            in <xref target="sec.generic.idp" format="default"/> are more suitable for general
            use. Note, however, that the other victim expects will contain
            audio (perhaps it is only expecting audio!)  potentially causing
            overload.  Muxing multiple media flows over a single transport makes malicious signaling service can strip off
            any such identity assertions, though it harder to individually suppress a single flow by denying ICE
            keepalives. Either media-level (RTCP) cannot forge new ones.  Note
            that all of the third-party security mechanisms must be used available (whether
            X.509 certificates or a third-party IdP) rely on the
            implementation must deny responses entirely, thus terminating the
            call.
          </t>
          <t>
            Yet another attack, suggested by Magnus Westerlund, security of the
            third party -- this is for of course also true of the
            attacker user's connection to cross-connect offers and answers as follows. It induces the victim
            Web site itself. Users who wish to make assure themselves of security
            against a call and then uses its control malicious identity provider can only do so by verifying
            peer credentials directly, e.g., by checking the peer's fingerprint
            against a value delivered out of other users
            browsers band.
        </t>
        <t>
            In order to get them protect against malicious content JavaScript, that
            JavaScript <bcp14>MUST NOT</bcp14> be allowed to attempt a call have direct
	    access to someone. It -- or perform
            computations with -- DTLS keys. For instance, if content JS were able
            to compute digital signatures, then
            translates their offers into apparent answers it would be possible for content
            JS to get an identity assertion for a browser's generated key and
            then use that assertion plus a signature by the victim, which
            looks like large-scale parallel forking.  The victim still responds key to ICE responses and now authenticate
            a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the browsers all try content
            JS, thus violating the security guarantees otherwise provided by the
            IdP mechanism. Note that it is not sufficient merely to send media deny the
            content JS direct access to the
            victim.  Implementations can defend themselves from this attack by
            only responding keys, as some have suggested doing
            with the WebCrypto API <xref target="webcrypto" format="default"/>.  The JS must
            also not be allowed to ICE Binding Requests perform operations that would be valid for a limited number of
            remote ufrags (this
            DTLS endpoint. By far the safest approach is simply to deny the reason for
            ability to perform any operations that depend on secret information
            associated with the requirement key. Operations that depend on public
            information, such as exporting the JS
            not be able public key, are of course safe.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Privacy</name>
        <t>
            The requirements in this document are intended to control the ufrag and password). allow:
        </t>
        <ul spacing="normal">
          <li>
                Users to participate in calls without revealing their location.
              </li>
          <li>
                Potential callees to avoid revealing their location and even
                presence status prior to agreeing to answer a call.
              </li>
        </ul>
        <t>
            <xref target="I-D.ietf-rtcweb-rtp-usage"/> Section 13 documents
            However, these privacy protections come at a number performance cost in
            terms of potential RTCP-based DoS attacks and countermeasures. using TURN relays and, in the latter case, delaying
            ICE. Sites <bcp14>SHOULD</bcp14> make users aware of these trade&nbhy;offs.
        </t>
        <t>
            Note that attacks based on confusing one end or the other about
            consent are possible even in protections provided here assume a non-malicious
            calling service. As the face calling service always knows the user's
            status and (absent the use of a technology like Tor) their IP
            address, they can violate the third-party identity
            mechanism user's privacy at will.  Users who wish
            privacy against the calling sites they are using must use separate
            privacy-enhancing technologies such as long Tor. &nbsp;Combined WebRTC/Tor
            implementations <bcp14>SHOULD</bcp14> arrange to route the media as well as major parts of the
            signaling messages are not
            signed. On through Tor. &nbsp;Currently this will produce very suboptimal
            performance.
        </t>
        <t>
            Additionally, any identifier that persists across multiple calls is
            potentially a problem for privacy, especially for anonymous calling
            services. Such services <bcp14>SHOULD</bcp14> instruct the browser to use separate
            DTLS keys for each call and also to use TURN throughout the
            call. Otherwise, the other hand, signing side will learn linkable information that
            would allow them to correlate the entire message severely
            restricts browser across multiple calls.
            Additionally, browsers <bcp14>SHOULD</bcp14> implement the capabilities privacy-preserving CNAME
            generation mode of the calling application, so there are
            difficult tradeoffs here. <xref target="RFC7022" format="default"/>.
        </t>
      </section>
      <section title="IdP Authentication Mechanism"> numbered="true" toc="default">
        <name>Denial of Service</name>
        <t>
            This mechanism relies for its security on the IdP and on the
            PeerConnection correctly enforcing the security invariants
            The consent mechanisms described
            above. At a high level, the IdP is attesting that the user
            identified in the assertion wishes this document are intended to be associated with the
            assertion. Thus, it must not be possible for arbitrary third parties
            mitigate DoS attacks in which an attacker uses clients
            to get assertions tied send large amounts of traffic to a user or victim without the consent of
            the victim. While these mechanisms are sufficient to produce assertions that RPs
            will accept. protect victims
            who have not implemented WebRTC at all, WebRTC implementations need
            to be more careful.
        </t>

          <section title="PeerConnection Origin Check" anchor="sec.pc-origin">
        <t>
              Fundamentally,
            Consider the IdP proxy is just a piece case of HTML and JS loaded
              by the browser, so nothing stops a Web call center which accepts calls via
            WebRTC. An attacker from creating
              their own IFRAME, loading proxies the IdP proxy HTML/JS, call center's front-end and requesting a
              signature over his own keys rather than those generated arranges
            for multiple clients to initiate calls to the call center. Note that
            this requires user consent in many cases, but because the data
            channel does not need consent, he can use that directly. Since ICE
            will complete, browsers can then be induced to send large amounts of
            data to the victim call center if it supports the browser. However, data channel at
            all. Preventing this attack requires that proxy would automated WebRTC
            implementations implement sensible flow control and have the ability
            to triage out (i.e., stop responding to ICE probes on) calls which
            are behaving badly, and especially to be in prepared to remotely
            throttle the
              attacker's origin, not data channel in the IdP's origin. Only absence of plausible audio and
            video (which the
              browser itself can instantiate a context that (a) attacker cannot control).
        </t>
        <t>
            Another related attack is in for the IdP's origin and
              (b) exposes signaling service to swap the correct API surface. Thus, ICE
            candidates for the IdP proxy on audio and video streams, thus forcing a browser
            to send video to the sender's side MUST ensure sink that the other victim expects will contain
            audio (perhaps it is running in the IdP's origin
              prior only expecting audio!), potentially causing
            overload.  Muxing multiple media flows over a single transport makes
            it harder to issuing assertions. individually suppress a single flow by denying ICE
            keepalives. Either media-level (RTCP) mechanisms must be used or the
            implementation must deny responses entirely, thus terminating the
            call.
        </t>
        <t>
              Note that this check only asserts that
            Yet another attack, suggested by Magnus Westerlund, is for the browser (or some
            attacker to cross-connect offers and answers as follows. It induces
            the victim to make a call and then uses its control of other
              entity with access users'
            browsers to get them to attempt a call to someone. It then
            translates their offers into apparent answers to the user's authentication data) attests victim, which
            looks like large-scale parallel forking.  The victim still responds
            to
              the request ICE responses, and hence to the fingerprint.  It does not demonstrate
              that now the browser has access browsers all try to send media to the associated private
              key, and therefore an attacker
            victim.  Implementations can attach their own identity
              to another party's keying material, thus making a call which
              comes defend themselves from Alice appear this attack by
            only responding to come from the attacker.
              See <xref target="I-D.ietf-mmusic-sdp-uks"/> ICE Binding Requests for defenses against this
              form a limited number of attack.
            </t>
          </section>

          <section title="IdP Well-known URI" anchor="sec.sec-idp-uri">
            <t>
              As described in <xref target="sec.idp-uri"/> the IdP proxy HTML/JS
              landing page
            remote ufrags (this is located at a well-known URI based on the IdP's
              domain name. This reason for the requirement prevents an attacker who can write
              some resources at that the IdP (e.g., on one's Facebook wall) from
              being JS
            not be able to impersonate control the IdP. ufrag and password).
        </t>
          </section>

          <section title="Privacy
        <t>
            <xref target="RFC8834" sectionFormat="comma" section="13"/> documents a number
            of IdP-generated identities potential RTCP-based DoS attacks and the hosting site"> countermeasures.
        </t>
        <t>
              Depending
            Note that attacks based on confusing one end or the structure of the IdP's assertions, other about
            consent are possible even in the calling
              site may learn face of the user's third-party identity from the perspective
            mechanism as long as major parts of the
              IdP.  In many cases this is signaling messages are not an issue because the user is
              authenticating to the site via the IdP in any case, for instance
              when
            signed. On the user has logged in with Facebook Connect and is then
              authenticating their call with a Facebook identity.  However, in other case, the user may not have already revealed their identity
              to hand, signing the site.  In general, IdPs SHOULD either verify that entire message severely
            restricts the user
              is willing to have their identity revealed to capabilities of the site (e.g.,
              through calling application, so there are
            difficult trade&nbhy;offs here.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>IdP Authentication Mechanism</name>
        <t>
            This mechanism relies for its security on the usual IdP permissions dialog) or arrange that and on the
              identity information is only available to known RPs (e.g., social
              graph adjacencies) but not to
            PeerConnection correctly enforcing the calling site. The "domain" field
              of security invariants described
            above. At a high level, the assertion request can be used to check IdP is attesting that the user has
              agreed to disclose their identity to
            identified in the calling site; because it
              is supplied by assertion wishes to be associated with the PeerConnection
            assertion. Thus, it can must not be trusted possible for arbitrary third parties
            to be correct. get assertions tied to a user or to produce assertions that RPs
            will accept.
        </t>
          </section>
        <section title="Security of Third-Party IdPs" anchor="sec.sec-third-party"> anchor="sec.pc-origin" numbered="true" toc="default">
          <name>PeerConnection Origin Check</name>
          <t>
              As discussed above, each third-party
              Fundamentally, the IdP represents proxy is just a new
              universal trust point piece of HTML and therefore JS loaded
              by the number of these IdPs needs
              to be quite limited. Most IdPs, even browser, so nothing stops a Web attacker from creating
              their own IFRAME, loading the IdP proxy HTML/JS, and requesting a
              signature over his own keys rather than those which issue unqualified
              identities such as Facebook, can be recast as authoritative IdPs
              (e.g., 123456@facebook.com). generated in
              the browser. However, that proxy would be in such cases, the user
              interface implications are not entirely desirable.  One
              intermediate approach
              attacker's origin, not the IdP's origin. Only the
              browser itself can instantiate a context that (a)&nbsp;is in the IdP's origin and
              (b)&nbsp;exposes the correct API surface. Thus, the IdP proxy on
              the sender's side <bcp14>MUST</bcp14> ensure that it is running in the IdP's origin
              prior to have special (potentially user
              configurable) UI for large authoritative IdPs, thus allowing issuing assertions.
          </t>
          <t>
              Note that this check only asserts that the
              user browser (or some other
              entity with access to instantly grasp the user's authentication data) attests to
              the request and hence to the fingerprint.  It does not demonstrate
              that the call is being authenticated by
              Facebook, Google, etc.
            </t>

            <section title="Confusable Characters">
              <t>
                Because a broad range of characters are permitted in browser has access to the associated private
              key, and therefore an attacker can attach their own identity
                strings, it may be possible for attackers
              to craft identities another party's keying material, thus making a call which are confusable with other identities (see
              comes from Alice appear to come from the attacker.
              See <xref target="RFC6943"/> target="RFC8844" format="default"/> for more on this topic). This is
                a problem with any identifier space of defenses against this type
                (e.g., e-mail addresses).
                Those minting identifers should avoid mixed scripts and similar
                confusable characters. Those presenting these identifiers to a
                user should consider highlighting cases
              form of mixed script usage
                (see <xref target="RFC5890"/>, section 4.4). Other best practices are still in development. attack.
          </t>
        </section>
          </section>

          <section title="Web Security Feature Interactions">
            <t>
              A number of optional Web security features have the potential to
              cause issues for this mechanism, as discussed below.
            </t>
        <section title="Popup Blocking" anchor="sec.popup-blocking"> anchor="sec.sec-idp-uri" numbered="true" toc="default">
          <name>IdP Well-Known URI</name>
          <t>
                When popup blocking is
              As described in use, <xref target="sec.idp-uri" format="default"/>, the IdP proxy HTML/JS
              landing page is unable to generate popup windows, dialogs or
                any other form of user interactions. located at a well-known URI based on the IdP's
              domain name. This requirement prevents an attacker who can write
              some resources at the IdP
                proxy (e.g., on one's Facebook wall) from
              being used able to circumvent user interaction.  The
                "LOGINNEEDED" message allows impersonate the IdP proxy to inform IdP.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Privacy of IdP-Generated Identities and the Hosting Site</name>
          <t>
              Depending on the structure of the IdP's assertions, the calling
              site may learn the user's identity from the perspective of a need for user login, providing the information
                necessary to satisfy
              IdP.  In many cases, this requirement without resorting to
                direct is not an issue because the user interaction from is
              authenticating to the site via the IdP proxy itself.
              </t>
            </section>

            <section title="Third Party Cookies" anchor="sec.3rd-party-cookies">
              <t>
                Some browsers allow users to block third party cookies (cookies
                associated in any case -- for instance,
              when the user has logged in with origins Facebook Connect and is then
              authenticating their call with a Facebook identity.  However, in
              other than cases, the top level page) for
                privacy reasons.  Any IdP which uses cookies to persist logins
                will be broken by third-party cookie blocking. One option is user may not have already revealed their identity
              to
                accept this as a limitation; another the site.  In general, IdPs <bcp14>SHOULD</bcp14> either verify that the user
              is willing to have their identity revealed to the
                PeerConnection object disable third-party cookie blocking for site (e.g.,
              through the usual IdP proxy.
              </t>
            </section>

          </section>
        </section>
      </section>

      <section title="IANA Considerations" anchor="sec.iana-cons">
        <t>
          This specification defines the <spanx style="verb">identity</spanx>
          SDP attribute per permissions dialog) or arrange that the procedures of Section 8.2.4 of <xref
          target="RFC4566"/>.  The required
              identity information for the registration is
          included here:
          <list style="hanging">
            <t hangText="Contact Name:">IESG (iesg@ietf.org)</t>
            <t hangText="Attribute Name:">identity</t>
            <t hangText="Long Form:">identity</t>
            <t hangText="Type of Attribute:">session-level</t>
            <t hangText="Charset Considerations:">This attribute is only available to known RPs (e.g., social
              graph adjacencies) but not subject to the charset attribute.</t>
            <t hangText="Purpose:">This attribute carries an identity assertion,
            binding an calling site. The "domain" field
              of the assertion request can be used to check that the user has
              agreed to disclose their identity to the transport-level security session.</t>
            <t hangText="Appropriate Values:">See <xref
            target="sec.sdp-id-attr"/> of RFCXXXX [[Editor Note: This
            document.]]</t>
            <t hangText="Mux Category:">NORMAL.</t>
          </list>
        </t>
        <t>
          This section reqisters calling site; because it
              is supplied by the <spanx style="verb">idp-proxy</spanx> well-known
          URI from <xref target="RFC5785"/>.
          <list style="hanging">
             <t hangText="URI suffix:">idp-proxy</t>
             <t hangText="Change controller:">IETF</t>
          </list> PeerConnection it can be trusted to be correct.
          </t>
        </section>
        <section title="Acknowledgements"> anchor="sec.sec-third-party" numbered="true" toc="default">
          <name>Security of Third-Party IdPs</name>
          <t>
        Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen
        Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin
        Thomson, Magnus Westerland.  Matthew Kaufman provided
              As discussed above, each third-party IdP represents a new
              universal trust point and therefore the UI material number of these IdPs needs
              to be quite limited. Most IdPs, even those which issue unqualified
              identities such as Facebook, can be recast as authoritative IdPs
              (e.g., 123456@facebook.com). However, in
        <xref target="sec.proposal.comsec"/>. Christer Holmberg provided such cases, the initial version of <xref target="sec.sdp-id-attr-oa"/>.
      </t>
    </section>

    <section title="Changes">
      <t> [RFC Editor: Please remove this section prior user
              interface implications are not entirely desirable.  One
              intermediate approach is to publication.]</t>
      <section title="Changes since -15">
        <t>Rewrite have a special (potentially user
              configurable) UI for large authoritative IdPs, thus allowing the Identity section in more conventional offer/answer format.</t>
        <t>Clarify rules on changing identities.</t>
      </section>

      <section title="Changes since -11">
        <t>
          Update discussion of IdP security model
        </t>

        <t>
          Replace "domain name" with RFC 3986 Authority
              user to instantly grasp that the call is being authenticated by
              Facebook, Google, etc.
          </t>
          <section numbered="true" toc="default">
            <name>Confusable Characters</name>
            <t>
          Clean up discussion
                Because a broad range of how characters are permitted in identity
                strings, it may be possible for attackers to generate IdP URI.
        </t>

        <t>
          Remove obsolete text about null cipher suites.
        </t>

        <t>
          Remove obsolete appendixes about older IdP systems
        </t>

        <t>
          Require support craft identities
                which are confusable with other identities (see
                <xref target="RFC6943" format="default"/> for ECDSA, PFS, and AEAD
        </t>
      </section>
      <section title="Changes since -10">
        <t>
          Update cipher suite profiles.
        </t>
        <t>
          Rework IdP interaction based more on implementation experience this topic). This is
                a problem with any identifier space of this type
                (e.g., email addresses).
                Those minting identifiers should avoid mixed scripts and similar
                confusable characters. Those presenting these identifiers to a
                user should consider highlighting cases of mixed script usage
                (see <xref target="RFC5890" sectionFormat="comma" section="4.4"/>). Other best practices are still in
          Firefox. development.
            </t>
          </section>
        </section>
        <section title="Changes since -06"> numbered="true" toc="default">
          <name>Web Security Feature Interactions</name>
          <t>
          Replaced RTCWEB and RTC-Web with WebRTC, except when referring to
              A number of optional Web security features have the
          IETF WG
        </t>
        <t>
          Forbade use in mixed content potential to
              cause issues for this mechanism, as discussed in Orlando. below.
          </t>
          <section anchor="sec.popup-blocking" numbered="true" toc="default">
            <name>Popup Blocking</name>
            <t>
          Added a requirement
                When popup blocking is in use, the IdP proxy is unable to surface NULL ciphers generate popup windows, dialogs, or
                any other form of user interactions.  This prevents the IdP
                proxy from being used to circumvent user interaction.  The
                "LOGINNEEDED" message allows the top-level.
        </t>
        <t>
          Tried IdP proxy to clarify SRTP versus DTLS-SRTP.
        </t>
        <t>
          Added inform the calling
                site of a section on screen sharing permissions.
        </t>
        <t>
          Assorted editorial work.
        </t>
      </section>

      <section title="Changes since -05">
        <t>
          The following changes have been made since need for user login, providing the -05 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Response information
                necessary to comments satisfy this requirement without resorting to
                direct user interaction from Richard Barnes
            </t>
            <t>
              More explanation of the IdP security properties and the federation
              use case.
            </t>
            <t>
              Editorial cleanup.
            </t>
          </list> proxy itself.
            </t>
          </section>
          <section title="Changes since -03"> anchor="sec.3rd-party-cookies" numbered="true" toc="default">
            <name>Third Party Cookies</name>
            <t>
          Version -04 was
                Some browsers allow users to block third party cookies (cookies
                associated with origins other than the top-level page) for
                privacy reasons.  Any IdP which uses cookies to persist logins
                will be broken by third-party cookie blocking. One option is to
                accept this as a version control mistake. Please ignore.
        </t>
        <t>
          The following changes limitation; another is to have been made since the -04 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Move origin check from
                PeerConnection object disable third-party cookie blocking for
                the IdP to RP per discussion in YVR.
            </t>
            <t>
              Clarified treatment of X.509-level identities.
            </t>
            <t>
              Editorial cleanup.
            </t>
          </list> proxy.
            </t>
          </section>

      <section title="Changes since -03">
        </section>
      </section>
    </section>
    <section title="Changes since -02"> anchor="sec.iana-cons" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
          This specification defines the "identity"
          SDP attribute per the procedures of <xref target="RFC4566" sectionFormat="of" section="8.2.4"/>.  The following changes have been made since required information for the -02 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Forbid persistent HTTP permissions. registration is
          included here:
      </t>
            <t>
              Clarified the text in S 5.4 to clearly refer
      <dl newline="false" spacing="normal">
        <dt>Contact Name:</dt>
        <dd>IESG (iesg@ietf.org)</dd>
        <dt>Attribute Name:</dt>
        <dd>identity</dd>
        <dt>Long Form:</dt>
        <dd>identity</dd>
        <dt>Type of Attribute:</dt>
        <dd>session-level</dd>
        <dt>Charset Considerations:</dt>
        <dd>This attribute is not subject
            to requirements on the API to provide functionality charset attribute.</dd>
        <dt>Purpose:</dt>
        <dd>This attribute carries an identity assertion,
            binding an identity to the site.
            </t>
            <t>
              Fold in the IETF portion transport-level security session.</dd>
        <dt>Appropriate Values:</dt>
        <dd>See <xref target="sec.sdp-id-attr" format="default"/> of draft-rescorla-rtcweb-generic-idp
            </t> RFC 8827.</dd>
        <dt>Mux Category:</dt>
        <dd>NORMAL.</dd>
      </dl>
      <t>
              Retarget the continuing consent
          This section to assume Binding Requests
            </t>
            <t>
              Added some more privacy and linkage text in various places.
            </t>
            <t>
              Editorial improvements
            </t>
          </list> registers the "idp-proxy" well-known
          URI from <xref target="RFC5785" format="default"/>.
      </t>
      </section>
      <dl newline="false" spacing="normal">
        <dt>URI suffix:</dt>
        <dd>idp-proxy</dd>
        <dt>Change controller:</dt>
        <dd>IETF</dd>
      </dl>
    </section>
  </middle>
  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC2818;
      &RFC3264;
      &RFC3711;
      &RFC3986;
      &RFC4566;
      &RFC4568;
      &RFC4648;
      &RFC5246;
      &RFC5763;
      &RFC5764;
      &RFC5785;
      &RFC5890;
      &RFC6347;
      &RFC6454;
      &RFC7022;
      &RFC7675;
      &RFC7918;
      &RFC8174;
      &RFC8122;
      &RFC8259;
      &RFC8261;
      &RFC8445;

      &I-D.ietf-rtcweb-overview;
      &I-D.ietf-rtcweb-security;
      &I-D.ietf-rtcweb-rtp-usage;
      &I-D.ietf-mmusic-sdp-uks;
      &I-D.ietf-rtcweb-jsep;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
  <front>
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
    <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    </author>
    <date month="June" year="2020" />
  </front>
  <seriesInfo name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>
</reference>

 <!--draft-ietf-rtcweb-security: RFC 8826 -->
 <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
 <front>
 <title>Security Considerations for WebRTC</title>
 <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
   <organization/>
 </author>
 <date month='June' year='2020'/>
 </front>
 <seriesInfo name="RFC" value="8826"/>
 <seriesInfo name="DOI" value="10.17487/RFC8826"/>
 </reference>

<!-- draft-ietf-rtcweb-rtp-usage; RFC 8834 -->
<reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834">
  <front>
    <title>Media Transport and Use of RTP in WebRTC</title>
    <author initials="C." surname="Perkins" fullname="Colin Perkins">
      <organization />
    </author>
    <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
      <organization />
    </author>
    <author initials="J." surname="Ott" fullname="Jörg Ott">
      <organization />
    </author>
    <date month="June" year="2020" />
  </front>
  <seriesInfo name="RFC" value="8834" />
  <seriesInfo name="DOI" value="10.17487/RFC8834"/>
</reference>

<!-- draft-ietf-mmusic-sdp-uks; RFC 8844 -->
<reference anchor='RFC8844' target="https://www.rfc-editor.org/info/rfc8844">
<front>
<title>Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP)</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month="June" year="2020"/>

</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>

</reference>

<!-- draft-ietf-rtcweb-jsep; RFC 8829 -->
 <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
 <front>
 <title>JavaScript Session Establishment Protocol (JSEP)</title>
 <author initials='J.' surname='Uberti' fullname='Justin Uberti'>
   <organization/>
 </author>
 <author initials="C." surname="Jennings" fullname="Cullen Jennings">
   <organization/>
 </author>
 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"
         role="editor">
 <organization/>
 </author>
 <date month='June' year='2020'/>
 </front>
 <seriesInfo name="RFC" value="8829"/>
 <seriesInfo name="DOI" value="10.17487/RFC8829"/>
 </reference>

        <reference anchor="webcrypto"> anchor="webcrypto" target="https://www.w3.org/TR/WebCryptoAPI/">
          <front>
            <title>Web Cryptography API</title>
            <author fullname="W3C editors"
                  surname="Dahl, Sleevi">
            <organization>W3C</organization> initials="M" surname="Watson" fullname="Mark Watson">
              <organization>W3C</organization>
            </author>
            <date month="January" year="2017"/>
          </front>
        </reference>

<!-- [rfced] Normative References:  Because the citation for
[webcrypto] is used generally in text, we updated this listing per
<https://www.w3.org/TR/WebCryptoAPI/>.  Please let us know any
objections.

Original:
 [webcrypto]
            editors, W., "Web Cryptography API", June 2013.

            Available at http://www.w3.org/TR/WebCryptoAPI/

Currently:
 [webcrypto]
            Watson, M., "Web Cryptography API", January 2017,
            <https://www.w3.org/TR/WebCryptoAPI/>. -->

        <reference anchor="webrtc-api" target="https://www.w3.org/TR/webrtc/">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="A" surname="Bergkvist" fullname="Adam Bergkvist">
              <organization></organization>
            </author>
            <author initials="D" surname="Burnett" fullname="Daniel C. Burnett">
              <organization></organization>
            </author>
            <author initials="C" surname="Jennings" fullname="Cullen Jennings">
              <organization></organization>
            </author>
            <author initials="A" surname="Narayanan" fullname="Anant Narayanan">
              <organization></organization>
            </author>
            <author initials="B" surname="Aboba" fullname="Bernard Aboba">
              <organization></organization>
            </author>
            <author initials="T" surname="Brandstetter" fullname="Taylor Brandstetter">
              <organization></organization>
            </author>
            <author initials="H" surname="Boström" fullname="Henrik Boström">
              <organization></organization>
            </author>
            <author initials="J-I" surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization></organization>
            </author>
            <date day="25" month="June" year="2013" /> month="December" year="2019"/>
          </front>

        <annotation>Available at
        http://www.w3.org/TR/WebCryptoAPI/</annotation>
        </reference>

      <reference anchor="webrtc-api">
        <front>
          <title>WebRTC

<!-- [rfced] Normative References:  The URL as provided for
[webrtc-api] in the original document -
<http://dev.w3.org/2011/webrtc/editor/webrtc.html> - steers to
<http://w3c.github.io/webrtc-pc/>, dated October 2019.  Please note
that this GitHub page says "Editor's draft" and also says
"Latest published version: https://www.w3.org/TR/webrtc/."  We have updated
this to refer to the "Latest published version".  Please let us know any
objections.

Original:
 [webrtc-api]
            editors, W., "WebRTC 1.0: Real-time Communication Between Browsers</title>

          <author fullname="W3C editors"
                  surname="Bergkvist,
            Browsers", October 2011.

            Available at http://dev.w3.org/2011/webrtc/editor/
            webrtc.html

Currently:
 [webrtc-api]
            Bergkvist, A., Burnett, D., Jennings, Narayanan">
            <organization>W3C</organization>
          </author>

          <date day="4" month="October" year="2011" />
        </front>

        <annotation>Available at
        http://dev.w3.org/2011/webrtc/editor/webrtc.html</annotation>
      </reference> C., Narayanan, A.,
            Aboba, B., Brandstetter, T., Boström, H., and J-I.
            Bruaroey, "WebRTC 1.0: Real-time Communication Between
            Browsers", December 2019,
            <https://www.w3.org/TR/webrtc/>
-->
        <reference anchor="FIPS186">
          <front>
            <title>Digital Signature Standard (DSS)</title>
          <author >
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2013" month="July"/>
          </front>
            <seriesInfo name="NIST PUB 186-4" value=""/> PUB" value="186-4"/>
            <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>
      </references>

   <references title="Informative References">
      &RFC7617;
      &RFC3261;
      &RFC5705;
      &RFC6455;
      &RFC6265;
      &RFC6943;
      &RFC6120;
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5705.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6943.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/>
        <reference anchor="XmlHttpRequest"> anchor="XmlHttpRequest" target="https://www.w3.org/TR/XMLHttpRequest/">
          <front>
            <title>XMLHttpRequest Level 2</title>
            <author initials="A." surname="van Kesteren">
            <organization></organization>
              <organization/>
            </author>
            <date day="17" month="January" year="2012"/>
          </front>
        <format target="http://www.w3.org/TR/XMLHttpRequest/" type="TXT"/>
        </reference>

<!-- [rfced] Informative References:  The URL as provided for
[XmlHttpRequest] in the original document -
<http://www.w3.org/TR/XMLHttpRequest/> - steers to a page with the
title "XMLHttpRequest Level 1," dated October 2016.  When we did a
Google search for "XMLHttpRequest Level 2," we found
<https://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/>, which is
partially obscured by a red box that says "This version is
outdated!"  The link in the box in turn steers to the October 2016
"XMLHttpRequest Level 1" page.

Please advise.

Original:
 [XmlHttpRequest]
            van Kesteren, A., "XMLHttpRequest Level 2", January 2012. -->

      </references>
    </references>

    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        <contact fullname="Bernard Aboba"/>, <contact fullname="Harald
	Alvestrand"/>, <contact fullname="Richard Barnes"/>, <contact
	fullname="Dan Druta"/>, <contact fullname="Cullen
        Jennings"/>, <contact fullname="Hadriel Kaplan"/>, <contact
	fullname="Matthew Kaufman"/>, <contact fullname="Jim McEachern"/>,
	<contact fullname="Martin Thomson"/>, <contact fullname="Magnus
	Westerlund"/>.  <contact fullname="Matthew Kaufman"/> provided the UI material in
        <xref target="sec.proposal.comsec" format="default"/>. <contact fullname="Christer Holmberg"/> provided
        the initial version of <xref target="sec.sdp-id-attr-oa" format="default"/>.
      </t>
    </section>
  </back>

<!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following term was used inconsistently in this document.
We chose to use the latter form.  Please let us know any objections.

 Cookies ("use Cookies") / cookies ("access cookies") (Section 7.7)

b) In the v2 XML file, <spanx style="verb"> was used to create single quotes
for some keys, values, and attribute names.  Per RFC 7991, the xml2rfc v3
vocab, <spanx> has been deprecated:

   Deprecate <spanx>; replace it with <strong>, <em>, and <tt>.

C238 uses single or double quotes when referring to SDP attributes. Note that
we have replaced instances of <spanx> with double quotes.  Please let us know
if any updates are needed.

c) Please let us know how/if the following should be made consistent:

 interdomain ("interdomain calling") /
   inter-domain ("inter-domain protocol")
     (Usage post-RFC 6000 is mixed but leans heavily toward
     "inter-domain.")

 Identity Providers ("overview of Identity Providers and the relevant
   terminology") / identity providers

   The rest of this document, and the rest of the documents in
     Cluster 238, use the lowercase form.  Changing "overview of
     Identity Providers" to "overview of IdPs" in this document would
     resolve this issue.

 Relying Party (Section 4) / relying party (Section 7)

 security characteristics / "security characteristics"

 "https:" (The scheme, "https:") / "https" scheme (the "https" scheme)
-->

</rfc>