jiebi/TextFlow huggingface dataset:
Original text:
STUN - Session Traversal Utilities for NAT, <del> ICE - Interactive Connectivity Establishment, RFC5245 </del>  TLS - Trasnsport Layer Security, media type (audio, video or data) into its own 5-tuple (bundling by media type). <del> Sending data over multiple 5-tuples is not supported. </del>  A receiving implementation MUST be able to receive media and data in all these configurations.

Reviewer comments:
Also do reformatting (xxe equivalent of tidy).
From Ben Campbell's IESG comments:

Revised text:
STUN - Session Traversal Utilities for NAT,  <ins> ICE - Interactive Connectivity Establishment, </ins> TLS - Trasnsport Layer Security, media type (audio, video or data) into its own 5-tuple (bundling by media type).  <ins> Sending data channel data over multiple 5-tuples is not supported. </ins> A receiving implementation MUST be able to receive media and data in all these configurations.
Original text:
can fail to generate an assertion and instead indicate a URL where login should proceed. <del> A calling site is then able to load the provided URL in an IFRAME in order to trigger the required user interactions.  Once any user interactions are complete, the IFRAME MUST send a WebMessaging to the calling site indicating that login has completed.  Any message is sufficient for this purpose, the "source" parameter identifies the originating IFRAME. </del>  5.7.

Reviewer comments:
This is the companion to w3c/webrtc-pc A move to JS realms and so forth removes the need for a "protocol" in this document. Instead, I've tried to focus here on what information needs to pass between the browser and the IdP, rather than be prescriptive. I didn't reindent anything, so it's a mess. I also didn't move Section 5.6 up a level, as I am sorely tempted to do. Hopefully these changes are easy enough to review as they are.

Revised text:
can fail to generate an assertion and instead indicate a URL where login should proceed.  <ins> The application can then load the provided URL to enable the user to enter credentials.  The communication between the application and the IdP is described in webrtc-api. </ins> 5.7.
Original text:
All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite <del> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.  Implementations MUST favor cipher suites which support PFS over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG Consensus.]] The API MUST provide a mechanism to indicate that a fresh DTLS key pair is to be generated for a specific call.  This is intended to allow for unlinkability.  Note that there are also settings where it is attractive to use the same keying material repeatedly, especially those with key continuity-based authentication.  Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </del>  When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material.  This requirement preserves the

Reviewer comments:
I also cleaned up the requirements that follow on from this. I think that those changes are editorial only.
Tickling this issue. Not clear to me if it is resolved or not. Current text (-12): All implementations MUST implement DTLS 1.0, with the cipher suite TLSECDHEECDSAWITHAES128CBCSHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTPAES128CMHMACSHA180 MUST be supported for SRTP. Implementations SHOULD implement DTLS 1.2 with the TLSECDHEECDSAWITHAES128GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. (Original text of this comment turned out to be a misunderstanding. The draft linked as "editor's draft" from the project's master page is older than the published -12 version.)
I think that the actual editors draft is OK, ekr merged a while ago.

Revised text:
All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite  <ins> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the FIPS186.  The DTLS- SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.  Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability. The API MUST provide a means to reuse a key pair for calls.  This can be used to enable key continuity-based authentication, and could be used to amortize key generation costs. Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin.  (This avoids creating a super-cookie.) </ins> When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material.  This requirement preserves the
Original text:
Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness <del> mechanism specified in I-D.muthu-behave-consent-freshness.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </del>  5. Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile <del> the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del>  5.4.

Reviewer comments:
Addresses .
NAME CI fail
Yeah I can’t wait to diagnose what xml problem I introduced - sigh.
From Cullen's 20171106 review: The refs to draft-muthu-behave-consent-freshness should be to RFC7675
Addressed by .

Revised text:
Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness  <ins> mechanism specified in RFC7675.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </ins> 5. Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile  <ins> the ICE timers to be used; see RFC7675. </ins> 5.4.
Original text:
necessary in systems that are non-windows-based but that have good notifications support, such as phones.] <del> Browsers MUST not permit permanent screen or application sharing </del>  permissions to be installed as a response to a JS request for permissions.  Instead, they must require some other user action such as a permissions setting or an application install experience The browser MUST indicate any windows which are currently being shared in some unambiguous way.  Windows which are not visible <del> MUST not be shared even if the application is being shared.  If </del>  the screen is being shared, then that MUST be indicated. Clients MAY permit the formation of data channels without any direct

Reviewer comments:
There were two instances of "MUST not" that need to be "MUST NOT"
Address I-D nits complaints.

