<?xml version="1.0" encoding="US-ASCII"?>
<!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"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtcweb-security-arch-20"
     ipr="pre5378Trust200902"> indexInclude="true" ipr="pre5378Trust200902" number="8827" prepTime="2021-01-16T18:38:47" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch-20" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8827" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="WebRTC Sec. Arch.">WebRTC Security Architecture</title>
    <seriesInfo name="RFC" value="8827" stream="IETF"/>
    <author fullname="Eric Rescorla" initials="E.K." initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
      <organization showOnFrontPage="true">Mozilla</organization>
      <address>
        <postal>
          <street>2064 Edgewood Drive</street>

          <city>Palo Alto</city>

          <region>CA</region>

          <code>94303</code>

          <country>USA</country>
        </postal>

        <phone>+1 650 678 2350</phone>
        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date/>

    <area>ART</area>

    <workgroup>RTCWEB</workgroup>

    <abstract>
      <t>
    <date month="01" year="2021"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        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 -- "real-time communication on the Web".
      </t>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section title="Introduction" anchor="sec.introduction">
      <t>
        The Real-Time Communications on anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Web (RTCWEB) working group
        standardized protocols for real-time communications between Web
        browsers, generally called "WebRTC" <xref target="I-D.ietf-rtcweb-overview"/>.
        The major use cases for WebRTC technology are real-time audio
        and/or video calls, Web conferencing, Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and direct data transfer. Unlike
        most conventional real-time systems, (e.g., SIP-based <xref
        target="RFC3261"></xref> soft phones) WebRTC communications are directly
        controlled has been approved for publication by some Web server, via a JavaScript (JS) API as shown
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in
        <xref target="fig.simple"/>. Section 2 of
            RFC 7841.
        </t>
      <figure title="A simple WebRTC system" anchor="fig.simple">
        <artwork><![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"/>.  The protocol
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be used between
        the domains is not standardized by WebRTC, but given the installed base obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8827" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the form of persons identified as the WebRTC API
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is likely subject to be something SDP-based like
        SIP or something like Extensible Messaging BCP 78 and Presence Protocol (XMPP)
        <xref target="RFC6120"/>.
      </t>
      <figure title="A multidomain WebRTC system" anchor="fig.multidomain">
        <artwork><![CDATA[
                 +--------------+             +--------------+
                 |              | 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"/>.  This document
        describes a security architecture for WebRTC which addresses the threats
        and requirements described IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in that effect on the date of
            publication of this document.
      </t>
    </section>

    <section anchor="sec-term" title="Terminology">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", Please review these documents
            carefully, as they describe your rights and "OPTIONAL" in restrictions with
            respect to this document. Code Components extracted from this
            document are to be interpreted must include Simplified BSD License text as described in BCP 14 <xref target="RFC2119"/>
        <xref target="RFC8174"/> when,
            Section 4.e of the Trust Legal Provisions and only when, they
        appear in all capitals, are provided without
            warranty as shown here. described in the Simplified BSD License.
        </t>
    </section>

    <section title="Trust Model" anchor="sec.proposal.trusthierarchy">
      <t>
        <t indent="0" pn="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The basic assumption of this architecture is that network resources
        exist person(s) controlling the copyright in a hierarchy some of trust, rooted in the browser, which serves as
        the user's Trusted Computing Base (TCB). Any security property which the
        user wishes to this
            material may not have enforced must be ultimately guaranteed by granted the
        browser (or transitively by some property IETF Trust the browser
        verifies). Conversely, if right to allow
            modifications of such material outside the browser is compromised, then no security
        guarantees are possible.  Note that there are cases (e.g., Internet
        kiosks) where IETF Standards Process.
            Without obtaining an adequate license from the user can't really trust person(s)
            controlling the browser that much. In
        these cases, copyright in such materials, this document may not
            be modified outside the level IETF Standards Process, and derivative
            works of security provided is limited by how much they
        trust the browser.
      </t>
      <t>
        Optimally, we would it may not rely on trust in any entities other than be created outside the
        browser. However, this is unfortunately not possible if we wish IETF Standards Process,
            except to have
        a functional system.  Other network elements fall format it for publication as an RFC or to translate it
            into two categories:
        those which can be authenticated by the browser languages other than English.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trust-model">Trust Model</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authenticated-entities">Authenticated Entities</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unauthenticated-entities">Unauthenticated Entities</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-signaling">Initial Signaling</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-consent-verification">Media Consent Verification</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-handshake">DTLS Handshake</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-and-consent-">Communications and thus can be granted
        permissions to access sensitive resources, Consent Freshness</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-identity-attribute">SDP Identity Attribute</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offer-answer-considerations">Offer/Answer Considerations</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-initial-sdp-">Generating the Initial SDP Offer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-an-sdp-answer">Generating an SDP Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-an-sdp-offer-or-">Processing an SDP Offer or Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-the-session">Modifying the Session</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detailed-technical-descript">Detailed Technical Description</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-origin-and-web-security-iss">Origin and those which cannot be
        authenticated Web Security Issues</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-device-permissions-model">Device Permissions Model</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-consent">Communications Consent</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-location-privacy">IP Location Privacy</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-security">Communications Security</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-web-based-peer-authenticati">Web-Based Peer Authentication</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trust-relationships-idps-ap">Trust Relationships: IdPs, APs, and thus are untrusted.
      </t>

      <section title="Authenticated Entities" anchor="sec.proposal.authenticated">
        <t>
          There are two major classes RPs</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-operation">Overview of Operation</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-items-for-standardization">Items for Standardization</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-binding-identity-assertions">Binding Identity Assertions to JSEP Offer/Answer Transactions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.4.2">
                  <li pn="section-toc.1-1.7.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.4.2.1.1"><xref derivedContent="7.4.1" format="counter" sectionFormat="of" target="section-7.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-carrying-identity-assertion">Carrying Identity Assertions</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-determining-the-idp-uri">Determining the IdP URI</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.5.2">
                  <li pn="section-toc.1-1.7.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.1.1"><xref derivedContent="7.5.1" format="counter" sectionFormat="of" target="section-7.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authenticating-party">Authenticating Party</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.5.2.2.1"><xref derivedContent="7.5.2" format="counter" sectionFormat="of" target="section-7.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relying-party">Relying Party</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requesting-assertions">Requesting Assertions</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-managing-user-login">Managing User Login</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verifying-assertions">Verifying Assertions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identity-formats">Identity Formats</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-security-2">Communications Security</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy">Privacy</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-denial-of-service">Denial of Service</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-idp-authentication-mechanis">IdP Authentication Mechanism</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.4.2">
                  <li pn="section-toc.1-1.9.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.9.2.4.2.1.1"><xref derivedContent="9.4.1" format="counter" sectionFormat="of" target="section-9.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-peerconnection-origin-check">PeerConnection Origin Check</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.9.2.4.2.2.1"><xref derivedContent="9.4.2" format="counter" sectionFormat="of" target="section-9.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-idp-well-known-uri">IdP Well-Known URI</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.9.2.4.2.3.1"><xref derivedContent="9.4.3" format="counter" sectionFormat="of" target="section-9.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-of-idp-generated-id">Privacy of IdP-Generated Identities and the Hosting Site</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.9.2.4.2.4.1"><xref derivedContent="9.4.4" format="counter" sectionFormat="of" target="section-9.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-of-third-party-idp">Security of authenticated entities in Third-Party IdPs</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.4.2.4.2">
                      <li pn="section-toc.1-1.9.2.4.2.4.2.1">
                        <t indent="0" pn="section-toc.1-1.9.2.4.2.4.2.1.1"><xref derivedContent="9.4.4.1" format="counter" sectionFormat="of" target="section-9.4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confusable-characters">Confusable Characters</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.9.2.4.2.5">
                    <t indent="0" pn="section-toc.1-1.9.2.4.2.5.1"><xref derivedContent="9.4.5" format="counter" sectionFormat="of" target="section-9.4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-web-security-feature-intera">Web Security Feature Interactions</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.4.2.5.2">
                      <li pn="section-toc.1-1.9.2.4.2.5.2.1">
                        <t indent="0" pn="section-toc.1-1.9.2.4.2.5.2.1.1"><xref derivedContent="9.4.5.1" format="counter" sectionFormat="of" target="section-9.4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-popup-blocking">Popup Blocking</xref></t>
                      </li>
                      <li pn="section-toc.1-1.9.2.4.2.5.2.2">
                        <t indent="0" pn="section-toc.1-1.9.2.4.2.5.2.2.1"><xref derivedContent="9.4.5.2" format="counter" sectionFormat="of" target="section-9.4.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-third-party-cookies">Third Party Cookies</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec.introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
        The Real-Time Communications on the system:
        </t>
        <t>
          <list style="symbols">
            <t>
              Calling services: Web sites whose origin we can verify (optimally
              via HTTPS, but in some (RTCWEB) Working Group
        standardized protocols for real-time communications between Web
        browsers, generally called "WebRTC" <xref target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>.
        The major use cases because we for WebRTC technology are on a topologically
              restricted network, such as behind a firewall, real-time audio
        and/or video calls, Web conferencing, and can infer
              authentication from firewall behavior).
            </t>
            <t>
              Other users: WebRTC peers whose origin we can verify
              cryptographically (optimally direct data transfer. Unlike
        most conventional real-time systems (e.g., SIP-based <xref target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/> soft phones), WebRTC communications are directly
        controlled by some Web server, via DTLS-SRTP).
            </t>
          </list> a JavaScript (JS) API as shown in
        <xref target="fig.simple" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
      </t>
        <t>
          Note that merely being authenticated does not make these entities
          trusted. For instance, just because we can verify that
          https://www.example.org/ 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
      <figure anchor="fig.simple" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-a-simple-webrtc-system">A Simple WebRTC System</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-2.1">
                         +----------------+
                         |                |
                         |   Web Server   |
                         |                |
                         +----------------+
                             ^        ^
                            /          \
                    HTTP   /            \   HTTP
                          /              \
                         /                \
                        v                  v
                     JS API              JS API
               +-----------+            +-----------+
               |           |    Media   |           |
               |  Browser  |&lt;----------&gt;|  Browser  |
               |           |            |           |
               +-----------+            +-----------+ </artwork>
      </figure>
      <t indent="0" pn="section-1-3">
        A more complicated system might allow for ransom payment), it's safe to temporarily give him
          access inter-domain calling, as shown
        in <xref target="fig.multidomain" format="default" sectionFormat="of" derivedContent="Figure 2"/>.  The protocol to be used between
        the camera domains is not standardized by WebRTC, but given the installed base
        and microphone for the purpose form of the call, but
          he doesn't want Dr. Evil WebRTC API is likely to be able to access his camera and
          microphone other than during something SDP-based like
        SIP or something like the call. The point here is that we must
          first identify other elements before we can determine whether Extensible Messaging and how
          much to trust them. Additionally, sometimes we need to identify the
          communicating peer before we know what policies to apply. Presence Protocol (XMPP)
        <xref target="RFC6120" format="default" sectionFormat="of" derivedContent="RFC6120"/>.
      </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.
      <figure anchor="fig.multidomain" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-a-multidomain-webrtc-system">A Multidomain WebRTC System</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-4.1">
          +--------------+                +--------------+
          |              | SIP, XMPP, ... |              |
          |  Web Server  |&lt;--------------&gt;|  Web Server  |
          |              |                |              |
          +--------------+                +--------------+
                 ^                                ^
                 |                                |
           HTTP  |                                |  HTTP
                 |                                |
                 v                                v
                 JS API                       JS API
           +-----------+                     +-----------+
           |           |        Media        |           |
           |  Browser  |&lt;-------------------&gt;|  Browser  |
           |           |                     |           |
           +-----------+                     +-----------+ </artwork>
      </figure>
      <t indent="0" pn="section-1-5">
        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 presents a number of new security challenges, which is secure even if they do so.
        </t>
      </section>
    </section>
    <!-- Not layered ? -->

    <section title="Overview" anchor="sec.proposal.overview">
      <!-- TODO: Federated -->
      <t> are
        analyzed in <xref target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/>.  This section document
        describes a typical security architecture for WebRTC session and shows how which addresses the
        various security elements interact threats
        and what guarantees requirements described in that document.
      </t>
    </section>
    <section anchor="sec-term" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are provided
    to
        the user. The example be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>
    </section>
    <section anchor="sec.proposal.trusthierarchy" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-trust-model">Trust Model</name>
      <t indent="0" pn="section-3-1">
        The basic assumption of this section architecture is that network resources
        exist in a "best case" scenario hierarchy of trust, rooted in the browser, which serves as
        the user's Trusted Computing Base (TCB). Any security property which
        we provide the maximal amount of
        user authentication and media privacy
        with wishes to have enforced must be ultimately guaranteed by the minimal level of trust in
        browser (or transitively by some property the calling service. Simpler versions
        with lower levels of browser
        verifies). Conversely, if the browser is compromised, then no security
        guarantees are also possible and possible.  Note that there are noted in the
        text cases (e.g., Internet
        kiosks) where applicable. It's also important to recognize the tension
        between user can't really trust the browser that much. In
        these cases, the level of security (or performance) and privacy. The example shown here provided is
        aimed towards settings where limited by how much they
        trust the browser.
      </t>
      <t indent="0" pn="section-3-2">
        Optimally, we are more concerned about secure calling would not rely on trust in any entities other than about privacy, but as the
        browser. However, this is unfortunately not possible if we shall see, there are settings where one
        might wish to make different tradeoffs--this architecture is still
        compatible with have
        a functional system.  Other network elements fall into two categories:
        those settings.
      </t>
      <t>
        For which can be authenticated by the purposes browser and thus can be granted
        permissions to access sensitive resources, and those which cannot be
        authenticated and thus are untrusted.
      </t>
      <section anchor="sec.proposal.authenticated" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-authenticated-entities">Authenticated Entities</name>
        <t indent="0" pn="section-3.1-1">
          There are two major classes of this example, we assume the topology shown authenticated entities in the
        figures below. This topology is derived from the topology shown in <xref
        target="fig.simple"/>, system:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.1-2">
          <dt pn="section-3.1-2.1">Calling services:</dt>
          <dd pn="section-3.1-2.2">Web sites whose origin we can verify (optimally
              via HTTPS, but separates Alice and Bob's identities from the
        process of signaling.  Specifically, Alice and Bob have relationships
        with in some Identity Provider (IdP) that supports cases because we are on a protocol (such topologically
              restricted network, such as
        OpenID Connect) that behind a firewall, and can be used to demonstrate their identity to
        other parties. infer
              authentication from firewall behavior).</dd>
          <dt pn="section-3.1-2.3">Other users:</dt>
          <dd pn="section-3.1-2.4">WebRTC peers whose origin we can verify
              cryptographically (optimally via DTLS-SRTP).</dd>
        </dl>
        <t indent="0" pn="section-3.1-3">
          Note that merely being authenticated does not make these entities
          trusted. For instance, Alice might have an account with a social
        network which she just because we can then use to authenticate to other web sites
        without explicitly having an account with those sites; this verify that
          &lt;https://www.example.org/&gt; is a fairly
        conventional pattern on owned by Dr. Evil does not mean that we can
          trust Dr. Evil to access our camera and microphone. However, it gives
          the Web. <xref
        target="sec.trust-relationships"/> provides user an overview of Identity
        Providers and opportunity to determine whether they wish to trust
          Dr. Evil or not; after all, if they desire to contact Dr. Evil (perhaps
          to arrange for ransom payment), it's safe to temporarily give them
          access to the relevant terminology.  Alice and Bob might have
        relationships with different IdPs as well.
      </t>
      <t>
        This separation of identity provision and signaling isn't particularly
        important in "closed world" cases where Alice camera and Bob are users on microphone for the
        same social network and have identities based on that domain (<xref
        target="fig.proposal.idp"/>). However, there are important settings where
        that is not purpose of the case, such as federation (calls from one domain to
        another; <xref target="fig.proposal-federated.idp"/>) and calling on
        untrusted sites, such as where two users who have a relationship via a
        given social network call, but
          they don't want Dr. Evil to call each be able to access their camera and
          microphone other on another, untrusted,
        site, such as a poker site.
      </t>
      <t>
        Note that than during the servers themselves are also authenticated by an external
        identity service, the SSL/TLS certificate infrastructure (not shown).
        As call. The point here is conventional in the Web, all identities are ultimately rooted in that system. For instance, when an IdP makes an identity assertion, we must
          first identify other elements before we can determine whether and how
          much to trust them. Additionally, sometimes we need to identify the
        Relying Party consuming that assertion is
          communicating peer before we know what policies to apply.
        </t>
      </section>
      <section anchor="sec.proposal.unauthenticated" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-unauthenticated-entities">Unauthenticated Entities</name>
        <t indent="0" pn="section-3.2-1">
          Other than the above entities, we are not generally able to verify because identify
          other network elements; thus, we cannot trust them.  This does not mean
          that 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 it
          means that we must assume that they will behave maliciously and design
          a call between two separate domains (i.e., system which is secure even if they do so.
        </t>
      </section>
    </section>
    <section anchor="sec.proposal.overview" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-4-1">
        This section describes a
        federated case), as in <xref target="fig.multidomain"/>. As mentioned
        above, the domains communicate by some unspecified protocol 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 the inter-domain protocol.
      </t>
      <figure title="A federated call 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 user. The example in <xref
          target="fig.proposal.idp"/>.  Alice and Bob are both users of this section is a common
          calling service; they both have approved the calling service to make
          calls (we defer "best case" scenario in which
        we provide the discussion maximal amount of device access permissions until
          later).  They are both connected to the calling service via HTTPS user authentication and
          so know the origin media privacy
        with some the minimal level of confidence. They also have
          accounts trust in the calling service. Simpler versions
        with some identity provider.  This sort lower levels of identity service
          is becoming increasingly common security are also possible and are noted in the Web environment (with technologies
          such as Federated Google Login, Facebook Connect, OAuth,
          OpenID, WebFinger), and is often provided
        text where applicable. It's also important to recognize the tension
        between security (or performance) and privacy. The example shown here is
        aimed towards settings where we are more concerned about secure calling
        than about privacy, but as a side effect service of
          a user's ordinary accounts we shall see, there are settings where one
        might wish to make different tradeoffs -- this architecture is still
        compatible with some service. In those settings.
      </t>
      <t indent="0" pn="section-4-2">
        For the purposes of this example, we show
          Alice and Bob using a separate identity service, though the identity
          service may be assume the same entity as topology shown in the calling service or there may be
          no identity service at all.
        </t>
        <t>
          Alice
        figures below. This topology is logged onto the calling service and decides to call Bob.  She
          can see derived from the calling service that he is online and the calling
          service presents a JS UI topology shown in <xref target="fig.simple" format="default" sectionFormat="of" derivedContent="Figure 1"/>, 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 authenticate to other Web sites
        without explicitly having an account with those sites; this
          far.
        </t>

        <t>
          Once the PeerConnection is created, a fairly
        conventional pattern on the calling service JS needs to
          set up some media. Because this is an audio/video call, it creates a
          MediaStream with two MediaStreamTracks, one connected to Web. <xref target="sec.trust-relationships" format="default" sectionFormat="of" derivedContent="Section 7.1"/> provides an audio
          input overview of IdPs
        and one connected to a video input. At this point the first
          security check is required: untrusted origins are relevant terminology.  Alice and Bob might have
        relationships with different IdPs as well.
        Note: The IdP mechanism described here has not allowed to
          access seen wide adoption.
        See <xref target="sec.generic.idp" format="default" sectionFormat="of" derivedContent="Section 7"/> for more on the camera status of
        IdP-based authentication.
      </t>
      <t indent="0" pn="section-4-3">
        This separation of identity provision and microphone, so the browser prompts signaling isn't particularly
        important in "closed world" cases where Alice for
          permission.
        </t>
        <t>
          In 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" sectionFormat="of" derivedContent="Figure 3"/>). 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" sectionFormat="of" derivedContent="Figure 4"/>) 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 the signaling message, the PeerConnection code
          contacts
      <t indent="0" pn="section-4-4">
        Note that the identity service and obtains servers themselves are also authenticated by an assertion binding Alice's external
        identity to her fingerprint. The exact details depend on service, the identity
          service (though as discussed SSL/TLS certificate infrastructure (not shown).
        As is conventional 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 Web, all identities are ultimately rooted in
        that system. For instance, when an IdP makes an identity besides assertion, the fingerprint, but at minimum it
          needs
        Relying Party consuming that assertion is able to bind the fingerprint.
        </t>
        <t>
          This message verify because it is sent
        able to connect to the signaling server, e.g., by XMLHttpRequest
          <xref target="XmlHttpRequest"/> or by WebSockets <xref
          target="RFC6455"/>, over TLS IdP via HTTPS.
      </t>
      <figure anchor="fig.proposal.idp" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-a-call-with-idp-based-ident">A Call with IdP-Based Identity</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-5.1">
                            +----------------+
                            |                |
                            |     Signaling  |
                            |     Server     |
                            |                |
                            +----------------+
                                ^        ^
                               /          \
                       HTTPS  /            \   HTTPS
                             /              \
                            /                \
                           v                  v
                        JS API              JS API
                  +-----------+            +-----------+
                  |           |    Media   |           |
            Alice |  Browser  |&lt;----------&gt;|  Browser  | Bob
                  |           | (DTLS+SRTP)|           |
                  +-----------+            +-----------+
                        ^      ^--+     +--^     ^
                        |         |     |        |
                        v         |     |        v
                  +-----------+   |     |  +-----------+
                  |           |&lt;--------+  |           |
                  |   IdP1    |   |        |    IdP2   |
                  |           |   +-------&gt;|           |
                  +-----------+            +-----------+ </artwork>
      </figure>
      <t indent="0" pn="section-4-6">
        <xref target="RFC5246"/>.
          The signaling server processes target="fig.proposal-federated.idp" format="default" sectionFormat="of" derivedContent="Figure 4"/> 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
        federated case), as in <xref target="fig.multidomain" format="default" sectionFormat="of" derivedContent="Figure 2"/>. As mentioned
        above, the domains communicate by some unspecified protocol, and
        providing separate signaling message and identity allows for calls to
          Bob's browser (again, be
        authenticated regardless of the format is currently undefined).  The details of the inter-domain protocol.
      </t>
      <figure anchor="fig.proposal-federated.idp" align="left" suppress-title="false" pn="figure-4">
        <name slugifiedName="name-a-federated-call-with-idp-b">A Federated Call with IdP-Based Identity</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-7.1">
        +----------------+    Unspecified    +----------------+
        |                |      protocol     |                |
        |    Signaling   |&lt;-----------------&gt;|    Signaling   |
        |    Server      |  (SIP, XMPP, ...) |    Server      |
        |                |                   |                |
        +----------------+                   +----------------+
                 ^                                   ^
                 |                                   |
           HTTPS |                                   | HTTPS
                 |                                   |
                 |                                   |
                 v                                   v
              JS on
          Bob's browser processes it, and alerts API                               JS API
        +-----------+                             +-----------+
        |           |             Media           |           |
  Alice |  Browser  |&lt;---------------------------&gt;|  Browser  | Bob to
        |           |           DTLS+SRTP         |           |
        +-----------+                             +-----------+
              ^      ^--+                      +--^     ^
              |         |                      |        |
              v         |                      |        v
        +-----------+   |                      |  +-----------+
        |           |&lt;-------------------------+  |           |
        |   IdP1    |   |                         |    IdP2   |
        |           |   +------------------------&gt;|           |
        +-----------+                             +-----------+ </artwork>
      </figure>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-initial-signaling">Initial Signaling</name>
        <t indent="0" pn="section-4.1-1">
          For simplicity, assume the incoming call and to
          Alice's identity. In this case, topology in <xref target="fig.proposal.idp" format="default" sectionFormat="of" derivedContent="Figure 3"/>.  Alice has provided an identity
          assertion and so Bob's browser contacts Alice's identity provider
          (again, this is done in Bob are both users of a generic way so common
          calling service; they both have approved the browser has no specific
          knowledge of calling service to make
          calls (we defer the IdP) discussion of device access permissions until
          later).  They are both connected to verify the assertion. It is calling service via HTTPS and
          so know the origin with some level of confidence. They also possible
          to have IdPs
          accounts with which the browser has a specific trustrelationship,
          as described in <xref target="sec.trust-relationships"/>. some IdP.  This allows the browser
          to display a trusted element in the browser chrome indicating that a
          call is coming in from Alice. If Alice sort of identity service
          is becoming increasingly common in Bob's address book, then
          this interface might also include her real name, a picture, etc.  The
          calling site will also provide some user interface element (e.g., a
          button) to allow Bob to answer the call, though this is most likely
          not part of the trusted UI.
        </t>
        <t>
          If Bob agrees a PeerConnection is instantiated with the message from
          Alice's side.  Then, a similar process occurs Web environment (with technologies
          such as on Alice's browser:
          Bob's browser prompts him for device permission, the media streams are
          created, and a return signaling message containing media information,
          ICE candidates, 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 indent="0" pn="section-4.1-2">
          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. 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.
        </t>
        <t>
          Of course, the call works perfectly well if either Alice or Bob
          doesn't have
          require a relationship with an IdP; they just security check: JS from any origin is allowed to get a lower level
          of assurance. I.e., they simply have whatever information their
          calling site claims about this
          far.
        </t>
        <t indent="0" pn="section-4.1-3">
          Once the caller/callee's identity.  Moreover,
          Alice might wish to make an anonymous call through an anonymous
          calling site, in which case she would of course just not provide any
          identity assertion and PeerConnection is created, 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 service JS needs to
          set up some media. Because this is provided via ICE.  Thus, Alice and
          Bob perform ICE checks an audio/video call, it creates a
          MediaStream with each other.  At the completion of these
          checks, they are ready two MediaStreamTracks, one connected to send non-ICE data.
        </t>
        <t> an audio
          input and one connected to 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 to exchange traffic with her and (b) that either Bob is at
          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 Alice and Bob
          but required: untrusted origins are not attached to the signaling service allowed to spoof these checks
          because they do not have
          access the ICE credentials. Bob has camera and microphone, so the same
          security guarantees with respect to Alice. browser prompts Alice for
          permission.
        </t>
      </section>

      <section title="DTLS Handshake">
        <t>
          Once
        <t indent="0" pn="section-4.1-4">
          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" sectionFormat="of" derivedContent="RFC8829"/> containing:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-5">
          <li pn="section-4.1-5.1">
              Media channel information
          </li>
          <li pn="section-4.1-5.2">
              Interactive Connectivity Establishment (ICE) <xref target="RFC3711"/> for target="RFC8445" format="default" sectionFormat="of" derivedContent="RFC8445"/> candidates
          </li>
          <li pn="section-4.1-5.3">
              A "fingerprint" attribute binding the media channel and SCTP over DTLS communication to a key pair
              <xref target="RFC8261"/> target="RFC5763" format="default" sectionFormat="of" derivedContent="RFC5763"/>. 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 indent="0" pn="section-4.1-6">
          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" sectionFormat="of" derivedContent="Section 7"/>
          PeerConnection can be agnostic to key SRTP them), but for now it's easiest to
          think of as an OAuth token.  The assertion may bind other
          information to the media channels. identity besides the fingerprint, but at minimum it
          needs to bind the fingerprint.
        </t>
        <t>
          At
        <t indent="0" pn="section-4.1-7">
          This message is sent to the signaling server, e.g., by fetch()
          <xref target="fetch" format="default" sectionFormat="of" derivedContent="fetch"/> or by WebSockets
          <xref target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/>, over TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.
          The signaling server processes the message from Alice's browser,
          determines that this point, Alice is a call to Bob, and Bob know that they share sends a set of secure data
          and/or media channels with keys which are not known signaling message to any third-party
          attacker. If Alice
          Bob's browser (again, the format is currently undefined).  The JS on
          Bob's browser processes it, and alerts Bob authenticated via their IdPs, then they
          also know that to the signaling service incoming call and to
          Alice's identity. In this case, Alice has provided an identity
          assertion and so Bob's browser contacts Alice's IdP
          (again, this is not mounting done in a
          man-in-the-middle attack on their traffic. Even if they do not use an
          IdP, as long as they generic way so the browser has no specific
          knowledge of the IdP) to verify the assertion. It is also possible
          to have minimal IdPs with which the browser has a specific trust relationship,
          as described in <xref target="sec.trust-relationships" format="default" sectionFormat="of" derivedContent="Section 7.1"/>.
          This allows the signaling service not browser
          to perform display a man-in-the-middle attack, they know that their
          communications are secure against the signaling service as well (i.e.,
          that trusted element in the signaling service cannot mount browser chrome indicating that a passive attack on
          call is coming in from Alice. If Alice is in Bob's address book, then
          this interface might also include her real name, a picture, etc.  The
          calling site will also provide some user interface element (e.g., a
          button) to allow Bob to answer the
          communications). call, though this is most likely
          not part of the trusted UI.
        </t>

      </section>

      <section title="Communications and Consent Freshness">
        <t>
          From
        <t indent="0" pn="section-4.1-8">
          If Bob agrees, a security perspective, everything PeerConnection is instantiated with the message from here
          Alice's side.  Then, a similar process occurs as on in Alice's browser:
          Bob's browser prompts him for device permission, the media streams are
          created, and a return signaling message containing media information,
          ICE candidates, and a fingerprint is sent back to Alice via the
          signaling service.  If Bob has a little
          anticlimactic: relationship with an IdP, the message
          will also come with an identity assertion.
        </t>
        <t indent="0" pn="section-4.1-9">
          At this point, Alice and Bob exchange data protected by each know that the keys
          negotiated by DTLS. Because of other party wants to
          have a secure call with them. Based purely on the security guarantees discussed in interface provided
          by the previous sections, signaling server, they know that the communications are encrypted
          and authenticated.
        </t>
        <t>
          The one remaining security property we need to establish is "consent
          freshness", i.e., allowing Alice to verify signaling server claims
          that Bob the call is still prepared
          to receive her communications so that from Alice does not continue to send
          large traffic volumes to entities which went abruptly offline. ICE
          specifies periodic STUN keepalives but only if media Bob. This level of security is not flowing.
          Because provided
          merely by having the consent issue is more difficult here, we require WebRTC
          implementations to periodically send keepalives.  As described fingerprint in
          Section 5.3, these keepalives MUST be based on the consent freshness
          mechanism specified in <xref target="RFC7675"/>.  If a
          keepalive fails message and no new ICE channels can be established, then 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 having that
        is used by
          message received securely from the signaling server.  Because the far
          end sent an endpoint to convey its identity assertion to its
        peer. The identity assertion value along with their message, they know
          that this is encoded verifiable from the IdP as Base-64, well. Note that if the call is
          federated, as described shown in Section 4 of <xref target="RFC4648"/>.
      </t>
      <t>
        The procedures target="fig.proposal-federated.idp" format="default" sectionFormat="of" derivedContent="Figure 4"/>,
          then Alice is able to verify Bob's identity in this section are based on the assumption a way that the identity assertion of an endpoint is bound to the
        fingerprints of the endpoint. This does not preclude the definition of
        alternative means of binding an assertion to the endpoint, but such
        means are outside the scope of this specification.
          mediated by either her signaling server or Bob's. Rather, she verifies
          it directly with Bob's IdP.
        </t>
      <t>
        The semantics of multiple 'identity' attributes within an
        offer
        <t indent="0" pn="section-4.1-10">
          Of course, the call works perfectly well if either Alice or answer are undefined.  Implementations SHOULD only include Bob
          doesn't have a
        single 'identity' attribute in relationship with an offer or answer and relying parties
        MAY elect to ignore all but IdP; they just get a lower level
          of assurance. I.e., they simply have whatever information their
          calling site claims about 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 caller/callee's identity.  Moreover,
          Alice might wish to make an anonymous call through an anonymous
          calling site, in [RFC4566]>

 Example:

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

  Note that long lines 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 numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-media-consent-verification">Media Consent Verification</name>
        <t indent="0" pn="section-4.2-1">
          As described in <xref target="RFC8826" sectionFormat="comma" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8826#section-4.2" derivedContent="RFC8826"/>, media consent verification is provided via ICE.
  Thus, Alice and
          Bob perform ICE checks with each other.  At the example completion of these
          checks, they are folded ready to meet the column
  width constraints of send non-ICE data.
        </t>
        <t indent="0" pn="section-4.2-2">
          At this document; point, Alice knows that (a) Bob (assuming he is verified via
          his IdP) or someone else who the backslash ("\") signaling service is claiming is Bob
          is willing to exchange traffic with her and (b) either Bob is at
          the end of
  a line, IP address which she has verified via ICE or there is an attacker
          who is on-path to that IP address detouring the carriage return traffic. Note that follows, and whitespace shall be ignored.

      ]]></artwork>
       </figure>
       <t>
         This specification does it
          is not define any extensions possible for the attribute.
       </t>
       <t>
         The identity-assertion value is a JSON <xref target="RFC8259"/> encoded string. The JSON object
         contains two keys: "assertion" and "idp". The <spanx style="verb">assertion</spanx> key value contains an opaque string that attacker who is consumed by the IdP. The <spanx style="verb">idp</spanx> key value contains a
         dictionary with one or two further values that identify 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 on-path between Alice and Bob
          but not attached to the SDP
           'identity' attribute.
         </t>
         <t>
           Within this section, 'initial offer' refers signaling service to spoof these checks
          because they do not have the first offer in ICE credentials. Bob has the
           SDP session that contains an SDP <spanx style="verb">identity</spanx> attribute. same
          security guarantees with respect to Alice.
        </t>
      </section>
      <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 to numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-dtls-handshake">DTLS Handshake</name>
        <t indent="0" pn="section-4.3-1">
          Once the peer, it includes an 'identity' attribute in requisite ICE checks have completed, Alice and Bob can set
          up a secure channel or channels. This is performed via DTLS <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>
          and DTLS-SRTP <xref target="RFC5763" format="default" sectionFormat="of" derivedContent="RFC5763"/> keying for SRTP
          <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/> for the offer. In addition, media channel and
          the offerer includes one or more SDP
           'fingerprint' attributes. Stream Control Transmission Protocol (SCTP) over DTLS
          <xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC8261"/> for data
          channels. Specifically, Alice and Bob perform a DTLS handshake on
          every component which has been established by ICE. The 'identity' attribute MUST be bound to
           all the 'fingerprint' attributes in total number of
          channels depends on the session
           description.
         </t>
         </section>
         <section title="Generating amount of SDP Answer" anchor="sec.sdp-id-attr-oa-ansa">
           <t>
             If muxing; in the answerer elects to include an 'identity' attribute, it follows most likely case, we
          are using both RTP/RTCP mux and muxing multiple media streams on the
          same steps as those channel, in which case there is only one DTLS handshake. Once the
          DTLS handshake has completed, the keys are exported <xref target="sec.sdp-id-attr-oa-inio"/>.
             The answerer can choose target="RFC5705" format="default" sectionFormat="of" derivedContent="RFC5705"/> and used to include or omit an 'identity' attribute independently,
             regardless of whether key SRTP for the offerer did so. media channels.
        </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 that contains an 'identity'
             attribute, the answerer can use the the attribute information to
             contact the IdP
        <t indent="0" pn="section-4.3-2">
          At this point, Alice and verify the identity Bob know that they share a set of the peer. secure data
          and/or media channels with keys which are not known to any third-party
          attacker. If Alice and Bob authenticated via their IdPs, then they
          also know that the identity
             requires signaling service is not mounting a third-party IdP
          man-in-the-middle attack on their traffic. Even if they do not use an
          IdP, as described long as they have minimal trust in <xref target="sec.trust-relationships"/>
             then that IdP will need the signaling service not
          to have been specifically configured.
             If perform a man-in-the-middle attack, they know that their
          communications are secure against the identity verification fails, signaling service as well (i.e.,
          that the answerer MUST discard signaling service cannot mount a passive attack on the
             offer or answer as malformed.
          communications).
        </t>
      </section>
      <section title="Modifying the Session" anchor="sec.sdp-id-attr-oa-modi">
           <t>
             When modifying numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-communications-and-consent-">Communications and Consent Freshness</name>
        <t indent="0" pn="section-4.4-1">
          From a session, if the set of fingerprints security perspective, everything from here on in is
             unchanged, then a little
          anticlimactic: Alice and Bob exchange data protected by the sender MAY send keys
          negotiated by DTLS. Because of the same 'identity' attribute. In
             this case, security guarantees discussed in
          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 previous sections, they know that each media section use the same set of
             fingerprints for every media section.
             If a new identity attribute communications are encrypted
          and authenticated.
        </t>
        <t indent="0" pn="section-4.4-2">
          The one remaining security property we need to establish is received, then the receiver MUST
             apply "consent
          freshness", i.e., allowing Alice to verify that identity Bob is still prepared
          to receive her communications so that Alice does not continue to all existing connections.
           </t>
           <t>
             If the set of fingerprints changes, then the sender MUST
             either send a new 'identity' attribute or none at all.
          large traffic volumes to entities which went abruptly offline. ICE
          specifies periodic Session Traversal Utilities for NAT (STUN) keepalives but only if media is not flowing.
          Because a change the consent issue is more difficult here, we require WebRTC
          implementations to periodically send keepalives using the
          consent freshness
          mechanism specified in fingerprints also causes <xref target="RFC7675" format="default" sectionFormat="of" derivedContent="RFC7675"/>.
  If a
          keepalive fails and no new DTLS
             connection to ICE channels can be established, then the receiver MUST discard
             all previously established identities.
          session is terminated.
        </t>
      </section>
    </section>
    </section>
    <section title="Detailed Technical Description" anchor="sec.proposal.detailed">

      <section title="Origin and Web Security Issues" anchor="sec.proposal.origin">
        <t> anchor="sec.sdp-id-attr" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-sdp-identity-attribute">SDP Identity Attribute</name>
      <t indent="0" pn="section-5-1">
        The basic unit of permissions for WebRTC SDP "identity" attribute is the origin 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="RFC6454"/>. Because target="RFC4648" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent="RFC4648"/>.
      </t>
      <t indent="0" pn="section-5-2">
        The procedures in this section are based on the security assumption
        that the identity assertion of an endpoint is bound to the origin depends on
          being able
        fingerprints of the endpoint. This does not preclude the definition of
        alternative means of binding an assertion to authenticate content from that origin, the origin can endpoint, but such
        means are outside the scope of this specification.
      </t>
      <t indent="0" pn="section-5-3">
        The semantics of multiple "identity" attributes within an
        offer or answer are undefined.  Implementations <bcp14>SHOULD</bcp14> only be securely established if data is transferred over HTTPS <xref
          target="RFC2818"/>. Thus, clients MUST treat HTTP include a
        single "identity" attribute in an offer or answer, and HTTPS origins as
          different permissions domains. Note: this follows directly from Relying Parties
        <bcp14>MAY</bcp14> elect to ignore all but the
          origin security model and is stated here merely for clarity. first "identity" attribute.
      </t>
        <t>
          Many web browsers currently forbid by default any active mixed content
          on HTTPS pages. That is, when JavaScript is loaded
      <dl newline="false" spacing="normal" indent="3" pn="section-5-4">
        <dt pn="section-5-4.1">Name:</dt>
        <dd pn="section-5-4.2">identity</dd>
        <dt pn="section-5-4.3">Value:</dt>
        <dd pn="section-5-4.4">identity-assertion</dd>
        <dt pn="section-5-4.5">Usage Level:</dt>
        <dd pn="section-5-4.6">session</dd>
        <dt pn="section-5-4.7">Charset Dependent:</dt>
        <dd pn="section-5-4.8">no</dd>
        <dt pn="section-5-4.9">Default Value:</dt>
        <dd pn="section-5-4.10">N/A</dd>
      </dl>
      <t indent="0" pn="section-5-5">Syntax:</t>
      <sourcecode name="abnf-1" type="abnf" markers="false" pn="section-5-6">
 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 an HTTP origin
          onto an HTTPS page, an error is displayed [RFC4566]

 &lt;ALPHA and the HTTP content is not
          executed unless the user overrides the error. Any browser which
          enforces such a 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 MUST
          nevertheless disable WebRTC functionality DIGIT as defined in mixed content settings.
        </t>
        <t>
          Note [RFC4566]&gt;
 &lt;base64 as defined in [RFC4566]&gt;
