jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-security-arch

Commentary: s5.1 referred to for SDP O / A. Should probably be instead .
Paragraph (version A):
This section defines the SDP Offer/Answer RFC6454 considerations for
the SDP 'identity' attribute.
Paragraph (version B):
This section defines the SDP Offer/Answer RFC3264 considerations for
the SDP 'identity' attribute.
Draft: draft-ietf-rtcweb-security-arch

Commentary: The key point is that this is a self - consumed token , so you need to separate it from other self - consumed tokens with different semantics or externally consumed tokens , either by format or by using a separate ke .  suggests making this point in 7.4 .
Paragraph (version A):
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 of this document.  Line breaks are inserted
solely for readability.
Paragraph (version A):
For use in signaling, the assertion is serialized into JSON, RFC4648,
and used as the value of the "identity" attribute.
Paragraph (version B):
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 of this document.
Paragraph (version B):
For use in signaling, the assertion is serialized into JSON, RFC4648,
and used as the value of the "identity" attribute.  IdPs SHOULD
ensure that any assertions they generate cannot be interpreted 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.
Draft: draft-ietf-rtcweb-security-arch

Commentary: What happens if fingerprints do n't change but identity does , and there 's no new connection , ( e.g. , a codec change ) . This text needs to say you propagate that identity to the existing connections . 
 The webrtc text forbids changing of identity . You might want to note that , even if this new language is correct in a more general sense .
Paragraph (version A):
When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute.  In this
case, the established identity MUST be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires
that each media section use the same set of fingerprints for every
media section.
Paragraph (version B):
When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute.  In this
case, the established identity MUST be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires
that each media section use the same set of fingerprints for every
media section.  If a new identity attribute is received, then the
receiver MUST apply that identity to all existing connections.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Need to address  's points . 
 Working group consensus to remove non - default port capability from the specification . In line with RFC 5785bis 's guidance in Section 3 .
Paragraph (version A):
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.
Paragraph (version B):
The RFC3986 at which the IdP's service is hosted.
Draft: draft-ietf-rtcweb-security-arch

Commentary: In Section 7 I would suggest using  and  ( or some other name ) rather than " I " and " you / your . " is used there so the pronouns are mixed . Same comment for 9.1 -- I would suggest replacing " your " with " the user 's . "
Paragraph (version A):
Recently, a number of Web-based identity technologies (OAuth,
Facebook Connect etc.) have been developed.  While the details vary,
what these technologies share is that they have a Web-based (i.e.,
HTTP/HTTPS) identity provider which attests to your identity.  For
instance, if I have an account at example.org, I could use the
example.org identity provider to prove to others that I was
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version B):
Recently, a number of Web-based identity technologies (OAuth,
Facebook Connect etc.) have been developed.  While the details vary,
what these technologies share is that they have a Web-based (i.e.,
HTTP/HTTPS) identity provider which attests to Alice's identity.  For
instance, if Alice has an account at example.org, Alice could use the
example.org identity provider to prove to others that Alice is
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: Alice could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version A):
the security of the third party--this is of course also true of your
connection to the Web site itself.  Users who wish to assure
themselves of security against a malicious identity provider can only
do so by verifying peer credentials directly, e.g., by checking the
peer's fingerprint against a value delivered out of band.
Paragraph (version B):
the security of the third party--this is of course also true of the
user's connection to the Web site itself.  Users who wish to assure
themselves of security against a malicious identity provider can only
do so by verifying peer credentials directly, e.g., by checking the
peer's fingerprint against a value delivered out of band.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Need to register well - known / idp - proxy . 
 PTAL
Paragraph (version B):
This section reqisters the "idp-proxy" well-known URI from RFC5785.
Draft: draft-ietf-rtcweb-security-arch

Commentary: The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a = identity . You had to read much further down to learn that this was n't right and that it was really the assertion . This just moves some of the critical text up , duplicating it really , so that this confusion is less likely .
Paragraph (version A):
This object is encoded in a RFC8259 string for passing to the IdP.
Paragraph (version B):
This object is encoded in a RFC8259 string for passing to the IdP.
The identity assertion returned by the IdP, which is encoded in the
"identity" attribute, is a JSON object that is encoded as described
in sec.carry-assertion.
Paragraph (version A):
Unlike the AP, the RP need not have any particular relationship with
the IdP.  Rather, it needs to be able to process whatever assertion
is provided by the AP.  As the assertion contains the IdP's identity,
the URI can be constructed directly from the assertion, and thus the
RP can directly verify the technical validity of the assertion with
no user interaction.  Authoritative assertions need only be
verifiable.  Third-party assertions also MUST be verified against
local policy, as described in sec.id-format.
Paragraph (version B):
Unlike the AP, the RP need not have any particular relationship with
the IdP.  Rather, it needs to be able to process whatever assertion
is provided by the AP.  As the assertion contains the IdP's identity
in the "idp" field of the JSON-encoded object (see sec.request-
assert), the URI can be constructed directly from the assertion, and
thus the RP can directly verify the technical validity of the
assertion with no user interaction.  Authoritative assertions need
only be verifiable.  Third-party assertions also MUST be verified
against local policy, as described in sec.id-format.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Address . Was n't sure if we should reject the connection . PTAL 
 This was entirely motivated by ekr 's issue . Just trying to move this one along . 
 We should prohibit false start . 
 Why ? ( Sean in the PT said " because of ekr 's issue " , but I ca n't see what the issue is here ) 
 Because the DTLS - SRTP cipher negotiation is not protected until the Finished . 
 That is covered by the false start RFC adequately in my view . 
 Which section do you believe covers it ? 
 Well , I guess that covers cipher negotiation , but I would concede that it 's probably more mechanical and less about the underlying principles . 
 Yes , and so consider the case where you are negotiating both double and regular SRTP .... 
 Ugh . You have convinced me :) Prohibit it . And we should maybe say why . 
 I tend to agree that we should include a reason in . 
 Why make this prohibition ? The description in RFC 7918 covers most of the reasons you might choose not to false start , is there anything in that set that motivates this ? I mean , clients doing false start only do so if they are n't concerned about the implications of downgrade for the parameters that are ( apparently ) negotiated .