Revised text:
necessary in systems that are non-windows-based but that have good notifications support, such as phones.]  <ins> Browsers MUST NOT permit permanent screen or application sharing </ins> permissions to be installed as a response to a JS request for permissions.  Instead, they must require some other user action such as a permissions setting or an application install experience The browser MUST indicate any windows which are currently being shared in some unambiguous way.  Windows which are not visible  <ins> MUST NOT be shared even if the application is being shared.  If </ins> the screen is being shared, then that MUST be indicated. Clients MAY permit the formation of data channels without any direct
Original text:
The "security characteristics" MUST indicate the cryptographic <del> algorithms in use (For example: "AES-CBC" or "Null Cipher".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </del>  The "security characteristics" MUST indicate whether PFS is provided.

Reviewer comments:
Addressing .
From Cullen's 20171106 review: At the end of section 5.5, there is mention of a NULL cipher in an example. I don't think that is allowed and thought is not a problem the way it is mentioned here, perhaps it should be removed from the example.
NAME Version -06, exposed the NULL ciphers at the top level so are you suggested to just delete the part in the parenthetical or the rest of the sentence too: i.e.,: The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI.

Revised text:
The "security characteristics" MUST indicate the cryptographic  <ins> algorithms in use (For example: "AES-CBC".)  However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </ins> The "security characteristics" MUST indicate whether PFS is provided.
Original text:
channels.  This is performed via DTLS RFC6347 and DTLS-SRTP RFC5763 keying for SRTP RFC3711 for the media channel and SCTP over DTLS RFC8261 for data channels.  Specifically, Alice and Bob perform a <del> DTLS handshake on every channel which has been established by ICE. </del>  The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one

Reviewer comments:
RFC 5764 rather optimistically describes how the same DTLS handshake can be used to key SRTP for RTP and RTCP even if these are on different components (i.e., is not negotiated). This is not what anyone does. Mandate precisely one handshake per component.
FROM IETF100: Don't mux.
Given we don't allow rtcpmux in WEbRTC. This is sort of irrelevant and we can say it never happens just don't do it.
I actually thought this was pretty clear before, but I've added the term component to make it clear. I don't understand NAME comment. We absolutely allow rtcpmux in WebRTC, but it's still possible to not have it (browsers aren't forbidden to support it).

Revised text:
channels.  This is performed via DTLS RFC6347 and DTLS-SRTP RFC5763 keying for SRTP RFC3711 for the media channel and SCTP over DTLS RFC8261 for data channels.  Specifically, Alice and Bob perform a  <ins> DTLS handshake on every component which has been established by ICE. </ins> The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one
Original text:
hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: <del> The IdP's domain name </del>  The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to The scheme, "https:".  An IdP MUST be loaded using RFC2818. <del> The authority, which is the IdP domain name.  The authority MAY contain a non-default port number.  Any port number is removed </del>  when determining if an asserted identity matches the name of the <del> IdP.  The authority MUST NOT include a userinfo sub-component. </del>  The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'

Reviewer comments:
This references RFC 3986 authority instead of providing a definition for IdP domain. This change means that userinfo sub-components are permitted, as are non-default ports, but also states that both are removed before matching against the certificate.

Revised text:
hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values:  <ins> The RFC3986 at which the IdP's service is hosted.  Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. </ins> The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to The scheme, "https:".  An IdP MUST be loaded using RFC2818.  <ins> The RFC3986.  As noted above, the authority MAY contain a non- default port number or userinfo sub-component.  Both are removed </ins> when determining if an asserted identity matches the name of the  <ins> IdP. </ins> The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'
Original text:
dictionary with one or two further values that identify the IdP, as described in sec.idp-uri.  5.6.5. In order to ensure that the IdP is under control of the domain owner

Reviewer comments:
From URL repos it seems the conclusion is that how identity is handled carried in the SDP, and how identity in the SDP is parsed, and how multiple identity attributes (if we are to support that) should be describe in draft-ietf-rtcweb-security-arch [5]. draft-ietf-rtcweb-security-arch, but only for a single identity attribute, and parsing is not described, so it needs to be updated. repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating the action happens elsewhere). [2] URL [3] URL [4] URL [5] URL [6] URL
FROM IETF100: EKR just needs to write some crap. Should only have one, semantics are undefined with more than 1, implementations need only process one.
1) only put 1 in 2) semantics undefined if more than one 3) implementations only need to process one
NAME PTAL Hi, after some discussing in in W3C webrtc-pc [1] and JSEP [2][3][4] github repos it seems the conclusion is that how identity is handled carried in the SDP, and how identity in the SDP is parsed, and how multiple identity attributes (if we are to support that) should be describe in draft-ietf-rtcweb-security-arch [5]. Identity in the SDP is currently described in draft-ietf-rtcweb-security-arch, but only for a single identity attribute, and parsing is not described, so it needs to be updated. I decided to send this to the list as the activity level at the github repo [6] for draft-ietf-rtcweb-security-arch seems to be low (indicating the action happens elsewhere). Stefan [1] URL [2] URL [3] URL [4] URL [5] URL [6] URL