</sourcecode>
      <t indent="0" pn="section-5-7">Example:</t>
      <sourcecode name="sdp-1" type="sdp" markers="false" pn="section-5-8">
 a=identity:\
   eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
   In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
   IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
   aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9</sourcecode>
      <aside pn="section-5-9">
        <t indent="0" pn="section-5-9.1">Note that it is possible for a page which was not mixed content long lines in the example are folded to
          become mixed content during meet the duration column
  width constraints of this document; the call.  The major risk
          here is that backslash ("\") at the newly arrived insecure JS might redirect media to end of
  a
          location controlled by the attacker.  Implementations MUST either
          choose to terminate line, the call or display a warning at that point.
        </t>
        <t>
          Also note carriage return that the security architecture depends on the keying material follows, and whitespace shall be ignored.</t>
      </aside>
      <t indent="0" pn="section-5-10">
         This specification does not being available to move between origins.  But, it define any extensions for the attribute.
      </t>
      <t indent="0" pn="section-5-11">
         The identity-assertion value is assumed a JSON encoded string
         <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>. The JSON object
         contains two keys: "assertion" and "idp". The "assertion" key value contains
         an opaque string that is consumed by the identity assertion can be passed to anyone IdP. The "idp" key value contains a
         dictionary with one or two further values that identify the page cares to. IdP. See
         <xref target="sec.request-assert" format="default" sectionFormat="of" derivedContent="Section 7.6"/> for more details.
      </t>
      </section>
      <section title="Device Permissions Model" anchor="sec.proposal.device.permissions">
        <t>
          Implementations MUST obtain explicit user consent prior to providing
          access to the camera and/or microphone. Implementations MUST at
          minimum support anchor="sec.sdp-id-attr-oa" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-offer-answer-considerations">Offer/Answer Considerations</name>
        <t indent="0" pn="section-5.1-1">
           This section defines 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 SDP offer/answer <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/> considerations for
          HTTP origins. the SDP
           "identity" attribute.
        </t>
        <t>
          In addition, they SHOULD support requests for access that promise that
          media from
        <t indent="0" pn="section-5.1-2">
           Within this grant will be sent section, 'initial offer' refers to a single communicating peer
          (obviously there could be other requests for other peers), eE.g.,
          "Call customerservice@example.org".  The semantics of this request are
          that the media stream from first offer in the camera and microphone will only be
          routed through a connection which has been cryptographically verified
          (through
           SDP session that contains an SDP "identity" attribute.
        </t>
        <section anchor="sec.sdp-id-attr-oa-inio" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-generating-the-initial-sdp-">Generating the IdP mechanism or Initial SDP Offer</name>
          <t indent="0" pn="section-5.1.1-1">
           When an X.509 certificate offerer sends an offer, in order to provide its
           identity assertion to the DTLS-SRTP
          handshake) as being associated with the stated identity. Note that peer, it
          is unlikely that browsers would have X.509 certificates, but servers
          might.  Browsers servicing such requests SHOULD clearly indicate that
          identity to includes an "identity" attribute in
           the user when asking for permission. offer. In addition, the offerer includes one or more SDP
           "fingerprint" attributes.  The idea behind this
          type of permissions is that a user might have a fairly narrow list of
          peers he is willing "identity" attribute <bcp14>MUST</bcp14> be bound to communicate with, e.g., "my mother" rather than
          "anyone on Facebook". Narrow permissions grants allow
           all the browser to
          do that enforcement. "fingerprint" attributes in the session
           description.
          </t>

        <t>
          <list style="hanging">
        </section>
        <section anchor="sec.sdp-id-attr-oa-ansa" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-generating-an-sdp-answer">Generating an SDP Answer</name>
          <t hangText="API Requirement:">
              The API MUST provide a mechanism for indent="0" pn="section-5.1.2-1">
             If the requesting JS answerer elects to
              relinquish include an "identity" attribute, it follows
             the ability same steps as those in <xref target="sec.sdp-id-attr-oa-inio" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>.
             The answerer can choose to see include or modify the media (e.g., via
              MediaStream.record()).  Combined with secure authentication omit an "identity" attribute independently,
             regardless of whether the
              communicating peer, this allows a user to be sure that the calling
              site is not accessing or modifying their conversion.
            </t>
          </list> offerer did so.
          </t>

        <t>
          <list style="hanging">
        </section>
        <section anchor="sec.sdp-id-attr-oa-offa" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-processing-an-sdp-offer-or-">Processing an SDP Offer or Answer</name>
          <t hangText="UI Requirement:">
              The UI MUST clearly indicate when indent="0" pn="section-5.1.3-1">
             When an endpoint receives an offer or answer that contains an "identity"
             attribute, the user's camera and microphone
              are in use.  This indication MUST NOT be suppressable by answerer can use the JS
              and MUST clearly indicate how to terminate device access, and
              provide a UI means attribute information to immediately stop camera/microphone input
              without
             contact the JS being able to prevent it.
            </t>
          </list>
        </t>

        <t>
          <list style="hanging">
            <t hangText="UI Requirement:">
              If IdP and verify the UI indication identity of camera/microphone use are displayed in the
              browser such that minimizing peer. If the browser window would hide identity
             requires a third-party IdP as described in <xref target="sec.trust-relationships" format="default" sectionFormat="of" derivedContent="Section 7.1"/>,
             then that IdP will need to have been specifically configured.
             If the
              indication, identity verification fails, the answerer <bcp14>MUST</bcp14> discard the
             offer or answer as malformed.
          </t>
        </section>
        <section anchor="sec.sdp-id-attr-oa-modi" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.4">
          <name slugifiedName="name-modifying-the-session">Modifying the JS creating an overlapping window would hide Session</name>
          <t indent="0" pn="section-5.1.4-1">
             When modifying a session, if the indication, set of fingerprints is
             unchanged, then the browser SHOULD stop camera and microphone
              input when sender <bcp14>MAY</bcp14> send the indication is hidden.  [Note: same "identity" attribute. In
             this may not case, the established identity <bcp14>MUST</bcp14> be
              necessary in systems that are non-windows-based but that have good
              notifications support, such as phones.]
            </t>
          </list>
        </t>

        <t>
          <list style="symbols">
            <t>
              Browsers MUST NOT permit permanent screen or application sharing
              permissions applied to be installed existing DTLS
             connections as a response to a JS request for
              permissions. Instead, they must require some other user action
              such well as a permissions setting or an application install experience
              to grant permission to a site.
            </t>
            <t>
              Browsers MUST provide a separate dialog request for
              screen/application sharing permissions even if the new connections established using one of those
             fingerprints. Note that <xref target="RFC8829" sectionFormat="comma" section="5.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8829#section-5.2.1" derivedContent="RFC8829"/> requires that each media request
              is made at section use the same time as camera and microphone.
            </t>

            <t>
              The browser MUST indicate any windows which are currently being
              shared in some unambiguous way. Windows which are not visible MUST
              NOT be shared even if the application is being shared. set of fingerprints.
             If the
              screen a new "identity" attribute is being shared, received, then the receiver <bcp14>MUST</bcp14>
             apply that MUST be indicated.
            </t>
          </list> identity to all existing connections.
          </t>

        <t>
          Browsers MAY permit
          <t indent="0" pn="section-5.1.4-2">
             If the formation set of data channels without any direct
          user approval. Because sites can always tunnel data through fingerprints changes, then the
          server, further restrictions on the data channel do not provide any
          additional security.  (See <xref
          target="sec.proposal.communications.consent"/> for a related issue).
        </t>
        <t>
          Implementations which support some form of direct user authentication
          SHOULD also provide sender <bcp14>MUST</bcp14>
             either send a policy by which new "identity" attribute or none at all.
             Because a user can authorize calls only
          to specific communicating peers. Specifically, the implementation
          SHOULD provide the following interfaces/controls:
        </t>
        <t>
          <list style="symbols">
            <t>
              Allow future calls to this verified user.
            </t>
            <t>
              Allow future calls to any verified user who is change in my system
              address book (this only works with address book integration, of
              course).
            </t>
          </list>
        </t>
        <t>
          Implementations SHOULD fingerprints also provide causes a different user interface
          indication when calls are in progress new DTLS
             connection to users whose identities are
          directly verifiable.  <xref target="sec.proposal.comsec"/> provides
          more on this. be established, the receiver <bcp14>MUST</bcp14> discard
             all previously established identities.
          </t>
        </section>
      </section>
    </section>
    <section title="Communications Consent" anchor="sec.proposal.communications.consent">

        <t>
          Browser client implementations anchor="sec.proposal.detailed" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-detailed-technical-descript">Detailed Technical Description</name>
      <section anchor="sec.proposal.origin" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-origin-and-web-security-iss">Origin and Web Security Issues</name>
        <t indent="0" pn="section-6.1-1">
          The basic unit of permissions for WebRTC MUST implement ICE.  Server
          gateway implementations which operate only at public IP addresses MUST
          implement either full ICE 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 is the ICE transaction ID to JavaScript during origin <xref target="RFC6454" format="default" sectionFormat="of" derivedContent="RFC6454"/>. Because the
          lifetime security of the transaction (i.e., during the period when the ICE
          stack would accept a new response for that transaction).  The JS MUST
          NOT be permitted origin depends on
          being able to control authenticate content from that origin, the local ufrag and password, though it of
          course knows it.
        </t>
        <t> <!-- FIXME: phrasing of first sentence still awkward -->
          While continuing consent origin can
          only be securely established if data is required, the ICE <xref
          target="RFC8445"/>; Section 10 keepalives use STUN Binding Indications which are
          one-way transferred over HTTPS <xref target="RFC2818" format="default" sectionFormat="of" derivedContent="RFC2818"/>. Thus, clients <bcp14>MUST</bcp14> treat HTTP and HTTPS origins as
          different permissions domains. Note: This follows directly from the
          origin security model and therefore not sufficient.  The current WG consensus is to
          use ICE Binding Requests stated here merely for continuing consent freshness. ICE already
          requires that implementations respond to such requests, so this
          approach is maximally compatible. A separate document will profile the
          ICE timers to be used; see <xref target="RFC7675"/>. clarity.
        </t>
      </section>

      <section title="IP Location Privacy" anchor="sec.proposal.ip.location.privacy">
        <t>
          A side effect of the
        <t indent="0" pn="section-6.1-2">
          Many Web browsers currently forbid by default ICE behavior any active mixed content
          on HTTPS pages. That is, when JavaScript is that loaded from an HTTP origin
          onto an HTTPS page, an error is displayed and 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 this section are intended to
          mitigate this issue. Note that these requirements are HTTP content is not intended to
          protect
          executed unless the user's IP address from a malicious site. In general, user overrides the
          site will learn at least error. Any browser which
          enforces such a user's server reflexive address from any
          HTTP transaction.  Rather, these requirements are intended 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 indent="0" pn="section-6.1-3">
          Note that it is possible for a
          site page which was not mixed content to cooperate with
          become mixed content during the user to hide the user's IP address from the
          other side duration 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://www.torproject.org/projects/torbrowser.html.en]) and
          is out of scope for this specification.
        </t>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">  The API MUST provide a mechanism to allow major risk
          here is that the newly arrived insecure JS might redirect media to suppress ICE
              negotiation (though perhaps to allow candidate gathering) until a
          location controlled by the user has decided attacker.  Implementations <bcp14>MUST</bcp14> either
          choose to answer the call [note: determining when terminate the call has been answered is or display a question for warning at that point.
        </t>
        <t indent="0" pn="section-6.1-4">
          Also note that the JS.]  This
              enables a user to prevent a peer from learning their IP address if
              they elect security architecture depends on the keying material
          not being available to answer a call and also from learning whether the
              user move between origins.  However, it is online.
            </t>
          </list>
        </t>

        <t>
          <list style="hanging">
            <t hangText="API Requirement:">
              The API MUST provide a mechanism for assumed that
          the calling application JS identity assertion can be passed to
              indicate anyone that only TURN candidates are the page cares to.
        </t>
      </section>
      <section anchor="sec.proposal.device.permissions" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-device-permissions-model">Device Permissions Model</name>
        <t indent="0" pn="section-6.2-1">
          Implementations <bcp14>MUST</bcp14> obtain explicit user consent prior to providing
          access to be used. This prevents the peer from learning one's IP address camera and/or microphone. Implementations <bcp14>MUST</bcp14> at all.  This mechanism
              MUST also permit suppression of
          minimum support the related address field, since
              that leaks local addresses.
            </t>
          </list> following two permissions models for HTTPS
          origins.
        </t>

        <t>
          <list style="hanging">
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-2">
          <li pn="section-6.2-2.1">
              Requests for one-time camera/microphone access.
          </li>
          <li pn="section-6.2-2.2">
              Requests for permanent access.
          </li>
        </ul>
        <t hangText="API Requirement:">
              The API MUST provide a mechanism indent="0" pn="section-6.2-3">
          Because HTTP origins cannot be securely established against network
          attackers, implementations <bcp14>MUST</bcp14> refuse all permissions grants for the calling application to
              reconfigure an existing call
          HTTP origins.
        </t>
        <t indent="0" pn="section-6.2-4">
          In addition, they <bcp14>SHOULD</bcp14> support requests for access that promise that
          media from this grant will be sent to add non-TURN candidates.  Taken
              together, a 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 media stream from the camera and microphone will only be
          routed through a connection which has been cryptographically verified
          (through the previous requirement allow ICE negotiation
              to start immediately on incoming call notification, thus reducing
              post-dial delay, but also to avoid disclosing IdP mechanism or an X.509 certificate in the user's IP
              address until they DTLS-SRTP
          handshake) as being associated with the stated identity. Note that it
          is unlikely that browsers would have decided to answer. They also allow users X.509 certificates, but servers
          might.  Browsers servicing such requests <bcp14>SHOULD</bcp14> clearly indicate that
          identity to completely hide their IP address for the duration user when asking for permission.  The idea behind this
          type of the
              call. Finally, permissions is that a user might have a fairly narrow list of
          peers they are willing to communicate with, e.g., "my mother" rather than
          "anyone on Facebook". Narrow permissions grants allow the browser to
          do that enforcement.
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.2-5">
          <dt pn="section-6.2-5.1">API Requirement:</dt>
          <dd pn="section-6.2-5.2">
              The API <bcp14>MUST</bcp14> provide a mechanism for the user requesting JS to optimize
              performance by reconfiguring
              relinquish the ability to allow non-TURN candidates during
              an active call if see or modify the media (e.g., via
              MediaStream.record()).  Combined with secure authentication of the
              communicating peer, this allows a user decides they no longer need to hide
              their IP address
            </t>
          </list>
        </t>

        <t>
          Note be sure 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 calling
              site is not accessing or modifying their conversion.
          </dd>
        </dl>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.2-6">
          <dt pn="section-6.2-6.1">UI Requirement:</dt>
          <dd pn="section-6.2-6.2">
              The UI <bcp14>MUST</bcp14> clearly indicate when the HTTP/HTTPS user's camera and modify the SDP and/or microphone
              are in use.  This indication <bcp14>MUST NOT</bcp14> be suppressible by the JS, or
          there needs JS
              and <bcp14>MUST</bcp14> clearly indicate how to be browser support terminate device access, and
              provide a UI means to set immediately stop camera/microphone input
              without the "TURN-only" policy
          regardless JS being able to prevent it.
          </dd>
        </dl>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.2-7">
          <dt pn="section-6.2-7.1">UI Requirement:</dt>
          <dd pn="section-6.2-7.2">
              If the UI indication of camera/microphone use is displayed in the site's preferences.
        </t>
      </section>

      <section title="Communications Security" anchor="sec.proposal.comsec">
        <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 DTLS <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;
              browser such that is, implementations MUST
          NOT negotiate cipher suites with NULL encryption modes.  DTLS-SRTP
          MUST be offered for every media channel.  WebRTC implementations MUST NOT
          offer SDP Security Descriptions <xref target="RFC4568"/> minimizing the browser window would hide the
              indication, or select it if offered.
          A SRTP MKI MUST NOT be used.
        </t>
        <t>
          All data channels MUST be secured via DTLS.
        </t>
        <t>
         All Implementations MUST support DTLS 1.2 with the
          TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and JS creating an overlapping window would hide
              the
          <xref target="FIPS186">P-256 curve</xref>.
          Earlier drafts of this specification required
          DTLS 1.0 with indication, then the cipher suite
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, browser <bcp14>SHOULD</bcp14> stop camera and at microphone
              input when the time of this
          writing some implementations do indication is hidden.  (Note: This may not support DTLS 1.2;
          endpoints which support 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 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 is intended
              necessary in systems that are non-windows-based but that have good
              notifications support, such as phones.)
          </dd>
        </dl>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-8">
          <li pn="section-6.2-8.1">
              Browsers <bcp14>MUST NOT</bcp14> permit permanent screen or application sharing
              permissions to allow for unlinkability.
            </t>
            <t hangText="API Requirement:">
              The API MUST provide be installed as a means response to reuse a key pair JS request for calls.  This
              can be used to enable key continuity-based authentication, and
              could be used to amortize key generation costs.
            </t>
            <t hangText="API Requirement:">
              Unless
              the
              permissions. Instead, they must require some other user specifically configures an external key pair, different
              key pairs MUST be used for each origin. (This avoids creating action
              such as a
              super-cookie.)
            </t>
            <t hangText="API Requirement:">
              When DTLS-SRTP is used, the API MUST NOT permit the JS permissions setting or an application install experience
              to obtain
              the negotiated keying material. This requirement preserves the
              end-to-end security of the media.
            </t>
          </list>
        </t>

        <t>
          <list style="hanging">
            <t hangText="UI Requirements: ">
              A user-oriented client MUST grant permission to a site.
          </li>
          <li pn="section-6.2-8.2">
              Browsers <bcp14>MUST</bcp14> provide an "inspector" interface which
              allows a separate dialog request for
              screen/application sharing permissions even if the user to determine media request
              is made at the security characteristics of same time as the
              media.
            </t>
            <t> request for camera and microphone
              permissions.
          </li>
          <li pn="section-6.2-8.3">
              The following properties SHOULD be displayed "up-front" in the browser chrome, i.e., without requiring the user to ask <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 application is being shared.  If the
              screen is being shared, then that <bcp14>MUST</bcp14> be indicated.
          </li>
        </ul>
        <t indent="0" pn="section-6.2-9">
          Browsers <bcp14>MAY</bcp14> permit the formation of data channels without any direct
          user approval. Because sites can always tunnel data through the
          server, further restrictions on the data channel do not provide any
          additional security.  (See <xref target="sec.proposal.communications.consent" format="default" sectionFormat="of" derivedContent="Section 6.3"/> for them: a related issue.)
        </t>
            <t>
              <list style="symbols">
                <t>
                  A client MUST
        <t indent="0" pn="section-6.2-10">
          Implementations which support some form of direct user authentication
          <bcp14>SHOULD</bcp14> also provide a user interface through policy by which a user
                  may determine can authorize calls only
          to specific communicating peers. Specifically, the security characteristics for
                  currently-displayed audio and video stream(s) implementation
          <bcp14>SHOULD</bcp14> provide the following interfaces/controls:
        </t>

                <t>
                  A client MUST
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-11">
          <li pn="section-6.2-11.1">
              Allow future calls to this verified user.
          </li>
          <li pn="section-6.2-11.2">
              Allow future calls to any verified user who is in my system
              address book (this only works with address book integration, of
              course).
          </li>
        </ul>
        <t indent="0" pn="section-6.2-12">
          Implementations <bcp14>SHOULD</bcp14> also provide a different user interface through which a user
                  may determine the security characteristics for transmissions
                  of their microphone audio and camera video.
                </t>

                <t>
                  If the far endpoint was
          indication when calls are in progress to users whose identities are
          directly verified, verifiable.  <xref target="sec.proposal.comsec" format="default" sectionFormat="of" derivedContent="Section 6.5"/> provides
          more on this.
        </t>
      </section>
      <section anchor="sec.proposal.communications.consent" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-communications-consent">Communications Consent</name>
        <t indent="0" pn="section-6.3-1">
          Browser client implementations of WebRTC <bcp14>MUST</bcp14> implement ICE.  Server
          gateway implementations which operate only at public IP addresses <bcp14>MUST</bcp14>
          implement either via a
                  third-party verifiable X.509 certificate full ICE or ICE-Lite <xref target="RFC8445" format="default" sectionFormat="of" derivedContent="RFC8445"/>.
        </t>
        <t indent="0" pn="section-6.3-2">
          Browser implementations <bcp14>MUST</bcp14> verify reachability via ICE prior to
          sending any non-ICE packets to a Web IdP
                  mechanism (see <xref target="sec.generic.idp"/>) given destination.  Implementations
          <bcp14>MUST NOT</bcp14> provide the "security
                  characteristics" MUST include ICE transaction ID to JavaScript during the verified information.  X.509
                  identities and Web IdP identities have similar semantics and
                  should be displayed in
          lifetime of the transaction (i.e., during the period when the ICE
          stack would accept a similar way.
                </t>
              </list>
            </t>
            <t>
            </t>
            <t> new response for that transaction).  The following properties are more likely JS <bcp14>MUST NOT</bcp14> be permitted to require some
              "drill-down" from control the user: local ufrag and password, though it of
          course knows it.
        </t>
            <t>
              <list style="symbols">
                <t>
                  The "security characteristics" MUST indicate
        <t indent="0" pn="section-6.3-3">
          While continuing consent is required, the cryptographic
                  algorithms in ICE <xref target="RFC8445" sectionFormat="comma" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8445#section-11" derivedContent="RFC8445"/> keepalives use (For example: "AES-CBC".)
                </t>

                <t> STUN Binding Indications, which are
          one-way and therefore not sufficient.  The "security characteristics" MUST indicate whether PFS current WG consensus is
                  provided.
                </t>

                <t>
                  The "security characteristics" MUST include some mechanism to
                  allow an out-of-band verification of the peer,
          use ICE Binding Requests for continuing consent freshness. ICE already
          requires that implementations respond to such as a
                  certificate fingerprint or a Short Authentication String (SAS).
                  These are compared by requests, so this
          approach is maximally compatible. A separate document will profile the peers
          ICE timers to authenticate one another.
                </t>
              </list>
            </t>
          </list> be used; see <xref target="RFC7675" format="default" sectionFormat="of" derivedContent="RFC7675"/>.
        </t>
      </section>
    </section>
      <section title="Web-Based Peer Authentication" anchor="sec.generic.idp">
        <t>
          In a number anchor="sec.proposal.ip.location.privacy" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-ip-location-privacy">IP Location Privacy</name>
        <t indent="0" pn="section-6.4-1">
          A side effect of cases, it is desirable for the endpoint (i.e., default ICE behavior is that the
          browser) 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 this section are intended to be able
          mitigate this issue. Note that these requirements are not intended to directly identify the endpoint on
          protect the other
          side without trusting user's IP address from a malicious site. In general, the signaling service to which they are
          connected. For instance, users may be making
          site will learn at least a call via user's server-reflexive address from any
          HTTP transaction.  Rather, these requirements are intended to allow a federated
          system where they wish
          site to get direct authentication of cooperate with the user to hide the user's IP address from the
          other
          side. Alternately, they may be making 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 <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" indent="3" pn="section-6.4-2">
          <dt pn="section-6.4-2.1">API Requirement:</dt>
          <dd pn="section-6.4-2.2">
              The API <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 on has been answered is a site which they
          minimally trust (such as question for the JS.)  This
              enables a poker site) but user to someone who has an
          identity on prevent a site peer from learning their IP address if
              they do trust (such as a social network.)
        </t>
        <t>
          Recently, elect not to answer a number of Web-based identity technologies (OAuth,
          Facebook Connect etc.) have been developed. While call and also from learning whether the
          details vary, what these technologies share
              user is that they have online.
          </dd>
        </dl>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.4-3">
          <dt pn="section-6.4-3.1">API Requirement:</dt>
          <dd pn="section-6.4-3.2">
              The API <bcp14>MUST</bcp14> provide a
          Web-based (i.e., HTTP/HTTPS) identity provider which attests to Alice's
          identity. For instance, if Alice has an account at example.org, Alice could
          use mechanism for the example.org identity provider to prove calling application JS to others
              indicate that Alice is
          alice@example.org.  The development of these technologies allows us only TURN candidates are to
          separate calling be used. This prevents
              the peer from identity provision: Alice could call you on 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" indent="3" pn="section-6.4-4">
          <dt pn="section-6.4-4.1">API Requirement:</dt>
          <dd pn="section-6.4-4.2">
              The API <bcp14>MUST</bcp14> provide a
          poker site 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 identify herself as alice@example.org.
        </t>
        <t>
          Whatever also to avoid disclosing the underlying technology, user's IP
              address until they have decided to answer. They also allow users
              to completely hide their IP address for the general principle is that duration of the
          party which is being authenticated is NOT
              call. Finally, they allow a mechanism for the signaling site but
          rather user to optimize
              performance by reconfiguring to allow non-TURN candidates during
              an active call if the user (and decides they no longer need to hide
              their browser). Similarly, IP address.
          </dd>
        </dl>
        <t indent="0" pn="section-6.4-5">
          Note that some enterprises may operate proxies and/or NATs designed to
          hide internal IP addresses from the relying party is outside world. WebRTC provides no
          explicit mechanism to allow this function. Either such enterprises
          need to proxy the browser HTTP/HTTPS and not modify the signaling site.  Thus, SDP and/or the JS, or
          there needs to be browser MUST
          generate the input support to set the IdP assertion process and
          display the results "TURN-only" policy
          regardless of the verification process site's preferences.
        </t>
        <t indent="0" pn="section-6.4-6">
          Note: These requirements are intended to allow sites to conceal the user
          in a way which cannot be imitated by
          user's IP address from the peer. For guidance on concealing the
          user's IP address from the calling site. site see <xref target="RFC8828" format="default" sectionFormat="of" derivedContent="RFC8828"/>.
        </t>
        <t>
          The mechanisms defined in this document do not require the browser to
          implement any particular identity protocol or to
      </section>
      <section anchor="sec.proposal.comsec" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-communications-security">Communications Security</name>
        <t indent="0" pn="section-6.5-1">
          Implementations <bcp14>MUST</bcp14> support any
          particular IdP. Instead, this document provides a generic interface
          which any IdP can implement. Thus, new IdPs SRTP <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/>.
          Implementations <bcp14>MUST</bcp14> support DTLS <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> and protocols can
          DTLS-SRTP <xref target="RFC5763" format="default" sectionFormat="of" derivedContent="RFC5763"/> <xref target="RFC5764" format="default" sectionFormat="of" derivedContent="RFC5764"/> for SRTP
          keying. Implementations <bcp14>MUST</bcp14> support SCTP over DTLS <xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC8261"/>.
        </t>
        <t indent="0" pn="section-6.5-2">
          All media channels <bcp14>MUST</bcp14> be
          introduced without change to either secured via SRTP and the browser
          Secure Real-time Transport Control Protocol (SRTCP).  Media traffic <bcp14>MUST NOT</bcp14>
          be sent over plain (unencrypted) RTP 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 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" sectionFormat="of" derivedContent="RFC4568"/> or 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 to establish its identity.
              </t>
              <t> select it if offered.
          An SRTP Master Key Identifier (MKI) <bcp14>MUST NOT</bcp14> be used.
        </t>
        <t hangText="Identity Provider (IdP):">
                The entity which is vouching for the AP's identity.
              </t>

              <t> indent="0" pn="section-6.5-3">
          All data channels <bcp14>MUST</bcp14> be secured via DTLS.
        </t>
        <t hangText="Relying Party (RP):">
                The entity which is trying to verify indent="0" pn="section-6.5-4">
         All implementations <bcp14>MUST</bcp14> support DTLS 1.2 with the AP's identity.
              </t>
            </list>
          </t>
          <t>
            The AP
          TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the IdP have an account relationship
          <xref target="FIPS186" format="default" sectionFormat="of" derivedContent="FIPS186">P-256 curve</xref>.
          Earlier drafts of some kind: the AP
            registers this specification required
          DTLS 1.0 with the IdP cipher suite
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and is able to subsequently authenticate
            directly to the IdP (e.g., with a password). This means that at the
            browser must somehow know time of this
          writing some implementations do not support DTLS 1.2;
          endpoints which IdP(s) 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 Forward Secrecy (FS)
          over non-FS cipher suites and <bcp14>SHOULD</bcp14> favor
          Authenticated Encryption with Associated Data (AEAD) over non-AEAD cipher suites.
          Note: the user has an account
            relationship with. IETF is in the process of standardizing DTLS 1.3
          <xref target="I-D.ietf-tls-dtls13" format="default" sectionFormat="of" derivedContent="TLS-DTLS13"/>.
        </t>
        <t indent="0" pn="section-6.5-5">
          Implementations <bcp14>MUST NOT</bcp14> implement DTLS renegotiation and <bcp14>MUST</bcp14> reject
          it with a "no_renegotiation" alert if offered.</t>
        <t indent="0" pn="section-6.5-6">
          Endpoints <bcp14>MUST NOT</bcp14> implement TLS False Start <xref target="RFC7918" format="default" sectionFormat="of" derivedContent="RFC7918"/>.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.5-7">
          <dt pn="section-6.5-7.1">API Requirement:</dt>
          <dd pn="section-6.5-7.2">
              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 pn="section-6.5-7.3">API Requirement:</dt>
          <dd pn="section-6.5-7.4">
              The API <bcp14>MUST</bcp14> provide a means to reuse a key pair for calls.  This
              can either be something that used to enable key continuity-based authentication, and
              could be used to amortize key generation costs.
          </dd>
          <dt pn="section-6.5-7.5">API Requirement:</dt>
          <dd pn="section-6.5-7.6">
              Unless
              the user specifically configures into the browser or that an external key pair, different
              key pairs <bcp14>MUST</bcp14> be used for each origin. (This avoids creating a
              super-cookie.)
          </dd>
          <dt pn="section-6.5-7.7">API Requirement:</dt>
          <dd pn="section-6.5-7.8">
              When DTLS-SRTP is configured at used, the calling
            site and then provided API <bcp14>MUST NOT</bcp14> permit the JS to obtain
              the PeerConnection by negotiated keying material. This requirement preserves the Web application
            at
              end-to-end security of the calling site. media.
          </dd>
        </dl>
        <dl newline="false" spacing="normal" indent="3" pn="section-6.5-8">
          <dt pn="section-6.5-8.1">UI Requirements:</dt>
          <dd pn="section-6.5-8.2">
              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 pn="section-6.5-8.3"/>
          <dd pn="section-6.5-8.4">
              The use case for having this information
            configured into following properties <bcp14>SHOULD</bcp14> be displayed "up-front" in the
              browser is that chrome, i.e., without requiring 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 ask for the IdP
            information to simply be provided by the calling application.
          </t>
          <t>
            At them:
          </dd>
          <dt pn="section-6.5-8.5"/>
          <dd pn="section-6.5-8.6">
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-8.6.1">
              <li pn="section-6.5-8.6.1.1">
                  A client <bcp14>MUST</bcp14> provide a high level there are two kinds of IdPs:
          </t>
          <t>
            <list style="hanging">
              <t hangText="Authoritative: ">
                IdPs user interface through which have verifiable control of some section of the
                identity space. For instance, in the realm of e-mail, the
                operator of "example.com" has complete control of the namespace
                ending in "@example.com". Thus, "alice@example.com" is whoever a user
                  may determine the operator says it is. Examples of systems with authoritative
                identity providers include DNSSEC, RFC 4474, "security characteristics" for
                  currently displayed audio and Facebook
                Connect (Facebook identities only make sense within the context
                of the Facebook system).
              </t>

              <t>
              </t>
              <t hangText="Third-Party: ">
                IdPs video stream(s).
              </li>
              <li pn="section-6.5-8.6.1.2">
                  A client <bcp14>MUST</bcp14> provide a user interface through which don't have control a user
                  may determine the "security characteristics" for transmissions
                  of their section of the identity
                space but instead verify user's identities via some unspecified
                mechanism microphone audio and then attest to it. Because camera video.
              </li>
              <li pn="section-6.5-8.6.1.3">
                  If the far endpoint was directly verified, either via a
                  third-party verifiable X.509 certificate or via a Web IdP doesn't
                actually control
                  mechanism (see <xref target="sec.generic.idp" format="default" sectionFormat="of" derivedContent="Section 7"/>), the namespace, RPs need to trust that "security
                  characteristics" <bcp14>MUST</bcp14> include the verified information.  X.509
                  identities and Web IdP
                is correctly verifying AP identities, identities have similar semantics and there can potentially
                  should be multiple IdPs attesting displayed in a similar way.
              </li>
            </ul>
          </dd>
          <dt pn="section-6.5-8.7"/>
          <dd pn="section-6.5-8.8">
              The following properties are more likely to require some
              "drill-down" from the same section of the identity
                space. Probably user:
          </dd>
          <dt pn="section-6.5-8.9"/>
          <dd pn="section-6.5-8.10">
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-8.10.1">
              <li pn="section-6.5-8.10.1.1">
                  The "security characteristics" <bcp14>MUST</bcp14> indicate the best-known example of a third-party identity
                provider cryptographic
                  algorithms in use (for example, "AES-CBC").
              </li>
              <li pn="section-6.5-8.10.1.2">
                  The "security characteristics" <bcp14>MUST</bcp14> indicate whether FS is SSL/TLS certificates, where there are a large number of
                CAs all of whom can attest
                  provided.
              </li>
              <li pn="section-6.5-8.10.1.3">
                  The "security characteristics" <bcp14>MUST</bcp14> include some mechanism to any domain name.
              </t>
            </list>
          </t>

          <t>
            If an AP is authenticating via
                  allow an authoritative IdP, then out-of-band verification of the RP
            does not need to explicitly configure trust in peer, such as a
                  certificate fingerprint or a Short Authentication String (SAS).
                  These are compared by the IdP at all. peers to authenticate one another.
              </li>
            </ul>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="sec.generic.idp" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-web-based-peer-authenticati">Web-Based Peer Authentication</name>
      <t indent="0" pn="section-7-1">
        NOTE: The
            identity mechanism can directly verify that the IdP indeed made the
            relevant identity assertion (a function provided by the mechanisms described in this document), and any assertion it makes section was designed relatively
        early in the RTCWEB process. In retrospect, the WG was too optimistic
        about an identity the enthusiasm for
            which it is authoritative is directly verifiable. Note that this
            does not mean that kind of mechanism. At the IdP might time of publication,
        it has not lie, but that is been widely adopted or implemented. It appears in this document
        as a
            trustworthiness judgement that the user can make at description of the time he
            looks at state of the identity. art as of this writing.
      </t>
          <t>
            By contrast, if an AP is authenticating via
      <t indent="0" pn="section-7-2">
          In a third-party IdP, number of cases, it is desirable for the
            RP needs to explicitly trust that IdP (hence endpoint (i.e., the need for an
            explicit trust anchor list in PKI-based SSL/TLS clients). The list
            of trustable IdPs needs
          browser) to be configured able to directly into the browser,
            either by identify the user or potentially by endpoint on the browser manufacturer. This
            is a significant advantage of authoritative IdPs and implies that if
            third-party IdPs are to be supported, other
          side without trusting the potential number needs signaling service to which they are
          connected. For instance, users may be fairly small.
          </t>
        </section>

        <section title="Overview of Operation" anchor="sec.overview">
          <t>
            In order making a call via a federated
          system where they wish to provide security without trusting the calling site, get direct authentication of the
            PeerConnection component 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 indent="0" pn="section-7-3">
          Recently, a number of Web-based identity technologies (OAuth,
          Facebook Connect, etc.) have been developed. While the browser must interact directly with
          details vary, what these technologies share is that they have a
          Web-based (i.e., HTTP/HTTPS) IdP which attests to Alice's
          identity. For instance, if Alice has an account at example.org, Alice could
          use the IdP. example.org IdP to prove to others that Alice is
          alice@example.org.  The details development of the mechanism are described in the W3C API
            specification, 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 indent="0" pn="section-7-4">
          Whatever the underlying technology, the general idea principle is that the PeerConnection
            component downloads JS from a specific location on
          party which is being authenticated is NOT the IdP dictated
            by signaling site but
          rather the IdP domain name. That JS (the "IdP proxy") runs in an
            isolated security context within user (and their browser). Similarly, the Relying Party is
          the browser and not the PeerConnection
            talks signaling site.  Thus, the browser <bcp14>MUST</bcp14>
          generate the input to it via a secure message passing channel.
          </t>
          <t>
            Note that there are two logically separate functions here:
            <list style="symbols">
              <t>
                Identity assertion generation.
              </t>
              <t>
                Identity the IdP assertion verification.
              </t>
            </list>
          </t>
          <t>
            The same IdP JS "endpoint" is used for both functions but of course
            a given IdP might behave differently process and load new JS to perform one
            function or the other.
          </t>
          <figure>
            <artwork><![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>
          </figure>
          <t>
            When the PeerConnection object wants to interact with the IdP,
          display the
            sequence results of events is as follows:
            <list style="numbers">
              <t>
                The browser (the PeerConnection component) instantiates an IdP
                proxy. This allows the IdP verification process to load whatever JS is necessary into the proxy.  The resulting code runs user
          in a way which cannot be imitated by the IdP's security
                context. calling site.
      </t>
              <t>
      <t indent="0" pn="section-7-5">
          The IdP registers an object with the browser that conforms to
                the API mechanisms defined in <xref target="webrtc-api"/>.
              </t>
              <t>
                The browser invokes methods on the object registered by the IdP
                proxy to create or verify identity assertions.
              </t>
            </list>
          </t>
          <t>
            This approach allows us to decouple this document do not require the browser from to
          implement any particular identity provider; the browser need only know how protocol or to load the IdP's
            JavaScript--the location of support any
          particular IdP. Instead, this document provides a generic interface
          which is determined based on the IdP's
            identity--and to call the generic API for requesting and verifying
            identity assertions. The any IdP provides whatever logic is necessary to
            bridge the generic protocol can implement. Thus, new IdPs and protocols can be
          introduced without change to either the IdP's specific
            requirements. Thus, a single browser can support any number of
            identity protocols, including being forward compatible with IdPs
            which did not exist at or the time calling
          service. This avoids the browser was written.
          </t>
        </section>

        <section title="Items for Standardization" anchor="sec.standardized">
          <t>
            There are two parts need to this work:
          </t>
          <t>
            <list style="symbols">
              <t>
                The precise information from the signaling message that must be
                cryptographically bound make a commitment to the user's any particular
          identity and a mechanism
                for carrying assertions in JSEP messages. This is specified protocol, although browsers may opt to directly implement
          some identity protocols in
                <xref target="sec.jsep-binding"/>. order to provide superior performance or UI
          properties.
      </t>
      <section anchor="sec.trust-relationships" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-trust-relationships-idps-ap">Trust Relationships: IdPs, APs, and RPs</name>
        <t indent="0" pn="section-7.1-1">
            Any federated identity protocol has three major participants:
        </t>

              <t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.1-2">
          <dt pn="section-7.1-2.1">Authenticating Party (AP):</dt>
          <dd pn="section-7.1-2.2">
                The interface entity which is trying to the IdP, establish its identity.
          </dd>
          <dt pn="section-7.1-2.3">Identity Provider (IdP):</dt>
          <dd pn="section-7.1-2.4">
                The entity which is defined in vouching for the companion W3C
                WebRTC API specification <xref target="webrtc-api"/>.
              </t>
            </list>
          </t>
          <t> AP's identity.
          </dd>
          <dt pn="section-7.1-2.5">Relying Party (RP):</dt>
          <dd pn="section-7.1-2.6">
                The WebRTC API specification also defines JavaScript interfaces that
            the calling application can use to specify entity which IdP to use.  That
            API also provides access is trying to verify the assertion-generation capability AP's identity.
          </dd>
        </dl>
        <t indent="0" pn="section-7.1-3">
            The AP and the status IdP have an account relationship of some kind: the validation process.
          </t>
        </section>

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

          <t>
            An identity assertion binds the user's identity (as asserted by the
            IdP) to AP
            registers with the SDP offer/answer exchange IdP and specifically is able to the
            media. In order subsequently authenticate
            directly to achieve this, the PeerConnection IdP (e.g., with a password). This means that the
            browser must provide somehow know which IdP(s) the
            DTLS-SRTP fingerprint to user has an account
            relationship with.  This can either be bound to something that the identity. This is provided
            as a JavaScript object (also known as a dictionary user
            configures into the browser or hash) with a
            single <spanx style="verb">fingerprint</spanx> key, as shown below:
          </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>
            The <spanx style="verb">fingerprint</spanx> value that is an array of
            objects.  Each object in configured at the array contains <spanx
            style="verb">algorithm</spanx> calling
            site and <spanx
            style="verb">digest</spanx> values, which correspond directly then provided to the algorithm and digest values in the <spanx
            style="verb">fingerprint</spanx> attribute of PeerConnection by the SDP <xref
            target="RFC8122"/>.
          </t>
          <t>
            This object is encoded in a <xref target="RFC8259">JSON</xref>
            string for passing to Web application
            at the IdP. calling site. The identity assertion returned by
            the IdP, which is encoded in use case for having this information
            configured into the <spanx
            style="verb">identity</spanx> attribute, browser is a JSON object that is
            encoded as described in <xref target="sec.carry-assertion"/>.
          </t>
          <t>
            This structure does not need to be interpreted by the IdP or the
            IdP proxy. It is consumed solely by user may "log into" the RP's browser.  The IdP
            merely treats
            browser to bind it as an opaque value to be attested to.  Thus, some identity. This is becoming common in new
            parameters can
            browsers. However, it should also be added to the assertion without modifying possible for the
            IdP.
          </t>

          <section title="Carrying Identity Assertions" anchor="sec.carry-assertion">
            <t>
              Once an IdP has generated an assertion (see <xref
              target="sec.request-assert"/>), it is attached
            information to the SDP
              offer/answer message. This is done simply be provided by adding the calling application.
        </t>
        <t indent="0" pn="section-7.1-4">
            At a new 'identity'
              attribute to high level, there are two kinds of IdPs:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.1-5">
          <dt pn="section-7.1-5.1">Authoritative:</dt>
          <dd pn="section-7.1-5.2">
                IdPs which have verifiable control of some section of the SDP. The sole contents
                identity space. For instance, in the realm of this value 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
                IdPs include DNSSEC, an identity assertion.  The system for SIP
                (see <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="RFC8224"/>), and Facebook
                Connect (Facebook identities only make sense within the context
                of the Facebook system).
          </dd>
          <dt pn="section-7.1-5.3">Third-Party:</dt>
          <dd pn="section-7.1-5.4">
                IdPs which don't have control of their section of the identity assertion produced by
                space but instead verify users' identities via some unspecified
                mechanism and then attest to it. Because the IdP is
              encoded into a UTF-8 JSON text, then <xref
              target="RFC4648">Base64-encoded</xref> doesn't
                actually control the namespace, RPs need 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 trust that long lines in the example are folded IdP
                is correctly verifying AP identities, and there can potentially
                be multiple IdPs attesting to meet the column
  width constraints same section of this document; the backslash ("\") at identity
                space. Probably the end best-known example 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 third-party IdP
                is therefore SSL/TLS certificates, where there are a session-level attribute.
            </t>
            <t>
              Multiple <spanx style="verb">fingerprint</spanx> values large number of
                certificate authorities (CAs) all of whom can be
              used attest to offer alternative certificates for a peer.  The <spanx
              style="verb">identity</spanx> attribute MUST include all
              fingerprint values that are included in <spanx
              style="verb">fingerprint</spanx> attributes of any domain name.
          </dd>
        </dl>
        <t indent="0" pn="section-7.1-6">
            If an AP is authenticating via an authoritative IdP, then the session
              description.
            </t>
            <t>
              The RP browser MUST verify that the in-use certificate for a DTLS
              connection is
            does not need to explicitly configure trust in the set of fingerprints returned from the IdP
              when verifying an assertion.
            </t>
          </section>
        </section>

            <section title="Determining the IdP URI" anchor="sec.idp-uri">
              <t>
                In order to ensure at all.  The
            identity mechanism can directly verify that the IdP is under control of indeed made the domain
                owner rather than someone who merely has an account on
            relevant identity assertion (a function provided by the
                domain owner's server (e.g., mechanisms
            in shared hosting scenarios), this document), and any assertion it makes about an identity for
            which it is authoritative is directly verifiable. Note that this
            does not mean that the IdP JavaScript might not lie, but that is hosted at a deterministic location based on
            trustworthiness judgement that 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> user can make at which the
                       IdP's service is hosted. time they
            look at the identity.
        </t>
        <t hangText="protocol:">
                    The specific IdP protocol which the IdP is using. This indent="0" pn="section-7.1-7">
            By contrast, if an AP is authenticating via a
                    completely opaque IdP-specific string, but allows an IdP third-party IdP, the
            RP needs to
                    implement two protocols in parallel. This value may be explicitly trust that IdP (hence the
                    empty string.  If no value need for protocol is provided, a value an
            explicit trust anchor list in PKI-based SSL/TLS clients). The list
            of "default" is used.
                  </t>
                </list>
              </t>
              <t>
                Each IdP MUST serve its initial entry page (i.e., trustable IdPs needs to be configured directly into the one loaded browser,
            either by the IdP proxy) from a <xref target="RFC5785">well-known
                URI</xref>.  The well-known URI for an IdP proxy is formed from
                the following URI components:
                <list style="numbers">
                  <t>
                    The scheme, "https:".  An IdP MUST be loaded using <xref
                    target="RFC2818">HTTPS</xref>.
                  </t>
                  <t>
                    The <xref target="RFC3986">authority</xref>.  As noted above,
                    the authority MAY contain a  non-default port number user or
                    userinfo sub-component.  Both are removed when determining
                    if an asserted identity matches potentially by the name browser manufacturer. This
            is a significant advantage of the IdP.
                  </t>
                  <t>
                    The path, starting with "/.well-known/idp-proxy/" authoritative IdPs and
                    appended with the IdP protocol.  Note implies that the separator
                    characters '/' (%2F) and '\' (%5C) MUST NOT if
            third-party IdPs are to be permitted in supported, the protocol field, lest an attacker be able potential number needs to direct
                    requests outside of the controlled "/.well-known/" prefix.
                    Query and fragment values MAY
            be used by including '?' or
                    '#' characters.
                  </t>
                </list>
                For example, for the IdP "identity.example.com" and the protocol
                "example", the URL would be: fairly small.
        </t>
              <figure>
                <artwork><![CDATA[
  https://identity.example.com/.well-known/idp-proxy/example
  ]]></artwork>
              </figure>
              <t>
                The IdP MAY redirect requests
      </section>
      <section anchor="sec.overview" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-overview-of-operation">Overview of Operation</name>
        <t indent="0" pn="section-7.2-1">
            In order to this URL, but they MUST retain provide security without trusting the "https" scheme.  This changes calling site, the effective origin
            PeerConnection component of the
                IdP, but not browser must interact directly with
            the domain IdP. The details of the identities that mechanism are described in the IdP is
                permitted to assert and validate. I.e., W3C API
            specification, but the IdP general idea is still
                regarded as authoritative for that the original domain.
              </t>

              <section title="Authenticating Party">
                <t>
                  How an AP determines PeerConnection
            component downloads JS from a specific location on the IdP dictated
            by the appropriate IdP domain is out of
                  scope of this specification. In general, however, name. That JS (the "IdP proxy") runs in an
            isolated security context within the AP has
                  some actual account relationship browser, and the PeerConnection
            talks to it via a secure message passing channel.
        </t>
        <t indent="0" pn="section-7.2-2">
            Note that there are two logically separate functions here:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2-3">
          <li pn="section-7.2-3.1">
                Identity assertion generation.
          </li>
          <li pn="section-7.2-3.2">
                Identity assertion verification.
          </li>
        </ul>
        <t indent="0" pn="section-7.2-4">
            The same IdP JS "endpoint" is used for both functions, but of course
            a given IdP might behave differently and load new JS to perform one
            function or the other.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-7.2-5">
     +--------------------------------------+
     | Browser                              |
     |                                      |
     | +----------------------------------+ |
     | | https://calling-site.example.com | |
     | |                                  | |
     | |        Calling JS Code           | |
     | |               ^                  | |
     | +---------------|------------------+ |
     |                 | API Calls          |
     |                 v                    |
     |          PeerConnection              |
     |                 ^                    |
     |                 | API Calls          |
     |     +-----------|-------------+      |   +---------------+
     |     |           v             |      |   |               |
     |     |       IdP Proxy         |&lt;--------&gt;|   Identity    |
     |     |                         |      |   |   Provider    |
     |     | https://idp.example.org |      |   |               |
     |     +-------------------------+      |   +---------------+
     |                                      |
     +--------------------------------------+ </artwork>
        <t indent="0" pn="section-7.2-6">
            When the PeerConnection object wants to interact with the IdP, as this
                  identity the
            sequence of events is what as follows:
        </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.2-7">
          <li pn="section-7.2-7.1" derivedCounter="1.">
                The browser (the PeerConnection component) instantiates an IdP
                proxy. This allows the IdP to load whatever JS is attesting to. Thus, necessary into
                the AP somehow
                  supplies proxy.  The resulting code runs in the IdP's security
                context.
          </li>
          <li pn="section-7.2-7.2" derivedCounter="2.">
                The IdP information registers an object with the browser that conforms to
                the browser. Some potential
                  mechanisms include:
                  <list style="symbols">
                    <t>
                      Provided API defined in <xref target="webrtc-api" format="default" sectionFormat="of" derivedContent="webrtc-api"/>.
          </li>
          <li pn="section-7.2-7.3" derivedCounter="3.">
                The browser invokes methods on the object registered by the user directly.
                    </t>
                    <t>
                      Selected from some set of IdPs known IdP
                proxy to create or verify identity assertions.
          </li>
        </ol>
        <t indent="0" pn="section-7.2-8">
            This approach allows us to decouple the calling site.
                      E.g., a button that shows "Authenticate via Facebook
                      Connect"
                    </t>
                  </list>
                </t>
              </section>

              <section title="Relying Party">
                <t>
                  Unlike the AP, the RP need not have browser from any particular
                  relationship with
            IdP; the IdP. Rather, it needs to be able browser need only know how to
                  process whatever assertion is provided by the AP.  As the
                  assertion contains load the IdP's identity in
            JavaScript -- the <spanx
                  style="verb">idp</spanx> field location of which is determined based on the JSON-encoded object (see
                  <xref target="sec.request-assert"/>), the URI can be
                  constructed directly from IdP's
            identity -- and to call the assertion, generic API for requesting and thus verifying
            identity assertions. The IdP provides whatever logic is necessary to
            bridge the RP can
                  directly verify generic protocol to the technical validity IdP's specific
            requirements. Thus, a single browser can support any number of the assertion
            identity protocols, including being forward compatible 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"/>. IdPs
            which did not exist at the time the browser was written.
        </t>
      </section>
            </section>
      <section title="Requesting Assertions" anchor="sec.request-assert">
              <t> anchor="sec.standardized" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-items-for-standardization">Items for Standardization</name>
        <t indent="0" pn="section-7.3-1">
            There are two parts to this work:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3-2">
          <li pn="section-7.3-2.1">
                The input precise information from the signaling message that must be
                cryptographically bound to the user's identity assertion and a mechanism
                for carrying assertions in JavaScript Session Establishment
                Protocol (JSEP) messages. This is the JSON-encoded object
                described specified in
                <xref target="sec.jsep-binding"/> that contains the
                set of certificate fingerprints the browser intends target="sec.jsep-binding" format="default" sectionFormat="of" derivedContent="Section 7.4"/>.
          </li>
          <li pn="section-7.3-2.2">
                The interface to use.
                This string is treated as opaque from the perspective of IdP, which is defined in the
                IdP.
              </t>
              <t>
                The browser also identifies the origin companion W3C
                WebRTC API specification <xref target="webrtc-api" format="default" sectionFormat="of" derivedContent="webrtc-api"/>.
          </li>
        </ul>
        <t indent="0" pn="section-7.3-3">
            The WebRTC API specification also defines JavaScript interfaces that
            the PeerConnection
                is run in, which allows the IdP to make decisions based on who
                is requesting the assertion.
              </t>
              <t>
                An calling application can optionally provide a user identifier hint
                when specifying an IdP.  This value is a hint that the IdP can use to select amongst multiple identities, or specify which IdP to avoid providing
                assertions for unwanted identities.  The <spanx
                style="verb">username</spanx> is a string that has no meaning use.  That
            API also provides access to
                any entity other than the IdP, it can contain any data assertion-generation capability and
            the IdP
                needs in order to correctly generate an assertion. status of the validation process.
        </t>
              <t>
      </section>
      <section anchor="sec.jsep-binding" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-binding-identity-assertions">Binding Identity Assertions to JSEP Offer/Answer Transactions</name>
        <t indent="0" pn="section-7.4-1">
            An identity assertion that is successfully provided binds the user's identity (as asserted by the IdP
                consists of
            IdP) to the following information:
              </t>
              <t>
                <list style="hanging">
                  <t hangText="idp:">
                    The domain name of an IdP SDP offer/answer exchange and specifically to the protocol string.
            media. In order to achieve this, the PeerConnection must provide the
            DTLS-SRTP fingerprint to be bound to the identity. This MAY
                    identify is provided
            as a different IdP JavaScript object (also known as a dictionary or protocol from the one that
                    generated the assertion. hash) with a
            single "fingerprint" key, as shown below:
        </t>
        <sourcecode name="json-1" type="json" markers="false" pn="section-7.4-2">
{
  "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 hangText="assertion:">
                    An opaque indent="0" pn="section-7.4-3">
            The "fingerprint" value containing the assertion itself. This is
                    only interpretable by an array of
            objects.  Each object in the identified IdP or array contains "algorithm" and "digest" values, which correspond directly to
            the IdP code
                    running algorithm and digest values in the client.
                  </t>
                </list>
              </t>
              <t>
                <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 the IdP can later
                verify it, but this is an implementation detail and out of scope "fingerprint" attribute of this document. the SDP <xref target="RFC8122" format="default" sectionFormat="of" derivedContent="RFC8122"/>.
        </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
        <t indent="0" pn="section-7.4-4">
            This object is encoded in signaling, a <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259">JSON</xref>
            string for passing to the IdP.  The identity assertion is serialized into JSON,
                <xref target="RFC4648">Base64-encoded</xref>, and used as returned by
            the
                value of IdP, which is encoded in the <spanx style="verb">identity</spanx> attribute.
                IdPs SHOULD ensure "identity" attribute, is a JSON object that any assertions they
                generate cannot be interpreted is
            encoded as described 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. <xref target="sec.carry-assertion" format="default" sectionFormat="of" derivedContent="Section 7.4.1"/>.
        </t>
            </section>

            <section title="Managing User Login" anchor="sec.user-login">
              <t>
                In order
        <t indent="0" pn="section-7.4-5">
            This structure does not need to generate an identity assertion, be interpreted by the IdP needs proof of or the user's identity.
            IdP proxy. It is common practice to authenticate users
                (using passwords or multi-factor authentication), then use <xref
                target="RFC6265">Cookies</xref> or <xref target="RFC7617">HTTP
                authentication</xref> for subsequent exchanges.
              </t>
              <t> consumed solely by the RP's browser.  The IdP proxy is able to access cookies, HTTP authentication or
                other persistent session data because
            merely treats it operates in as an opaque value to be attested to.  Thus, new
            parameters can be added to the security
                context of assertion without modifying the
            IdP.
        </t>
        <section anchor="sec.carry-assertion" numbered="true" toc="include" removeInRFC="false" pn="section-7.4.1">
          <name slugifiedName="name-carrying-identity-assertion">Carrying Identity Assertions</name>
          <t indent="0" pn="section-7.4.1-1">
              Once an IdP origin.  Therefore, if a user has generated an assertion (see <xref target="sec.request-assert" format="default" sectionFormat="of" derivedContent="Section 7.6"/>), it is logged in, attached to the
                IdP could have all the information needed to generate an
                assertion.
              </t>
              <t>
                An IdP proxy SDP
              offer/answer message. This is unable done by adding a new "identity"
              attribute to generate an assertion if the user SDP. The sole contents of this value is
                not logged in, or the
              identity assertion.  The identity assertion produced by the IdP wants is
              encoded into a UTF-8 JSON text, then <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648">base64-encoded</xref> to interact with produce this string.
              For example:
          </t>
          <sourcecode name="sdp-1" type="sdp" markers="false" pn="section-7.4.1-2">
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 pn="section-7.4.1-3">
            <t indent="0" pn="section-7.4.1-3.1">Note that long lines in the user example are folded to
                acquire more information before generating meet the assertion.  If column
  width constraints of this document; the IdP wants to interact with backslash ("\") at the user before generating an
                assertion, end of
  a line, the IdP proxy can fail to generate an assertion carriage return that follows, and
                instead indicate a URL where login should proceed.
              </t>
              <t> whitespace shall be ignored.</t>
          </aside>
          <t indent="0" pn="section-7.4.1-4">
              The application can then load the provided URL "identity" attribute attests to enable all "fingerprint" attributes in the
                user session
              description. It is therefore a session-level attribute.
          </t>
          <t indent="0" pn="section-7.4.1-5">
              Multiple "fingerprint" values can be
              used to enter credentials. offer alternative certificates for a peer.  The communication between "identity" attribute <bcp14>MUST</bcp14> include all
              "fingerprint" values that are included in "fingerprint" attributes of the
                application and session
              description.
          </t>
          <t indent="0" pn="section-7.4.1-6">
              The RP browser <bcp14>MUST</bcp14> verify that the IdP in-use certificate for a DTLS
              connection is described in <xref
                target="webrtc-api"/>. the set of fingerprints returned from the IdP
              when verifying an assertion.
          </t>
        </section>
      </section>
      <section title="Verifying Assertions" anchor="sec.verify-assert">
              <t>
                The input anchor="sec.idp-uri" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-determining-the-idp-uri">Determining the IdP URI</name>
        <t indent="0" pn="section-7.5-1">
                In order to identity validation ensure that the IdP is under control of the assertion string taken
                from a decoded 'identity' attribute.
              </t>
              <t>
                The IdP proxy verifies the assertion. Depending domain
                owner rather than someone who merely has an account on the identity
                protocol,
                domain owner's server (e.g., in shared hosting scenarios), the
                IdP JavaScript is hosted at a deterministic location based on
                the IdP's domain name.  Each IdP proxy might contact instance is associated
                with two values:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.5-2">
          <dt pn="section-7.5-2.1">authority:</dt>
          <dd pn="section-7.5-2.2">
                       The <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"> authority</xref> at which the
                       IdP's service is hosted.
          </dd>
          <dt pn="section-7.5-2.3">protocol:</dt>
          <dd pn="section-7.5-2.4">
                    The specific IdP server or other
                servers.  For instance, an OAuth-based protocol will likely
                require using which the IdP as an oracle, whereas with is using. This is a
                signature-based scheme might be able
                    completely opaque IdP-specific string, but allows an IdP to verify the assertion
                without contacting the IdP, provided that it has cached
                    implement two protocols in parallel. This value may be the
                relevant public key.
              </t>
              <t>
                Regardless
                    empty string.  If no value for protocol is provided, a value
                    of "default" is used.
          </dd>
        </dl>
        <t indent="0" pn="section-7.5-3">
                Each IdP <bcp14>MUST</bcp14> serve its initial entry page (i.e., the mechanism, if verification succeeds, a
                successful response from one loaded
                by the IdP proxy) from a <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615">well-known
                URI</xref>.
  The well-known URI for an IdP proxy consists of is formed from
                the following
                information:
                <list style="hanging">
                  <t hangText="identity:"> URI components:
        </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.5-4">
          <li pn="section-7.5-4.1" derivedCounter="1.">
                    The identity of scheme, "https:".  An IdP <bcp14>MUST</bcp14> be loaded using <xref target="RFC2818" format="default" sectionFormat="of" derivedContent="RFC2818">HTTPS</xref>.
          </li>
          <li pn="section-7.5-4.2" derivedCounter="2.">
                    The <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986">authority</xref>.  As noted above,
                    the AP from authority <bcp14>MAY</bcp14> contain a  non-default port number or
                    userinfo sub-component.  Both are removed when determining
                    if an asserted identity matches the IdP's perspective. Details name of this are provided in <xref target="sec.id-format"/>.
                  </t>
                  <t hangText="contents:"> the IdP.
          </li>
          <li pn="section-7.5-4.3" derivedCounter="3.">
                    The original unmodified string provided by path, starting with "/.well-known/idp-proxy/" and
                    appended with the AP as input
                    to IdP protocol.  Note that 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>
                  The identity provided from separator
                    characters '/' (%2F) and '\' (%5C) <bcp14>MUST NOT</bcp14> be permitted in
                    the IdP protocol field, lest an attacker be able to the RP browser MUST
                  consist direct
                    requests outside of a string representing the user's identity.  This
                  string is in controlled "/.well-known/" prefix.
                    Query and fragment values <bcp14>MAY</bcp14> be used by including '?' or
                    '#' characters.
          </li>
        </ol>
        <t indent="0" pn="section-7.5-5">
                For example, for the form "&lt;user>@&lt;domain>", where <spanx
                  style="verb">user</spanx> consists of any character, IdP "identity.example.com" and domain is aninternationalized
                  domain name <xref target="RFC5890"></xref> encoded as a sequence of U-labels. the protocol
                "example", the URL would be:
        </t>
                <t>
        <artwork align="left" pn="section-7.5-6">https://identity.example.com/.well-known/idp-proxy/example</artwork>
        <t indent="0" pn="section-7.5-7">
                The PeerConnection API MUST check IdP <bcp14>MAY</bcp14> redirect requests to this string as follows:
                  <list style="numbers">
                    <t>
                      If URL, but they <bcp14>MUST</bcp14> retain
                the "domain" portion "https:" scheme.  This changes the effective origin of the string is equal to
                IdP, but not the domain
                      name of the IdP proxy, then identities that the assertion IdP is valid, as
                permitted to assert and validate. I.e., the IdP is still
                regarded as authoritative for this the original domain.  Comparison of
        </t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5.1">
          <name slugifiedName="name-authenticating-party">Authenticating Party</name>
          <t indent="0" pn="section-7.5.1-1">
                  How an AP determines the appropriate IdP domain names is done using the label equivalence rule
                      defined in Section 2.3.2.4 out of <xref target="RFC5890"/>.
                    </t>
                    <t>
                      If the "domain" portion
                  scope of this specification. In general, however, the string is not equal to AP has
                  some actual account relationship with the
                      domain name of IdP, as this
                  identity is what the IdP proxy, then the PeerConnection
                      object MUST reject is attesting to. Thus, the assertion unless both:
                      <list style="numbers">
                        <t> AP somehow
                  supplies the IdP domain is trusted as an acceptable third-party
                          IdP; and
                        </t>
                        <t>
                          local policy is configured information to trust this IdP domain
                          for the domain portion of the identity string.
                        </t>
                      </list>
                    </t>
                  </list> browser. Some potential
                  mechanisms include:
          </t>
                <t>
                  Any "@" or "%" characters in
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.5.1-2">
            <li pn="section-7.5.1-2.1">
                      Provided by the "user" portion user directly.
            </li>
            <li pn="section-7.5.1-2.2">
                      Selected from some set of IdPs known to the
                  identity MUST calling site
                      (e.g., a button that shows "Authenticate via Facebook
                      Connect").
            </li>
          </ul>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5.2">
          <name slugifiedName="name-relying-party">Relying Party</name>
          <t indent="0" pn="section-7.5.2-1">
                  Unlike the AP, the RP need not have any particular
                  relationship with the IdP. Rather, it needs to be escaped according able to
                  process whatever assertion is provided by the "Percent-Encoding"
                  rules defined AP.  As the
                  assertion contains the IdP's identity in Section 2.1 the "idp" field of the JSON-encoded object (see
                  <xref
                  target="RFC3986"/>. Characters other than "@" and "%" MUST NOT
                  be percent-encoded. For example, with a "user" of "user@133" and
                  a "domain" of "identity.example.com", target="sec.request-assert" format="default" sectionFormat="of" derivedContent="Section 7.6"/>), the resulting string will URI can be encoded as "user%40133@identity.example.com".
                </t>
                <t>
                  Implementations are cautioned to take care when displaying
                  user identities containing escaped "@" characters. If such
                  characters are unescaped prior to display, implementations
                  MUST distinguish between the domain of
                  constructed directly from the IdP proxy assertion, and any
                  domain that might be implied by thus the portion of RP can
                  directly verify the
                  "&lt;user&gt;" portion that appears after technical validity of the escaped "@"
                  sign. assertion with
                  no user interaction. Authoritative assertions need only be
                  verifiable. Third-party assertions also <bcp14>MUST</bcp14> be verified
                  against local policy, as described in <xref target="sec.id-format" format="default" sectionFormat="of" derivedContent="Section 8.1"/>.
          </t>
        </section>
      </section>
      <section title="Security Considerations" anchor="sec.sec-cons">
        <t>
          Much of anchor="sec.request-assert" numbered="true" toc="include" removeInRFC="false" pn="section-7.6">
        <name slugifiedName="name-requesting-assertions">Requesting Assertions</name>
        <t indent="0" pn="section-7.6-1">
                The input to the security analysis of this problem identity assertion generation process is contained the JSON-encoded object
                described in <xref
          target="I-D.ietf-rtcweb-security"/> or in target="sec.jsep-binding" format="default" sectionFormat="of" derivedContent="Section 7.4"/> that contains the discussion
                set of certificate fingerprints the
          particular issues above. In order browser intends 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 use.
                This string is treated as opaque from the
          components in perspective of the system.
                IdP.
        </t>

        <section title="Communications Security">
          <t>
            IF HTTPS is not used to secure communications to
        <t indent="0" pn="section-7.6-2">
                The browser also identifies the signaling
            server, and origin that the identity mechanism used in
            <xref target="sec.generic.idp"/> PeerConnection
                is not used,
            then any on-path attacker can replace run in, which allows the DTLS-SRTP fingerprints
            in IdP to make decisions based on who
                is requesting the handshake and thus substitute its own identity for that
            of either endpoint. assertion.
        </t>

          <t>
            Even if HTTPS
        <t indent="0" pn="section-7.6-3">
                An application can optionally provide a user identifier hint
                when specifying an IdP.  This value is used, a hint that the signaling server IdP 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
                use to
            provide such a mechanism for motivated/security conscious users, but
            are not suitable select amongst multiple identities, or to avoid providing
                assertions for general use. unwanted identities.  The identity service mechanisms
            in <xref target="sec.generic.idp"/> are more suitable for general
            use. Note, however, that "username" is a malicious signaling service string that has no meaning to
                any entity other than the IdP; it can strip off contain any such data the IdP
                needs in order to correctly generate an assertion.
        </t>
        <t indent="0" pn="section-7.6-4">
                An identity assertions, though it cannot forge new ones.  Note assertion that all of the third-party security mechanisms available (whether
            X.509 certificates or a third-party IdP) rely on is successfully provided by the security IdP
                consists of the
            third party--this is of course also true following information:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.6-5">
          <dt pn="section-7.6-5.1">idp:</dt>
          <dd pn="section-7.6-5.2">
                    The domain name of an IdP and the user's connection to the
            Web site itself. Users who wish to assure themselves of security
            against protocol string.  This <bcp14>MAY</bcp14>
                    identify a malicious identity provider can only do so by verifying
            peer credentials directly, e.g., by checking different IdP or protocol from the peer's fingerprint
            against a value delivered out of band.
          </t>

          <t>
            In order to protect against malicious content JavaScript, one that
            JavaScript MUST NOT be allowed to have direct access to---or perform
            computations with---DTLS keys. For instance, if content JS were able
            to compute digital signatures, then 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 key to authenticate
            a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content
            JS, thus violating assertion.
          </dd>
          <dt pn="section-7.6-5.3">assertion:</dt>
          <dd pn="section-7.6-5.4">
                    An opaque value containing the security guarantees otherwise provided assertion itself. This is
                    only interpretable by the identified IdP mechanism. Note that it is not sufficient merely to deny or the
            content JS direct access to IdP code
                    running in the keys, client.
          </dd>
        </dl>
        <t indent="0" pn="section-7.6-6">
                <xref target="fig.assert-ex" format="default" sectionFormat="of" derivedContent="Figure 5"/> shows an example assertion
                formatted as some have suggested doing
            with JSON.  In this case, the WebCrypto API <xref target="webcrypto"/>.  The JS must
            also not be allowed to perform operations message has presumably
                been digitally signed/MACed in some way that would be valid for a
            DTLS endpoint. By far the safest approach IdP can later
                verify it, but this is simply to deny the
            ability to perform any operations that depend on secret information
            associated with the key. Operations that depend on public
            information, such as exporting the public key are an implementation detail and out of scope
                of course safe.
          </t>
        </section>

        <section title="Privacy">
          <t>
            The requirements in this document are intended to allow:
          </t>
          <t>
            <list style="symbols">
              <t>
                Users to participate in calls without revealing their location.
              </t>
              <t>
                Potential callees to avoid revealing their location and even
                presence status prior to agreeing to answer a call.
              </t>
            </list> document.              </t>
          <t>
            However, these privacy protections come at a performance cost in
            terms of using TURN relays and,
        <figure anchor="fig.assert-ex" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-example-assertion">Example Assertion</name>
          <sourcecode name="json-2" type="json" markers="false" pn="section-7.6-7.1">
{
  "idp":{
    "domain": "example.org",
    "protocol": "bogus"
  },
  "assertion": "{\"identity\":\"bob@example.org\",
                 \"contents\":\"abcdefghijklmnopqrstuvwyz\",
                 \"signature\":\"010203040506\"}"
}</sourcecode>
        </figure>
        <t indent="0" pn="section-7.6-8">
                For use in signaling, the latter case, delaying
            ICE. Sites SHOULD make users aware of these tradeoffs.
          </t>
          <t>
            Note that the protections provided here assume a non-malicious
            calling service. As the calling service always knows the users
            status assertion is serialized into JSON,
                <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648">base64-encoded</xref>, and (absent the use of a technology like Tor) their IP
            address, they can violate the users privacy at will.  Users who wish
            privacy against the calling sites they are using must use separate
            privacy enhancing technologies such used as Tor. Combined WebRTC/Tor
            implementations SHOULD arrange to route the media as well as
                value of the
            signaling through Tor. Currently this will produce very suboptimal
            performance.
          </t>
          <t>
            Additionally, "identity" attribute.
                IdPs <bcp14>SHOULD</bcp14> ensure that any identifier which persists across multiple calls is
            potentially assertions they
                generate cannot be interpreted in a problem for privacy, especially for anonymous calling
            services. Such services SHOULD instruct the browser to different context. E.g.,
                they should use a distinct format or have separate
            DTLS cryptographic
                keys for each call assertion generation and also to use TURN throughout the
            call. Otherwise, the other side will learn linkable information that
            would allow them purposes.
                Line breaks are inserted solely for
                readability.
        </t>
      </section>
      <section anchor="sec.user-login" numbered="true" toc="include" removeInRFC="false" pn="section-7.7">
        <name slugifiedName="name-managing-user-login">Managing User Login</name>
        <t indent="0" pn="section-7.7-1">
                In order to correlate generate an identity assertion, the browser across multiple calls.
            Additionally, browsers SHOULD implement the privacy-preserving CNAME
            generation mode IdP needs proof of
                the user's identity.  It is common practice to authenticate users
                (using passwords or multi-factor authentication), then use <xref target="RFC7022"/>. target="RFC6265" format="default" sectionFormat="of" derivedContent="RFC6265">cookies</xref> or <xref target="RFC7617" format="default" sectionFormat="of" derivedContent="RFC7617">HTTP
                authentication</xref> for subsequent exchanges.
        </t>
        </section>

        <section title="Denial of Service">
          <t>
        <t indent="0" pn="section-7.7-2">
                The consent mechanisms described in this document are intended IdP proxy is able to
            mitigate denial of service attacks access cookies, HTTP authentication data, or
                other persistent session data because it operates in which an attacker uses clients
            to send large amounts the security
                context of traffic to the IdP origin.  Therefore, if a victim without user is logged in, the consent of
                IdP could have all the victim. While these mechanisms are sufficient information needed to protect victims
            who have generate an
                assertion.
        </t>
        <t indent="0" pn="section-7.7-3">
                An IdP proxy is unable to generate an assertion if the user is
                not implemented WebRTC at all, WebRTC implementations need logged in, or the IdP wants to be interact with the user to
                acquire more careful.
          </t>
          <t>
            Consider information before generating the case of a call center which accepts calls via
            WebRTC. An attacker proxies assertion.  If
                the call center's front-end and arranges
            for multiple clients to initiate calls IdP wants to interact with the call center. Note that
            this requires user consent in many cases but because before generating an
                assertion, the data
            channel does not need consent, he IdP proxy can use that directly. Since ICE
            will complete, browsers fail to generate an assertion and
                instead indicate a URL where login should proceed.
        </t>
        <t indent="0" pn="section-7.7-4">
                The application can then be induced to send large amounts of
            data load the provided URL to enable the victim call center if it supports the data channel at
            all. Preventing this attack requires that 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 prepared
                user to remotely
            throttle the data channel in enter credentials.  The communication between the absence of plausible audio
                application and
            video (which the attacker cannot control). IdP is described in <xref target="webrtc-api" format="default" sectionFormat="of" derivedContent="webrtc-api"/>.
        </t>
          <t>
            Another related attack
      </section>
    </section>
    <section anchor="sec.verify-assert" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-verifying-assertions">Verifying Assertions</name>
      <t indent="0" pn="section-8-1">
                The input to identity validation is for the signaling service to swap assertion string taken
                from a decoded "identity" attribute.
      </t>
      <t indent="0" pn="section-8-2">
                The IdP proxy verifies the ICE
            candidates for assertion. Depending on the audio and video streams, thus forcing a browser
            to send video to identity
                protocol, the sink that proxy might contact the IdP server or other victim expects
                servers.  For instance, an OAuth-based protocol will contain
            audio (perhaps it is only expecting audio!)  potentially causing
            overload.  Muxing multiple media flows over likely
                require using the IdP as an oracle, whereas with a single transport makes
                signature-based scheme it harder to individually suppress a single flow by denying ICE
            keepalives. Either media-level (RTCP) mechanisms must might be used or able to verify the
            implementation must deny responses entirely, thus terminating assertion
                without contacting the
            call.
          </t>
          <t>
            Yet another attack, suggested by Magnus Westerlund, is for IdP, provided that it has cached the
            attacker to cross-connect offers and answers as follows. It induces
                relevant public key.
      </t>
      <t indent="0" pn="section-8-3">
                Regardless of the victim to make mechanism, if verification succeeds, a call and then uses its control
                successful response from the IdP proxy consists of other users
            browsers to get them to attempt a call to someone. It then
            translates their offers into apparent answers to the victim, which
            looks like large-scale parallel forking. following
                information:
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-8-4">
        <dt pn="section-8-4.1">identity:</dt>
        <dd pn="section-8-4.2">
                    The victim still responds
            to ICE responses and now the browsers all try to send media to identity of the
            victim.  Implementations can defend themselves AP from the IdP's perspective. Details
                    of this attack are provided in <xref target="sec.id-format" format="default" sectionFormat="of" derivedContent="Section 8.1"/>.
        </dd>
        <dt pn="section-8-4.3">contents:</dt>
        <dd pn="section-8-4.4">
                    The original unmodified string provided by
            only responding the AP as input
                    to ICE Binding Requests for a limited number of
            remote ufrags (this the assertion generation process.
        </dd>
      </dl>
      <t indent="0" pn="section-8-5">
                <xref target="fig.verify-ex" format="default" sectionFormat="of" derivedContent="Figure 6"/> shows an example response,
                which is JSON-formatted.
      </t>
      <figure anchor="fig.verify-ex" align="left" suppress-title="false" pn="figure-6">
        <name slugifiedName="name-example-verification-result">Example Verification Result</name>
        <sourcecode name="json-3" type="json" markers="false" pn="section-8-6.1">
{
  "identity": "bob@example.org",
  "contents": "{\"fingerprint\":[ ... ]}"
}</sourcecode>
      </figure>
      <section anchor="sec.id-format" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-identity-formats">Identity Formats</name>
        <t indent="0" pn="section-8.1-1">
                  The identity provided from the reason for IdP to the requirement that RP browser <bcp14>MUST</bcp14>
                  consist of a string representing the JS
            not be able to control user's identity.  This
                  string is in the ufrag form "&lt;user&gt;@&lt;domain&gt;", where "user" consists of any character,
                  and password).
          </t>
          <t> domain is an internationalized
                  domain name <xref target="I-D.ietf-rtcweb-rtp-usage"/> Section 13 documents target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/> encoded as a number sequence of potential RTCP-based DoS attacks and countermeasures. U-labels.
        </t>
          <t>
            Note that attacks based on confusing one end or the other about
            consent are possible even in
        <t indent="0" pn="section-8.1-2">
                  The PeerConnection API <bcp14>MUST</bcp14> check this string as follows:
        </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-8.1-3">
          <li pn="section-8.1-3.1" derivedCounter="1.">
                      If the face "domain" portion of the third-party identity
            mechanism as long as major parts string is equal to the domain
                      name of the signaling messages are not
            signed. On IdP proxy, then the other hand, signing assertion is valid, as the entire message severely
            restricts
                      IdP is authoritative for this domain.  Comparison of
                      domain names is done using the capabilities label equivalence rule
                      defined in <xref target="RFC5890" sectionFormat="of" section="2.3.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5890#section-2.3.2.4" derivedContent="RFC5890"/>.
          </li>
          <li pn="section-8.1-3.2" derivedCounter="2.">
            <t indent="0" pn="section-8.1-3.2.1">
                      If the "domain" portion of the calling application, so there are
            difficult tradeoffs here.
          </t>
        </section>

        <section title="IdP Authentication Mechanism">
          <t>
            This mechanism relies for its security on string is not equal to the
                      domain name of the IdP and on proxy, then the PeerConnection correctly enforcing
                      object <bcp14>MUST</bcp14> reject the security invariants described
            above. At a high level, assertion unless both:
            </t>
            <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-8.1-3.2.2">
              <li pn="section-8.1-3.2.2.1" derivedCounter="1.">
                          the IdP domain is attesting that trusted as an acceptable third-party
                          IdP; and
              </li>
              <li pn="section-8.1-3.2.2.2" derivedCounter="2.">
                          local policy is configured to trust this IdP domain
                          for the user
            identified domain portion of the identity string.
              </li>
            </ol>
          </li>
        </ol>
        <t indent="0" pn="section-8.1-4">
                  Any '@' or '%' characters in the assertion wishes "user" portion of the
                  identity <bcp14>MUST</bcp14> be escaped according to the "percent-encoding"
                  rules defined in <xref target="RFC3986" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-2.1" derivedContent="RFC3986"/>. Characters other than '@' and '%' <bcp14>MUST NOT</bcp14>
                  be associated percent-encoded. For example, with a "user" of "user@133" and
                  a "domain" of "identity.example.com", the
            assertion. Thus, it must not resulting string will
                  be possible for arbitrary third parties
            to get assertions tied encoded as "user%40133@identity.example.com".
        </t>
        <t indent="0" pn="section-8.1-5">
                  Implementations are cautioned to a take care when displaying
                  user or identities containing escaped '@' characters. If such
                  characters are unescaped prior to produce assertions that RPs
            will accept.
          </t>

          <section title="PeerConnection Origin Check" anchor="sec.pc-origin">
            <t>
              Fundamentally, display, implementations
                  <bcp14>MUST</bcp14> distinguish between the IdP proxy is just a piece domain of HTML and JS loaded
              by the 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 generated in
              the browser. However, any
                  domain that proxy would might be in the
              attacker's origin, not implied by the IdP's origin. Only portion of the
              browser itself can instantiate a context
                  "&lt;user&gt;" portion that (a) appears after the escaped "@"
                  sign.
        </t>
      </section>
    </section>
    <section anchor="sec.sec-cons" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">
          Much of the security analysis of RTCWEB is contained in <xref target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/> or in the IdP's origin and
              (b) exposes the correct API surface. Thus, discussion of the IdP proxy
          particular issues above. In order to avoid repetition, this section
          focuses on
              the sender's side MUST ensure (a) residual threats that it is running are not addressed by this
          document and (b) threats produced by failure/misbehavior of one of the
          components in the IdP's origin
              prior to issuing assertions. system.
      </t>
            <t>
              Note that this check only asserts that the browser (or some other
              entity with access
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-communications-security-2">Communications Security</name>
        <t indent="0" pn="section-9.1-1">
            If HTTPS is not used to the user's authentication data) attests secure communications to the request signaling
            server, and hence to the fingerprint.  It does identity mechanism used in
            <xref target="sec.generic.idp" format="default" sectionFormat="of" derivedContent="Section 7"/> is not demonstrate
              that used,
            then any on-path attacker can replace the browser has access to DTLS-SRTP fingerprints
            in the associated private
              key, handshake and therefore an attacker can attach their thus substitute its own identity
              to another party's keying material, thus making a call which
              comes from Alice appear to come from the attacker.
              See <xref target="I-D.ietf-mmusic-sdp-uks"/> for defenses against this
              form that
            of attack. either endpoint.
        </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
        <t indent="0" pn="section-9.1-2">
            Even if HTTPS is located at a well-known URI based on used, the IdP's
              domain name. This requirement prevents an attacker who signaling server can write
            potentially mount a man-in-the-middle attack unless implementations
            have some resources at the IdP (e.g., on one's Facebook wall) from
              being able mechanism for independently verifying keys. The UI
            requirements in <xref target="sec.proposal.comsec" format="default" sectionFormat="of" derivedContent="Section 6.5"/> are designed to impersonate the IdP.
            </t>
          </section>

          <section title="Privacy of IdP-generated identities and the hosting site">
            <t>
              Depending on the structure of the IdP's assertions, the calling
              site may learn the user's identity from the perspective of the
              IdP.  In many cases this is
            provide such a mechanism for motivated/security conscious users, but
            are not an issue because the user is
              authenticating to the site via the IdP in any case, suitable for instance
              when the user has logged general use.  The identity service mechanisms
            in with Facebook Connect and is then
              authenticating their call with <xref target="sec.generic.idp" format="default" sectionFormat="of" derivedContent="Section 7"/> are more suitable for general
            use. Note, however, that a Facebook identity.  However, in
              other case, the user may not have already revealed their malicious signaling service can strip off
            any such identity
              to the site.  In general, IdPs SHOULD either verify assertions, though it cannot forge new ones.  Note
            that all of the user third-party security mechanisms available (whether
            X.509 certificates or a third-party IdP) rely on the security of the
            third party -- this is willing to have their identity revealed of course also true of the user's connection to the
            Web site (e.g.,
              through the usual itself. Users who wish to assure themselves of security
            against a malicious IdP permissions dialog) or arrange that the
              identity information is can only available to known RPs (e.g., social
              graph adjacencies) but not to do so by verifying
            peer credentials directly, e.g., by checking the calling site. The "domain" field peer's fingerprint
            against a value delivered out of the assertion request can be used band.
        </t>
        <t indent="0" pn="section-9.1-3">
            In order to check protect against malicious content JavaScript, that the user has
              agreed
            JavaScript <bcp14>MUST NOT</bcp14> be allowed to disclose their identity have direct
            access to the calling site; because -- or perform
            computations with -- DTLS keys. For instance, if content JS were able
            to compute digital signatures, then it
              is supplied by the PeerConnection it can would be trusted possible for content
            JS to be correct.
            </t>
          </section>

          <section title="Security of Third-Party IdPs" anchor="sec.sec-third-party">
            <t>
              As discussed above, each third-party IdP represents get an identity assertion for a new
              universal trust point browser's generated key and therefore
            then use that assertion plus a signature by the number of these IdPs needs key to be quite limited. Most IdPs, even those which issue unqualified
              identities such as Facebook, can be recast authenticate
            a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content
            JS, thus violating the security guarantees otherwise provided by the
            IdP mechanism. Note that it is not sufficient merely to deny the
            content JS direct access to the keys, as authoritative IdPs
              (e.g., 123456@facebook.com). However, in such cases, some have suggested doing
            with the user
              interface implications are WebCrypto API <xref target="webcrypto" format="default" sectionFormat="of" derivedContent="webcrypto"/>.  The JS must
            also not entirely desirable.  One
              intermediate be allowed to perform operations that would be valid for a
            DTLS endpoint. By far the safest approach is simply to have special (potentially user
              configurable) UI for large authoritative IdPs, thus allowing deny the
              user
            ability to instantly grasp perform any operations that depend on secret information
            associated with the call is being authenticated by
              Facebook, Google, etc. key. Operations that depend on public
            information, such as exporting the public key, are of course safe.
        </t>
      </section>
      <section title="Confusable Characters">
              <t>
                Because a broad range of characters numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-privacy">Privacy</name>
        <t indent="0" pn="section-9.2-1">
            The requirements in this document are permitted intended to allow:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.2-2">
          <li pn="section-9.2-2.1">
                Users to participate in identity
                strings, it may be possible for attackers calls without revealing their location.
          </li>
          <li pn="section-9.2-2.2">
                Potential callees to craft identities
                which are confusable with other identities (see
                <xref target="RFC6943"/> for more on this topic). This is
                a problem with any identifier space of this type
                (e.g., e-mail addresses).
                Those minting identifers should avoid mixed scripts revealing their location and similar
                confusable characters. Those presenting these identifiers even
                presence status prior to agreeing to answer a
                user should consider highlighting cases of mixed script usage
                (see <xref target="RFC5890"/>, section 4.4). Other best practices are still call.
          </li>
        </ul>
        <t indent="0" pn="section-9.2-3">
            However, these privacy protections come at a performance cost in development.
              </t>
            </section>
          </section>

          <section title="Web Security Feature Interactions">
            <t>
              A number
            terms 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">
              <t>
                When popup blocking is using TURN relays and, in use, the IdP proxy is unable to generate popup windows, dialogs or
                any other form latter case, delaying
            ICE. Sites <bcp14>SHOULD</bcp14> make users aware of user interactions.  This prevents the IdP
                proxy from being used to circumvent user interaction.  The
                "LOGINNEEDED" message allows these tradeoffs.
        </t>
        <t indent="0" pn="section-9.2-4">
            Note that the IdP proxy to inform protections provided here assume a non-malicious
            calling service. As the calling
                site service always knows the user's
            status and (absent the use of a need for user login, providing technology like Tor) their IP
            address, they can violate the information
                necessary to satisfy this requirement without resorting to
                direct user interaction from user's privacy at will.  Users who wish
            privacy against the IdP proxy itself.
              </t>
            </section>

            <section title="Third Party Cookies" anchor="sec.3rd-party-cookies">
              <t>
                Some browsers allow users calling sites they are using must use separate
            privacy-enhancing technologies such as Tor. Combined WebRTC/Tor
            implementations <bcp14>SHOULD</bcp14> arrange to block third party cookies (cookies
                associated with origins other than route the top level page) for
                privacy reasons.  Any IdP which uses cookies to persist logins media as well as the
            signaling through Tor. Currently this will be broken by third-party cookie blocking. One option produce very suboptimal
            performance.
        </t>
        <t indent="0" pn="section-9.2-5">
            Additionally, any identifier which persists across multiple calls is to
                accept this as
            potentially a limitation; another is to have problem for privacy, especially for anonymous calling
            services. Such services <bcp14>SHOULD</bcp14> instruct the
                PeerConnection object disable third-party cookie blocking browser to use separate
            DTLS keys for each call and also to use TURN throughout the IdP proxy.
            call. Otherwise, the other side will learn linkable information that
            would allow them to correlate the browser across multiple calls.
            Additionally, browsers <bcp14>SHOULD</bcp14> implement the privacy-preserving CNAME
            generation mode of <xref target="RFC7022" format="default" sectionFormat="of" derivedContent="RFC7022"/>.
        </t>
      </section>

          </section>
        </section>
      </section>
      <section title="IANA Considerations" anchor="sec.iana-cons">
        <t>
          This specification defines numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-denial-of-service">Denial of Service</name>
        <t indent="0" pn="section-9.3-1">
            The consent mechanisms described in this document are intended to
            mitigate denial-of-service (DoS) attacks in which an attacker uses clients
            to send large amounts of traffic to a victim without the <spanx style="verb">identity</spanx>
          SDP attribute per consent of
            the procedures victim. While these mechanisms are sufficient to protect victims
            who have not implemented WebRTC at all, WebRTC implementations need
            to be more careful.
        </t>
        <t indent="0" pn="section-9.3-2">
            Consider the case of Section 8.2.4 a call center which accepts calls via
            WebRTC. An attacker proxies the call center's front-end and 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, they can use that directly. Since ICE
            will complete, browsers can then be induced to send large amounts of <xref
          target="RFC4566"/>.  The required information
            data to the victim call center if it supports the data channel at
            all. Preventing this attack requires that 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 prepared to remotely
            throttle the data channel in the absence of plausible audio and
            video (which the attacker cannot control).
        </t>
        <t indent="0" pn="section-9.3-3">
            Another related attack is for the signaling service to swap the ICE
            candidates for the audio and video streams, thus forcing a browser
            to send video to the sink 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
            it harder to 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 indent="0" pn="section-9.3-4">
            Yet another attack, suggested by Magnus Westerlund, is for the
            attacker to cross-connect offers and answers as follows. It induces
            the victim to make a call and then uses its control of other users'
            browsers to get them to attempt a call to someone. It then
            translates their offers into apparent answers to the victim, which
            looks like large-scale parallel forking.  The victim still responds
            to ICE responses, and now the browsers all try to send media to the
            victim.  Implementations can defend themselves from this attack by
            only responding to ICE Binding Requests for a limited number of
            remote ufrags (this is the reason for the requirement that the JS
            not be able to control the ufrag and password).
            <xref target="RFC8834" sectionFormat="comma" section="13" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8834#section-13" derivedContent="RFC8834"/> documents a number
            of potential RTCP-based DoS attacks and countermeasures.
        </t>
        <t indent="0" pn="section-9.3-5">
            Note that attacks based on confusing one end or the other about
            consent are possible even in the face of the third-party identity
            mechanism as long as major parts of the signaling messages are not
            signed. On the other hand, signing the entire message severely
            restricts the capabilities of the calling application, so there are
            difficult tradeoffs here.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-idp-authentication-mechanis">IdP Authentication Mechanism</name>
        <t indent="0" pn="section-9.4-1">
            This mechanism relies for its security on the IdP and on the
            PeerConnection correctly enforcing the security invariants described
            above. At a high level, the IdP is attesting that the user
            identified in the assertion wishes to be associated with the
            assertion. Thus, it must not be possible for arbitrary third parties
            to get assertions tied to a user or to produce assertions that RPs
            will accept.
        </t>
        <section anchor="sec.pc-origin" numbered="true" toc="include" removeInRFC="false" pn="section-9.4.1">
          <name slugifiedName="name-peerconnection-origin-check">PeerConnection Origin Check</name>
          <t indent="0" pn="section-9.4.1-1">
              Fundamentally, the IdP proxy is just a piece of HTML and JS loaded
              by the browser, so nothing stops a Web attacker from creating
              their own IFRAME, loading the IdP proxy HTML/JS, and requesting a
              signature over their own keys rather than those generated in
              the browser. However, that proxy would be in the
              attacker's origin, not the IdP's origin. Only the
              browser itself can instantiate a context that (a) is in the IdP's origin and
              (b) 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 issuing assertions.
          </t>
          <t indent="0" pn="section-9.4.1-2">
              Note that this check only asserts that the browser (or some other
              entity with access to the user's authentication data) attests to
              the request and hence to the fingerprint.  It does not demonstrate
              that the browser has access to the associated private
              key, and therefore an attacker can attach their own identity
              to another party's keying material, thus making a call which
              comes from Alice appear to come from the attacker.
              See <xref target="RFC8844" format="default" sectionFormat="of" derivedContent="RFC8844"/> for defenses against this
              form of attack.
          </t>
        </section>
        <section anchor="sec.sec-idp-uri" numbered="true" toc="include" removeInRFC="false" pn="section-9.4.2">
          <name slugifiedName="name-idp-well-known-uri">IdP Well-Known URI</name>
          <t indent="0" pn="section-9.4.2-1">
              As described in <xref target="sec.idp-uri" format="default" sectionFormat="of" derivedContent="Section 7.5"/>, the IdP proxy HTML/JS
              landing page is 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 (e.g., on one's Facebook wall) from
              being able to impersonate the IdP.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-9.4.3">
          <name slugifiedName="name-privacy-of-idp-generated-id">Privacy of IdP-Generated Identities and the Hosting Site</name>
          <t indent="0" pn="section-9.4.3-1">
              Depending on the structure of the IdP's assertions, the calling
              site may learn the user's identity from the perspective of the
              IdP.  In many cases, this is not an issue because the user is
              authenticating to the site via the IdP in any case -- for instance,
              when the user has logged in with Facebook Connect and is then
              authenticating their call with a Facebook identity.  However, in
              other cases, the user may not have already revealed their identity
              to the site.  In general, IdPs <bcp14>SHOULD</bcp14> either verify that the user
              is willing to have their identity revealed to the site (e.g.,
              through the usual IdP permissions dialog) or arrange that the
              identity information is only available to known RPs (e.g., social
              graph adjacencies) but not to the 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 calling site; because it
              is supplied by the PeerConnection it can be trusted to be correct.
          </t>
        </section>
        <section anchor="sec.sec-third-party" numbered="true" toc="include" removeInRFC="false" pn="section-9.4.4">
          <name slugifiedName="name-security-of-third-party-idp">Security of Third-Party IdPs</name>
          <t indent="0" pn="section-9.4.4-1">
              As discussed above, each third-party IdP represents a new
              universal trust point and therefore the 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 such cases, the user
              interface implications are not entirely desirable.  One
              intermediate approach is to have special (potentially user
              configurable) UI for large authoritative IdPs, thus allowing the
              user to instantly grasp that the call is being authenticated by
              Facebook, Google, etc.
          </t>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-9.4.4.1">
            <name slugifiedName="name-confusable-characters">Confusable Characters</name>
            <t indent="0" pn="section-9.4.4.1-1">
                Because a broad range of characters are permitted in identity
                strings, it may be possible for attackers to craft identities
                which are confusable with other identities (see
                <xref target="RFC6943" format="default" sectionFormat="of" derivedContent="RFC6943"/> for more on 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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5890#section-4.4" derivedContent="RFC5890"/>). Other best practices are still in development.
            </t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-9.4.5">
          <name slugifiedName="name-web-security-feature-intera">Web Security Feature Interactions</name>
          <t indent="0" pn="section-9.4.5-1">
              A number of optional Web security features have the potential to
              cause issues for this mechanism, as discussed below.
          </t>
          <section anchor="sec.popup-blocking" numbered="true" toc="include" removeInRFC="false" pn="section-9.4.5.1">
            <name slugifiedName="name-popup-blocking">Popup Blocking</name>
            <t indent="0" pn="section-9.4.5.1-1">
                When popup blocking is in use, the IdP proxy is unable to 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 IdP proxy to inform the calling
                site of a need for user login, providing the information
                necessary to satisfy this requirement without resorting to
                direct user interaction from the IdP proxy itself.
            </t>
          </section>
          <section anchor="sec.3rd-party-cookies" numbered="true" toc="include" removeInRFC="false" pn="section-9.4.5.2">
            <name slugifiedName="name-third-party-cookies">Third Party Cookies</name>
            <t indent="0" pn="section-9.4.5.2-1">
                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 limitation; another is to have the
                PeerConnection object disable third-party cookie blocking for
                the IdP proxy.
            </t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sec.iana-cons" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">
          This specification defines the "identity"
          SDP attribute per the procedures of <xref target="RFC4566" sectionFormat="of" section="8.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4566#section-8.2.4" derivedContent="RFC4566"/>.  The required information for the registration is
          included here:
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-10-2">
        <dt pn="section-10-2.1">Contact Name:</dt>
        <dd pn="section-10-2.2">IESG (iesg@ietf.org)</dd>
        <dt pn="section-10-2.3">Attribute Name:</dt>
        <dd pn="section-10-2.4">identity</dd>
        <dt pn="section-10-2.5">Long Form:</dt>
        <dd pn="section-10-2.6">identity</dd>
        <dt pn="section-10-2.7">Type of Attribute:</dt>
        <dd pn="section-10-2.8">session</dd>
        <dt pn="section-10-2.9">Charset Considerations:</dt>
        <dd pn="section-10-2.10">This attribute is not subject
            to the charset attribute.</dd>
        <dt pn="section-10-2.11">Purpose:</dt>
        <dd pn="section-10-2.12">This attribute carries an identity assertion,
            binding an identity to the transport-level security session.</dd>
        <dt pn="section-10-2.13">Appropriate Values:</dt>
        <dd pn="section-10-2.14">See <xref target="sec.sdp-id-attr" format="default" sectionFormat="of" derivedContent="Section 5"/> of RFC 8827.</dd>
        <dt pn="section-10-2.15">Mux Category:</dt>
        <dd pn="section-10-2.16">NORMAL</dd>
      </dl>
      <t indent="0" pn="section-10-3">
          This section registers the "idp-proxy" well-known
          URI from <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615"/>.
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-10-4">
        <dt pn="section-10-4.1">URI suffix:</dt>
        <dd pn="section-10-4.2">idp-proxy</dd>
        <dt pn="section-10-4.3">Change controller:</dt>
        <dd pn="section-10-4.4">IETF</dd>
      </dl>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="FIPS186" quoteTitle="true" target="https://doi.org/10.6028/NIST.FIPS.186-4" derivedAnchor="FIPS186">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2013" month="July"/>
          </front>
          <seriesInfo name="NIST PUB" value="186-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2818" quoteTitle="true" derivedAnchor="RFC2818">
          <front>
            <title>HTTP Over TLS</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="May"/>
            <abstract>
              <t indent="0">This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2818"/>
          <seriesInfo name="DOI" value="10.17487/RFC2818"/>
        </reference>
        <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </reference>
        <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Naslund" fullname="M. Naslund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Norrman" fullname="K. Norrman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Fielding" fullname="R. Fielding">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Masinter" fullname="L. Masinter">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="January"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" quoteTitle="true" derivedAnchor="RFC4566">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4566"/>
          <seriesInfo name="DOI" value="10.17487/RFC4566"/>
        </reference>
        <reference anchor="RFC4568" target="https://www.rfc-editor.org/info/rfc4568" quoteTitle="true" derivedAnchor="RFC4568">
          <front>
            <title>Session Description Protocol (SDP) Security Descriptions for Media Streams</title>
            <author initials="F." surname="Andreasen" fullname="F. Andreasen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams.  The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange.  The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams.  The SDP crypto attribute requires the services of a data security protocol to secure the SDP message.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4568"/>
          <seriesInfo name="DOI" value="10.17487/RFC4568"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author initials="S." surname="Josefsson" fullname="S. Josefsson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5763" quoteTitle="true" derivedAnchor="RFC5763">
          <front>
            <title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
            <author initials="J." surname="Fischl" fullname="J. Fischl">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5763"/>
          <seriesInfo name="DOI" value="10.17487/RFC5763"/>
        </reference>
        <reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5764" quoteTitle="true" derivedAnchor="RFC5764">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5764"/>
          <seriesInfo name="DOI" value="10.17487/RFC5764"/>
        </reference>
        <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890" quoteTitle="true" derivedAnchor="RFC5890">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
            <author initials="J." surname="Klensin" fullname="J. Klensin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t indent="0">This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5890"/>
          <seriesInfo name="DOI" value="10.17487/RFC5890"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC6454" target="https://www.rfc-editor.org/info/rfc6454" quoteTitle="true" derivedAnchor="RFC6454">
          <front>
            <title>The Web Origin Concept</title>
            <author initials="A." surname="Barth" fullname="A. Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6454"/>
          <seriesInfo name="DOI" value="10.17487/RFC6454"/>
        </reference>
        <reference anchor="RFC7022" target="https://www.rfc-editor.org/info/rfc7022" quoteTitle="true" derivedAnchor="RFC7022">
          <front>
            <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
            <author initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="September"/>
            <abstract>
              <t indent="0">The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint.  While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.</t>
              <t indent="0">For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness.  RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs.  Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective.  This document addresses these concerns and replaces RFC 6222.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7022"/>
          <seriesInfo name="DOI" value="10.17487/RFC7022"/>
        </reference>
        <reference anchor="RFC7675" target="https://www.rfc-editor.org/info/rfc7675" quoteTitle="true" derivedAnchor="RFC7675">
          <front>
            <title>Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness</title>
            <author initials="M." surname="Perumal" fullname="M. Perumal">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Ravindranath" fullname="R. Ravindranath">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy" fullname="T. Reddy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Thomson" fullname="M. Thomson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="October"/>
            <abstract>
              <t indent="0">To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.</t>
              <t indent="0">This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7675"/>
          <seriesInfo name="DOI" value="10.17487/RFC7675"/>
        </reference>
        <reference anchor="RFC7918" target="https://www.rfc-editor.org/info/rfc7918" quoteTitle="true" derivedAnchor="RFC7918">
          <front>
            <title>Transport Layer Security (TLS) False Start</title>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Moeller" fullname="B. Moeller">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start".  It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally.  A TLS False Start reduces handshake latency to one round trip.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7918"/>
          <seriesInfo name="DOI" value="10.17487/RFC7918"/>
        </reference>
        <reference anchor="RFC8122" target="https://www.rfc-editor.org/info/rfc8122" quoteTitle="true" derivedAnchor="RFC8122">
          <front>
            <title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t indent="0">This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP).  It defines the SDP protocol identifier, 'TCP/TLS'.  It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session.  This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</t>
              <t indent="0">This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8122"/>
          <seriesInfo name="DOI" value="10.17487/RFC8122"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8261" target="https://www.rfc-editor.org/info/rfc8261" quoteTitle="true" derivedAnchor="RFC8261">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets</title>
            <author initials="M." surname="Tuexen" fullname="M. Tuexen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Stewart" fullname="R. Stewart">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Jesup" fullname="R. Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Loreto" fullname="S. Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="November"/>
            <abstract>
              <t indent="0">The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6.  This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol.  Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks.  As a consequence, the SCTP associations carried over DTLS can only be single-homed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8261"/>
          <seriesInfo name="DOI" value="10.17487/RFC8261"/>
        </reference>
        <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" quoteTitle="true" derivedAnchor="RFC8445">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t indent="0">This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t indent="0">This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8445"/>
          <seriesInfo name="DOI" value="10.17487/RFC8445"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8615" quoteTitle="true" derivedAnchor="RFC8615">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="May"/>
            <abstract>
              <t indent="0">This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space.  It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825">
          <front>
            <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
            <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8825"/>
          <seriesInfo name="DOI" value="10.17487/RFC8825"/>
        </reference>
        <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826" quoteTitle="true" derivedAnchor="RFC8826">
          <front>
            <title>Security Considerations for WebRTC</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8826"/>
          <seriesInfo name="DOI" value="10.17487/RFC8826"/>
        </reference>
        <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829" quoteTitle="true" derivedAnchor="RFC8829">
          <front>
            <title>JavaScript Session Establishment Protocol (JSEP)</title>
            <author initials="J." surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8829"/>
          <seriesInfo name="DOI" value="10.17487/RFC8829"/>
        </reference>
        <reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834" quoteTitle="true" derivedAnchor="RFC8834">
          <front>
            <title>Media Transport and Use of RTP in WebRTC</title>
            <author initials="C." surname="Perkins" fullname="Colin Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ott" fullname="Jörg Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8834"/>
          <seriesInfo name="DOI" value="10.17487/RFC8834"/>
        </reference>
        <reference anchor="RFC8844" target="https://www.rfc-editor.org/info/rfc8844" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8844"/>
          <seriesInfo name="DOI" value="10.17487/RFC8844"/>
        </reference>
        <reference anchor="webcrypto" target="https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/" quoteTitle="true" derivedAnchor="webcrypto">
          <front>
            <title>Web Cryptography API</title>
            <author initials="M" surname="Watson" fullname="Mark Watson">
            </author>
            <date month="January" year="2017" day="26"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>
        <reference anchor="webrtc-api" target="https://www.w3.org/TR/webrtc/" quoteTitle="true" derivedAnchor="webrtc-api">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
          <refcontent>W3C Proposed Recommendation</refcontent>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="fetch" target="https://fetch.spec.whatwg.org/" quoteTitle="true" derivedAnchor="fetch">
          <front>
            <title>Fetch</title>
            <author initials="A." surname="van Kesteren">
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" quoteTitle="true" derivedAnchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Sparks" fullname="R. Sparks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Schooler" fullname="E. Schooler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3261"/>
          <seriesInfo name="DOI" value="10.17487/RFC3261"/>
        </reference>
        <reference anchor="RFC5705" target="https://www.rfc-editor.org/info/rfc5705" quoteTitle="true" derivedAnchor="RFC5705">
          <front>
            <title>Keying Material Exporters for Transport Layer Security (TLS)</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="March"/>
            <abstract>
              <t indent="0">A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism 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> allowing that.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5705"/>
          <seriesInfo name="DOI" value="10.17487/RFC5705"/>
        </reference>
        <reference anchor="RFC6120" target="https://www.rfc-editor.org/info/rfc6120" quoteTitle="true" derivedAnchor="RFC6120">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t hangText="Charset Considerations:">This attribute indent="0">The Extensible Messaging and Presence Protocol (XMPP) is not subject
            to the charset attribute.</t>
            <t hangText="Purpose:">This attribute carries an identity assertion,
            binding an identity to the transport-level security session.</t>
            <t hangText="Appropriate Values:">See <xref
            target="sec.sdp-id-attr"/> application profile of RFCXXXX [[Editor Note: This
            document.]]</t>
            <t hangText="Mux Category:">NORMAL.</t>
          </list>
        </t>
        <t>
          This section reqisters 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>
        </t>
      </section>

    <section title="Acknowledgements">
      <t>
        Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen
        Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin
        Thomson, Magnus Westerland.  Matthew Kaufman provided the UI material in
        <xref target="sec.proposal.comsec"/>. Christer Holmberg provided Extensible Markup Language (XML) that enables the initial version near-real-time exchange of <xref target="sec.sdp-id-attr-oa"/>.
      </t>
    </section>

    <section title="Changes">
      <t> [RFC Editor: Please remove this section prior to publication.]</t>
      <section title="Changes since -15">
        <t>Rewrite the Identity section in structured yet extensible data between any two or 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
        </t>

        <t>
          Clean up discussion network entities.  This document defines XMPP's core protocol methods: setup and teardown of how 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 XML streams, channel encryption, authentication, error handling, and communication primitives for ECDSA, PFS, messaging, network availability ("presence"), and AEAD
        </t>
      </section>
      <section title="Changes since -10">
        <t>
          Update cipher suite profiles.
        </t>
        <t>
          Rework IdP interaction based on implementation experience in
          Firefox.
        </t>
      </section>

      <section title="Changes since -06">
        <t>
          Replaced RTCWEB request-response interactions.  This document obsoletes RFC 3920.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6120"/>
          <seriesInfo name="DOI" value="10.17487/RFC6120"/>
        </reference>
        <reference anchor="RFC6265" target="https://www.rfc-editor.org/info/rfc6265" quoteTitle="true" derivedAnchor="RFC6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author initials="A." surname="Barth" fullname="A. Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">This document defines the HTTP Cookie and RTC-Web with WebRTC, except when referring Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the
          IETF WG
        </t>
        <t>
          Forbade use in mixed content as discussed servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6455" quoteTitle="true" derivedAnchor="RFC6455">
          <front>
            <title>The WebSocket Protocol</title>
            <author initials="I." surname="Fette" fullname="I. Fette">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Melnikov" fullname="A. Melnikov">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">The WebSocket Protocol enables two-way communication between a client running untrusted code in Orlando.
        </t>
        <t>
          Added a requirement to surface NULL ciphers to the top-level.
        </t>
        <t>
          Tried controlled environment to clarify SRTP versus DTLS-SRTP.
        </t>
        <t>
          Added a section on screen sharing permissions.
        </t>
        <t>
          Assorted editorial work.
        </t>
      </section>

      <section title="Changes since -05">
        <t> remote host that has opted-in to communications from that code.  The following changes have been made since the -05 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Response to comments from Richard Barnes
            </t>
            <t>
              More explanation of the IdP security properties and model used for this is the federation
              use case.
            </t>
            <t>
              Editorial cleanup.
            </t>
          </list>
        </t>
      </section>

      <section title="Changes since -03">
        <t>
          Version -04 was a version control mistake. Please ignore.
        </t>
        <t> origin-based security model commonly used by web browsers.  The following changes have been made since the -04 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Move origin check from IdP to RP per discussion in YVR.
            </t>
            <t>
              Clarified treatment protocol consists of X.509-level identities.
            </t>
            <t>
              Editorial cleanup.
            </t>
          </list>
        </t>
      </section>

      <section title="Changes since -03">
      </section>

      <section title="Changes since -02">
        <t> an opening handshake followed by basic message framing, layered over TCP.  The following changes have been made since the -02 draft.
        </t>
        <t>
          <list style="symbols">
            <t>
              Forbid persistent HTTP permissions.
            </t>
            <t>
              Clarified the text in S 5.4 to clearly refer goal of this technology is to requirements provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on
              the API opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and long polling).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6455"/>
          <seriesInfo name="DOI" value="10.17487/RFC6455"/>
        </reference>
        <reference anchor="RFC6943" target="https://www.rfc-editor.org/info/rfc6943" quoteTitle="true" derivedAnchor="RFC6943">
          <front>
            <title>Issues in Identifier Comparison for Security Purposes</title>
            <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="May"/>
            <abstract>
              <t indent="0">Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to provide functionality identify security principals and resources.  In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the site.
            </t>
            <t>
              Fold in security principal may access the IETF portion resource, what level of draft-rescorla-rtcweb-generic-idp
            </t>
            <t>
              Retarget authentication or encryption is required, etc.  If the continuing consent section parties involved in a security decision use different algorithms to assume Binding Requests
            </t>
            <t>
              Added some more privacy compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result.  This document provides a discussion of these issues that designers should consider when defining identifiers and linkage text in various places.
            </t>
            <t>
              Editorial improvements
            </t>
          </list>
        </t>
      </section>
    </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; protocols, and when constructing architectures that use multiple protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6943"/>
          <seriesInfo name="DOI" value="10.17487/RFC6943"/>
        </reference>
        <reference anchor="webcrypto"> anchor="RFC7617" target="https://www.rfc-editor.org/info/rfc7617" quoteTitle="true" derivedAnchor="RFC7617">
          <front>
          <title>Web Cryptography API</title>
            <title>The 'Basic' HTTP Authentication Scheme</title>
            <author fullname="W3C editors"
                  surname="Dahl, Sleevi">
            <organization>W3C</organization> initials="J." surname="Reschke" fullname="J. Reschke">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="25" month="June" year="2013" /> year="2015" month="September"/>
            <abstract>
              <t indent="0">This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</t>
            </abstract>
          </front>

        <annotation>Available at
        http://www.w3.org/TR/WebCryptoAPI/</annotation>
          <seriesInfo name="RFC" value="7617"/>
          <seriesInfo name="DOI" value="10.17487/RFC7617"/>
        </reference>
        <reference anchor="webrtc-api"> anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" quoteTitle="true" derivedAnchor="RFC8224">
          <front>
          <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
            <author fullname="W3C editors"
                  surname="Bergkvist, Burnett, Jennings, Narayanan">
            <organization>W3C</organization> initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Wendt" fullname="C. Wendt">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="4" month="October" year="2011" /> year="2018" month="February"/>
            <abstract>
              <t indent="0">The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t>
              <t indent="0">This document obsoletes RFC 4474.</t>
            </abstract>
          </front>

        <annotation>Available at
        http://dev.w3.org/2011/webrtc/editor/webrtc.html</annotation>
          <seriesInfo name="RFC" value="8224"/>
          <seriesInfo name="DOI" value="10.17487/RFC8224"/>
        </reference>
        <reference anchor="FIPS186"> anchor="RFC8828" target="https://www.rfc-editor.org/info/rfc8828" quoteTitle="true" derivedAnchor="RFC8828">
          <front>
          <title>Digital Signature Standard (DSS)</title>
            <title>WebRTC IP Address Handling Requirements</title>
            <author >
            <organization>National Institute of Standards and Technology (NIST)</organization> initials="J" surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G" surname="Shieh" fullname="Guo-wei Shieh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/> month="January" year="2021"/>
          </front>
          <seriesInfo name="NIST PUB 186-4" value=""/> name="RFC" value="8828"/>
          <seriesInfo name="DOI" value="10.17487/RFC8828"/>
        </reference>

    </references>

   <references title="Informative References">
      &RFC7617;
      &RFC3261;
      &RFC5705;
      &RFC6455;
      &RFC6265;
      &RFC6943;
      &RFC6120;

      <reference anchor="XmlHttpRequest">
        <front>
          <title>XMLHttpRequest Level 2</title>
        <reference anchor="I-D.ietf-tls-dtls13" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-tls-dtls13-39" derivedAnchor="TLS-DTLS13">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author initials="A." surname="van Kesteren">
            <organization></organization> initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true">RTFM, Inc.</organization>
            </author>
            <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization showOnFrontPage="true">Arm Limited</organization>
            </author>
            <author initials="N." surname="Modadugu" fullname="Nagendra Modadugu">
              <organization showOnFrontPage="true">Google, Inc.</organization>
            </author>
            <date day="17" month="January" year="2012"/> month="November" day="2" year="2020"/>
            <abstract>
              <t indent="0">   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees with the exception of order protection/non-replayability.
   Datagram semantics of the underlying transport are preserved by the
   DTLS protocol.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-39"/>
          <format target="http://www.w3.org/TR/XMLHttpRequest/" type="TXT"/> type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-39.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
        <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" sectionFormat="of" derivedContent="Section 6.5"/>. <contact fullname="Christer Holmberg"/> provided
        the initial version of <xref target="sec.sdp-id-attr-oa" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
        <organization showOnFrontPage="true">Mozilla</organization>
        <address>
          <email>ekr@rtfm.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>