Paragraph (version B):
Endpoints MUST NOT implement TLS False Start RFC7918.
Draft: draft-ietf-rtcweb-security-arch

Commentary: I think this one is good to merge . 
 Raised by   at the interim 
 I think this is now closed by MT 's revision with LOGINNEEDED . 
 Closing .  , please re - open if you believe it is not . 
 LGTM
Paragraph (version A):
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.
Paragraph (version B):
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".
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-security-arch

Commentary: As  suggested .
Paragraph (version A):
The identity provided from the IdP to the RP browser MUST consist of
a string representing the user's identity.  This string is in the
form "<user>@<domain>", where "user" consists of any character except
'@', and domain is an RFC5890.
Paragraph (version B):
The identity provided from the IdP to the RP browser MUST consist of
a string representing the user's identity.  This string is in the
form "<user>@<domain>", where "user" consists of any character except
'@', and domain is an RFC5890 encoded as a sequence of U-labels.
Draft: draft-ietf-rtcweb-security-arch

Commentary: 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 .
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-security-arch

Commentary: This is an ( lame ) attempt to I 'm , not sure the text is in the right place even . PTAL As far as I know this is the last technical security issue . 
 As described in the ( mailing list discussion ) [ ] 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 I d per peerconnection as described in and provide that information to the generate and validate assertion js methods . 
 I think where this conversation ended up , based on  's email : 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 ,  also this PR to the WebRTC spec : Also
Mailing list commentary: To make sure we 're all on the same page : The identity token is a 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 should n'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 does n'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 . )
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-security-arch

Commentary: adds " MUX Category " to the required fields to register an SDP attribute .
Paragraph (version A):
See sec.a-identity of RFCXXXX [[Editor Note: This document.
Paragraph (version B):
NORMAL.
Draft: draft-ietf-rtcweb-security-arch

Commentary: From 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 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] 
 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 
 PTAL
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-security-arch

Commentary: 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 .
Paragraph (version B):
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.
Paragraph (version A):
The authority, which is the IdP domain name.  The authority MAY
contain a non-default port number.  Any port number is removed
when determining if an asserted identity matches the name of the
IdP.  The authority MUST NOT include a userinfo sub-component.
Paragraph (version B):
The RFC3986.  As noted above, the authority MAY contain a non-
default port number or userinfo sub-component.  Both are removed
when determining if an asserted identity matches the name of the
IdP.
Draft: draft-ietf-rtcweb-security-arch

Commentary: 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 : Do n't mux . 
 Given we do n't allow rtcpmux in WEbRTC . This is sort of irrelevant and we can say it never happens just do n't do it . 
 I actually thought this was pretty clear before , but I 've the term component to make it clear . I do n't understand comment . We absolutely allow rtcpmux in WebRTC , but it 's still possible to not have it ( browsers are n't forbidden to support it ) .
Paragraph (version A):
Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel or
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
DTLS handshake on every channel which has been established by ICE.
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
DTLS handshake.  Once the DTLS handshake has completed, the keys are
exported RFC5705 and used to key SRTP for the media channels.
Paragraph (version B):
Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel or
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
DTLS handshake on every component which has been established by ICE.
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
DTLS handshake.  Once the DTLS handshake has completed, the keys are
exported RFC5705 and used to key SRTP for the media channels.
Draft: draft-ietf-rtcweb-security-arch

Commentary: PTAL 
 The current text on user identity covers the domain portion well enough , but does n't really say anything about how the part preceding the ' is handled . There is text regarding the use of a local address book for the purposes of rendering , which might help avoid these issues entirely ... where available . We may need to consider addressing the issue of confusable characters and whether we need to define the use of a particular normalization form . ( See )
Paragraph (version B):
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 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 and similar confusable characters.  Those presenting
these identifiers to a user should consider highlighting cases of
mixed script usage (see RFC5890, section 4.4).  Other best practices
are still in development.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Just saving some typing because this section will eventually need to match what 's in  .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Addressing . 
 From Cullen 's review : At the end of section 5.5 , there is mention of a NULL cipher in an example . I do n'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 . 
 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 .
Paragraph (version A):
The "security characteristics" MUST indicate the cryptographic
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.
Paragraph (version B):
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.