Revised text:
dictionary with one or two further values that identify the IdP, as described in sec.idp-uri. <ins> The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first identity attribute. </ins> 5.6.5. In order to ensure that the IdP is under control of the domain owner
Original text:
5.6.4. An identity assertion binds the user's identity (as asserted by the <del> IdP) to the SDP offer/exchange transaction and specifically to the media.  In order to achieve this, the PeerConnection must provide the DTLS-SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </del>  The "fingerprint" value is an array of objects.  Each object in the array contains "algorithm" and "digest" values, which correspond 5.6.4.1. Once an IdP has generated an assertion, it is attached to the SDP <del> message.  This is done by adding a new identity attribute to the SDP. The sole contents of this value are a RFC4648 identity assertion. For example: </del>  The identity attribute attests to all "a=fingerprint" attributes in the session description.  It is therefore a session-level attribute.

Reviewer comments:
Just some tweaks to consistently use offer/answer exchange and to explain that the offer/answer includes the caller's/callee's assertion, respectively.

Revised text:
5.6.4. An identity assertion binds the user's identity (as asserted by the  <ins> IdP) to the SDP offer/answer exchange and specifically to the media. In order to achieve this, the PeerConnection must provide the DTLS- SRTP fingerprint to be bound to the identity.  This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: </ins> The "fingerprint" value is an array of objects.  Each object in the array contains "algorithm" and "digest" values, which correspond 5.6.4.1. Once an IdP has generated an assertion, it is attached to the SDP  <ins> offer/answer message.  This is done by adding a new identity attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </ins> The identity attribute attests to all "a=fingerprint" attributes in the session description.  It is therefore a session-level attribute.
Original text:
location controlled by the attacker.  Implementations MUST either choose to terminate the call or display a warning at that point.  5.2. Implementations MUST obtain explicit user consent prior to providing

Reviewer comments:
This is an (lame) attempt to I'm, not sure the text is in the right place even. NAME NAME NAME NAME PTAL As far as I know this is the last technical security issue.
As described in the (mailing list discussion)[URL] As the RTCCertificates are allowed to be stored or transferred across domains via postMessage it could allow a potential attacker to reuse a past identity assertion when it is no longer valid. A possible solution would to generate an unique dtls external session Id per peerconnection as described in URL and provide that information to the generate and validate assertion js methods.
I think where this conversation ended up, based on Harald's email: URL Means that the security arch draft needs to say that the security architecture depends on the keying material not being available to move between origins, but that we understand and assume that the identity token can be passed to anyone that the page cares to. And, Martin also added this PR to the WebRTC spec: Also URL To make sure we're all on the same page: The identity token is a JSON blob - ie a string. There's absolutely no way to prevent the page from passing it to anyone it wants to pass it to - and there shouldn't be. In contrast, the RTCCertificate is an object with an interface that has a specific guarantee: "No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot." and therefore this further statement can be made to implementors: "In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used." I think it doesn't make sense to move such an object between origins. We might want to state that explictly. (But that's a W3C issue, so ought to be addressed to a different list.)

Revised text:
location controlled by the attacker.  Implementations MUST either choose to terminate the call or display a warning at that point. <ins> Also note that the security architecture depends on the keying material not being available to move between origins.  But, it is assumed that the identity assertion can be passed to anyone that the page cares to. </ins> 5.2. Implementations MUST obtain explicit user consent prior to providing
Original text:
dictionary with one or two further values that identify the IdP, as described in sec.idp-uri.  The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first

Reviewer comments:
This currently uses the fingerprint, but that's just this version.
I am ok with this scope, and to allow other means to be defined in future. However, as the whole document is based on the usage of fingerprints for assertion, I think this scope should be defined in the beginning of the document, e.g., in a separate "Scope" section and/or in the Introduction. Related to that, the document references the W3C API between the user and the IdP. It would be good to say that other APIs can also be used, but is outside the scope of this document.

Revised text:
dictionary with one or two further values that identify the IdP, as described in sec.idp-uri. <ins> An identity assertion as defined in this document relies on the value of "a=fingerprint" attributes, but this does not preclude the definition of alternative means of binding an assertion to the identity of a peer. </ins> The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first
Original text:
local policy is configured to trust this IdP domain for the domain portion of the identity string. <del> Sites that have identities that do not fit into the RFC822 style (for instance, identifiers that are simple numeric values, or values that contain '@' characters) SHOULD convert them to this form by escaping illegal characters and appending their IdP domain (e.g., user%40133@identity.example.com), thus ensuring that they are authoritative for the identity. </del>  9.

Reviewer comments:
NAME I think this one is good to merge.
Raised by Jim Spring at the interim
I think this is now closed by MT's revision with LOGINNEEDED.
Closing. Jim, please re-open if you believe it is not.
LGTM

Revised text:
local policy is configured to trust this IdP domain for the domain portion of the identity string.  <ins> Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in Section 2.1 of 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", the resulting string will be encoded as "user%40133@identity.example.com". 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 the IdP proxy and any domain that might be implied by the portion of the <user> portion that appears after the escaped "@" sign. </ins> 9.