jiebi/CodeConvo huggingface dataset:
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: 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:
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type <del> set as "message/token-response". </del> <ins> set as "application/private-token-response". </ins> 6.3.
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: 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
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: 8.2.2. <del> message </del> <ins> application </ins> <del> access-token-response </del> <ins> private-token-response </ins> N/A
Code change:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Related discussion:
text: its own name as one of the names in the list. When used in an authentication challenge, the "PrivateToken" scheme <del> uses the following attributes: </del> <ins> uses the following parameters: </ins> "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not
Code change:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Related discussion:
text: and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. <del> This attribute is required for all challenges. </del> <ins> This parameter is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge.
Code change:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Related discussion:
text: 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:
Code change:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Related discussion:
text: 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
Code change:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Related discussion:
text: 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.
Code change:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Related discussion:
text: Run by the client when processing the server response in the issuance phase of the protocol.  The output of this function is an array of "RedemptionToken" objects that are unlinkable from the server's <del> computation in "PP_Issue". </del> <ins> computation in "Issue". </ins> Inputs:
Code change:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Related discussion:
text: 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".
Code change:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Related discussion:
text: 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
Code change:
cc NAME NAME for an extra set of eyes to check me here -- ASN.1 is not my forte. I went based on the implementation , which I think matches what Frank did , but I would definitely appreciate confirmation!
Friendly bump NAME and NAME =)
Do you have a test vector / example to make sure it matches what I believe?
NAME yeah, each includes the encoded public key ().
Example, taken from the current test vector:
Looks good to me. But yeah, ASN.1 is not the most concise nor readable format.
ASN1 matches my expectations as well.
... we should make it clear, and provide test vectors to make sure it matches. The test vector could include public keys in PEM format and then print out the expected key ID.

Related discussion:
text: 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
Code change:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Related discussion:
text: 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
Code change:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Related discussion:
text: 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
Code change:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Related discussion:
text: 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
Code change:
LGTM
lgtm
The question has come up about what the default candidate should be set to during trickle ICE but after at least one candidate has been gathered so at least in principle you could set c= to one of those candidates. See also; URL
Want to pick a solution that works even if we we do continous trickle and ice does not finish.
Consensus on today's call is: Before ICE is completed, follow the 5245 guidance and pick the "best" candidate. Once ICE is completed, pick whatever you are actually using.
If we move to a mode where ICE never completes, perhaps use the active pair.
It turns out that this was pretty clear already. I have made it slightly clearer.

Related discussion:
text: 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.
Code change:
and
I tweaked this a bit, nothing major. LGTM.
For CT without AS, probably want to just tell the congestion control to stay below CT. For CT where AS is specified, do the same, but limit any streams with AS to the indicated value (in addition to total limit).
This should go into the handling-a-remote-description section.

Related discussion:
text: 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:
Code change:
and
I tweaked this a bit, nothing major. LGTM.
For CT without AS, probably want to just tell the congestion control to stay below CT. For CT where AS is specified, do the same, but limit any streams with AS to the indicated value (in addition to total limit).
This should go into the handling-a-remote-description section.

Related discussion:
text: 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:
Code change:
From meeting minutes "SDP o= line increment [] While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks."
This algorithm becomes correct once we decide to not allow o= modification. Editorial comments follow.
Discussion in-room: 1) add example to make it clear that there is a separate counter (other than current o=) which is what increments. 2) change text about &lt;session-version&gt; to be more of a "note that" for an edge case, as opposed to normative text about a mainline case.
Updated this branch. PTAL
LGTM
2349: "might differ" is creepy. "differs" perhaps. 2359: "N + 2" -> must be greater than N + 1 This is basically OK modulo the above

Related discussion:
text: 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
Code change:
NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits

Related discussion:
text: 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
Code change:
NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits

Related discussion:
text: 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.