Original text:
security. Interaction between the Key Distributor and the call processing <del> function may be necessary to for proper conference-to-endpoint mappings, which may or may not be satisfied by getting information directly from the endpoints or via some other means.  See dolist for a related item in the To Do list. </del>  The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys.  See dolist for a related item in the To Do list. </del>  4.4. 5.1. <del> WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </del>  Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor. can be conveyed to endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference.  6. This framework, and the individual protocols defined to support it, 7. <del> 8. </del> There are no IANA considerations for this document. <del> 9. [TBD] 10. </del>  The authors would like to thank Mo Zanaty and Christian Oien for invaluable input on this document.  Also, we would like to

Reviewer comments:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG

Revised text:
security. Interaction between the Key Distributor and the call processing  <ins> function is necessary to for proper conference-to-endpoint mappings. This is described in identity. </ins> The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those  <ins> header extensions encrypted with E2E keys. </ins> 4.4. 5.1.  <ins> WebRTC Identity assertion I-D.ietf-rtcweb-security-arch can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </ins> Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor. can be conveyed to endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference. <ins> 5.3. The Key Distributor is responsible for knowing what users are allowed in a given conferences.  When the call setup signalling indicates a session from a particular endpoint and user wishes to join a conferences, the Key Distributor will tell the Media Distributor which conference to place that session in using a globally unique identifier for the conference that is sent, along with the relevant keying information, from the Key Distributor to the Media Distributor. </ins> 6. This framework, and the individual protocols defined to support it, 7.  There are no IANA considerations for this document.  <ins> 8. </ins> The authors would like to thank Mo Zanaty and Christian Oien for invaluable input on this document.  Also, we would like to