jiebi/CodeConvo huggingface dataset:
The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request <del> is "message/token-request".  An example request is shown below, where Nk = 512. </del> <ins> is "application/private-token-request".  An example request is shown below, where Nk = 512. </ins> Upon receipt of the request, the Issuer validates the following conditions:
This specification defines the following protocol messages, along with their corresponding media types: <del> TokenRequest: "message/token-request" </del> <ins> TokenRequest: "application/private-token-request" </ins> <del> TokenResponse: "message/token-response" </del> <ins> TokenResponse: "application/private-token-response" </ins> The definition for each media type is in the following subsections. 8.2.1. <del> message </del> <ins> application </ins> <del> token-request </del> <ins> private-token-request </ins> N/A
include padding.  As an Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the <del> base64url string includes "=" characters.  This attribute MAY be </del> <ins> base64url string includes "=" characters.  This parameter MAY be </ins> omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. <del> "max-age", an optional attribute that consists of the number of </del> <ins> "max-age", an optional parameter that consists of the number of </ins> seconds for which the challenge will be accepted by the origin. Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header field MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </del> <ins> The header field MAY also include the standard "realm" parameter, if desired.  Issuance protocols MAY require other parameters.  Clients SHOULD ignore unknown parameters in challenges, except if otherwise specified by issuance protocols. </ins> As an example, the WWW-Authenticate header field could look like this:
obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time <del> T2 increases.  Depending on the "max-age" token challenge attribute, </del> <ins> T2 increases.  Depending on the "max-age" token challenge parameter, </ins> clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token
Server functionality: <del> "PP_Server_Setup": Generates server configuration and keys </del> <ins> "ServerSetup": Generates server configuration and keys </ins> <del> "PP_Issue": Run on the contents of the client message in the </del> <ins> "Issue": Run on the contents of the client message in the </ins> issuance phase. <del> "PP_Verify": Run on the contents of the client message in the </del> <ins> "Verify": Run on the contents of the client message in the </ins> redemption phase. Client functionality: <del> "PP_Client_Setup": Generates the client configuration based on the configuration used by a given server. </del> <ins> "ClientSetup": Generates the client configuration based on the configuration used by a given server. </ins> <del> "PP_Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </del> <ins> "Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </ins> <del> "PP_Process": Processes the contents of the server response in the issuance phase. </del> <ins> "Process": Processes the contents of the server response in the issuance phase. </ins> <del> "PP_Redeem": Generates the data that forms the client message in the redemption phase. </del> <ins> "Redeem": Generates the data that forms the client message in the redemption phase. </ins> We will use each of the functions internally in the description of the interfaces that follows.
Formally speaking the security model is the following: <del> The adversary runs "PP_Server_Setup" and generates a key-pair "(key, pub_key)". </del> <ins> The adversary runs "ServerSetup" and generates a key-pair "(key, pub_key)". </ins> The adversary specifies a number "Q" of issuance phases to initiate, where each phase "i in 1..Q" consists of "m_i" server evaluations. <del> The adversary runs "PP_Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </del> <ins> The adversary runs "Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </ins> When the adversary wants, it stops the issuance phase, and a random number "l" is picked from "1..Q".
The security model takes the following form: <del> A server is created that runs "PP_Server_Setup" and broadcasts the </del> <ins> A server is created that runs "ServerSetup" and broadcasts the </ins> "ServerUpdate" message "s_update". <del> The adversary runs "PP_Client_Setup" on "s_update". </del> <ins> The adversary runs "ClientSetup" on "s_update". </ins> The adversary specifies a number "Q" of issuance phases to initiate with the server, where each phase "i in 1..Q" consists of
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of <del> the hash function associated with the public key and token type. </del> <ins> the hash function associated with the public key and token type.  The parameters field for the digest used in the mask generation function and the digest being signed MUST be omitted. An example sequence of the SPKI object (in ASN.1 format) for a 2048-bit key is below: "$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER 0:d=0 hl=4 l= 338 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 17:d=2 hl=2 l= 48 cons: SEQUENCE 19:d=3 hl=2 l= 13 cons: cont [ 0 ] 21:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 34:d=3 hl=2 l= 26 cons: cont [ 1 ] 36:d=4 hl=2 l= 24 cons: SEQUENCE 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 49:d=5 hl=2 l= 11 cons: SEQUENCE 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 62:d=3 hl=2 l= 3 cons: cont [ 2 ] 64:d=4 hl=2 l= 1 prim: INTEGER :30 67:d=1 hl=4 l= 271 prim: BIT STRING " </ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide
sections as one BUNDLE group.  However, whether the m= sections are bundle-only or not depends on the BUNDLE policy. <ins> The next step is to generate session-level lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream. </ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of
session-level attributes.  The process here is identical to that indicated in the Initial Offers section above. <ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the
in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE policy is set to "balanced", and this is not the first m= section
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del> <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line
section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the
Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as <del> described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del> <ins> described in RFC5245, Section 4.3.  If ICE checking has already completed for one or more candidate pairs and a candidate pair is in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.
For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending <del> media as specified in RFC3890.  If a "TIAS" value is not </del> <ins> media, as specified in RFC3890.  If a "TIAS" value is not </ins> present, but an "AS" value is specified, generate a "TIAS" value using this formula:
to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". <ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </ins> Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. <del> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </del> [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio:
following restriction: The fields of the "o=" line MUST stay the same except for the <del> <session-version> field, which MUST increment if the session description changes in any way, including the addition of ICE candidates. </del> <ins> <session-version> field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.  The value of the generated <session-version> is independent of the <session-version> of the current local description; in particular, in the case where the current version is N, an offer is created with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the <session-version> will not have changed.  There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique <session-version>. </ins> If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </del> <ins> endpoints.  When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST
No supported codec is present in the offer. <del> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. </del> <ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. </ins> <del> The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </del> <ins> The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.
The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates.  The size <del> of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero.  [[OPEN ISSUE: this is an inconsistency with the W3C spec https://github.com/rtcweb-wg/jsep/issues/12.]] </del> <ins> of the ICE candidate pool can also be set, if desired.  If the application does not indicate a candidate pool size, the browser may select any default candidate pool size. </ins> In addition, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-
4.2.4. <ins> The direction method returns the last value passed into setDirection. If setDirection has never been called, it returns the direction the transceiver was initialized with. 4.2.5. The currentDirection method returns the last negotiated direction for the transceiver's associated m= section.  More specifically, it returns the RFC3264 directional attribute of the associated m= section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection returns "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection returns null. 4.2.6. </ins> The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and
3.7. <del> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </del> <ins> JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </ins> Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or
RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764, TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration, "UDP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </del> <ins> RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE
To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as <del> specified in I-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </del> <ins> specified in RFC7850 if the default candidate uses TCP transport. </ins> If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and
clearer. Session Information ("i="), URI ("u="), Email Address ("e="), <del> Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </del> <ins> Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </ins> Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The <del> application optionally modifies that offer, and then uses it to set up its local config via the setLocalDescription() API.  The offer is then sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del> <ins> application then uses that offer to set up its local config via the setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it
the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the <del> remaining candidates are gathered as usual. </del> <ins> remaining candidates are gathered as usual.  This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. </ins> One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to
createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has <del> a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del> <ins> a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or
until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. <del> Any changes to the ICE candidate pool size take effect </del> <ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been applied, any changes to the ICE candidate pool size take effect </ins> immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.
but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The JSEP implementation will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </del> <ins> The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any offers it generates.  This halves the number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3. <ins> If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4. </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be
attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute. </del> <ins> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:
TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or