jiebi/CodeConvo huggingface dataset:
Code change:
The list of prohibited cipher suites includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites.  To avoid this <del> problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS- ECDHE with the P-256 elliptic curve RFC8422. </del> <ins> problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P-256 elliptic curve RFC8422. </ins> Note that clients might advertise support of cipher suites that are prohibited in order to allow for connection to servers that do not

Related discussion:
text: : This sentence reads oddly. As it appears that the problem in question causes TLS handshake failures, we updated accordingly. Please let us know if this is incorrect. Original: To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422]. Currently: To avoid this problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422].
Code change:
room for future extensions.  Each key-value pair represents a priority parameter. <del> The Priority HTTP header field is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del> <ins> The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Headers Dictionary (STRUCTURED-HEADERS).

Related discussion:
text: A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.
Code change:
instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifier is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> updated identifier is reflected in returned JWT authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
SETTINGS frame.  Explicit SettingsSync is not necessary, since a 101 response serves as implicit acknowledgement.  Providing these values in the upgrade request gives a client an opportunity to provide <del> parameters prior to receiving any frames from the server. </del> <ins> settings prior to receiving any frames from the server. </ins> 3.3.

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
Authenticity checks for off-line systems can occur at time of deployment of released software.  Off-line systems require appropriate configuration and maintenance to be able to conduct <del> useful authenticity checks.  If the off-line systems are operation are part of constrained node environments, they do not possess the </del> <ins> useful authenticity checks.  If the off-line systems in operation are part of constrained node environments, they do not possess the </ins> capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements
Code change:
3.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the initiating device (e.g., Smart TV) which is then scanned or entered on the authorization device (the </del> <ins> QR code or a user code on the Initiating Device (e.g., Smart TV) which is then scanned or entered on the Authorization Device (the </ins> mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider. <del> It is up to the user's judgment to decide on whether they can trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the initiating device (smart TV) and the device on which the authentication/ authorization will take place (the mobile phone). </del> <ins> It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by initiating the authorization flows).  They then use social engineering techniques to change the context in which authorization is requested to trick end-users to scan the QR code or enter it on <del> their mobile devices.  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </del> <ins> their Authorization Device (e.g., mobile phone).  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </ins> 3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.

Related discussion:
text: Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving
Code change:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del> <ins> fig-concept-relationship illustrates entities and processes that comprise a Transparency Service independent of any one use case. </ins> <del> Issuers and Signed Statements </del> <ins> This section describes the three main roles and associated processes in SCITT: </ins> <del> Transparency Service and the registration process </del> <ins> Issuers that use their credentials to create Signed Statements about Artifacts </ins> <del> Relying Parties of the Transparent Statements and the Receipt validation process </del> <ins> Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration.  The returned Receipt may be combined with the Signed Statement to create a Transparent Statement. Relying Parties that: collect Receipts of Signed Statements for subsequent registration of Transparent Statements; retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification); or replay all the Transparent Statements to check for the consistency of the Transparency Service's Append-only Log (e.g. auditing) </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and

Related discussion:
text: Editors call notes: Moving above the diagram is good clarity Changing from defining the roles to the overall diagram caused some confusion. If the PR can maintain the roles, and add diagram clarity, that would be preferred.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained
LGTM
Code change:
FIXME bit vector: 0 right, 1 left, so no bit labels <del> For some tree algorithms, like Quantum Ledger Data Base (QLDB), the direction is derived from the hashes themselves and both the index and direction can be left out in the path: </del> <ins> For some tree algorithms, the direction is derived from the hashes themselves and both the index and direction can be left out in the path: </ins> Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to

Related discussion:
text: and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?
Code change:
by JSON-encoding an ordered array containing the salt and the claim value, e.g.: <del> .  The hash value is then BASE64URL encoded.  Note that the precise </del> <ins> .  The hash value is then BASE64URL-encoded.  Note that the precise </ins> JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below.

Related discussion:
text: reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
Code change:
by JSON-encoding an ordered array containing the salt and the claim value, e.g.: <del> .  The hash value is then BASE64URL encoded.  Note that the precise </del> <ins> .  The hash value is then BASE64URL-encoded.  Note that the precise </ins> JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below.

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
header field that appears in a field block after a regular field line MUST be treated as malformed. <ins> The same pseudo-header field name MUST NOT appear more than once in a field block.  A field block for an HTTP request or response that contains a repeated pseudo-header field name MUST be treated as malformed. </ins> 8.3.1. The following pseudo-header fields are defined for HTTP/2 requests:

Related discussion:
text: This fixes issue .
I agree on 1 that there's no reason to exclude response pseudo-headers from this requirement. (I was worried about contradicting something regarding multiple interim responses, each of which needs a field, but each of those are in a separate field section, so a rule of no duplicates within a field section should work for pseudo-headers, both request and response.) However, I think that a general prohibition is a good thing. If a future (negotiated) extension wants to introduce a new pseudo-header that can be duplicated, it could override an otherwise general prohibition in this draft. If a future extension doesn't do that, it gets the more sane/safe default for free.
Hmm, yeah, I think I can see a justification for that argument. Given that adding new pseudo-headers needs to be negotiated anyway, I don't think that's a big deal. So I'm happy to go ahead with the change for (1) and skip (2).
NAME is "this" the current text, or revised text to address Cory's comment?
This pull request. I think that a blanket "at most once" is fine and what you have is enough. Future extensions can deal with the consequences of that if they want >1.
NAME Do you want the change to cover responses as well?
That would mean moving it up to the "HTTP Control Data" section. That is a good idea. I missed that this was under requests only.
I moved the language up to the HTTP Control Data section and slightly tweaked it.
Code change:
Let member be the tuple (value, parameters). <del> Add name this_key with value member to dictionary. </del> <ins> Add name this_key with value member to dictionary.  If dictionary already contains a name this_key (comparing character-for-character), overwrite its value. </ins> Discard any leading SP characters from input_string.

Related discussion:
text: NAME thanks for the review, see latest commit. is talking about the abstract model for dictionaries, so they are required to be unique. I've removed "required to be" so that people don't misread this.
allows a sender to generate multiple header fields with the same name, if the field is defined as a comma-separated list [i.e., #(values)], and that such duplicates are semantically equivalent to them concatenated into a single header field. I think that this property has been useful for us, when annotating header fields. Can we allow such duplicates for Structured Headers too, when a list or a dictionary is being used? Note that we have merged based on the assumption that it is okay to require the consumer of SH header fields to have the knowledge on what the top type is.
That's always been the intent; are you saying that we should have text specifically enabling this for serialisation of dictionaries and lists?
Good to know that that has been the intent. Yes, I think we should clarify that explicitly for dictionaries and lists, because RFC 7230 can be interpreted to allow duplicates only for those using notation (which we do not use in SH). Also, it might be a good idea to revisit the rule for duplicate dictionary values, as I'd assume that people would try to append a header field without checking the values that already exist. IMO, the rule should be that the dictionary element that appears later overwrites the one that precedes.
PTAL
NAME Thank you! cb76bf1 looks good to me. Is your intention to retain the forbidding of duplicate dictionary values, even when the dictionary members are split into different header fields? For example, in the hypothetical world where cache-control is sent using SH, all the cache-control directives in the following example would be considered invalid and ignored. I am not strongly opposed to that, though my weak preference goes to requiring decoders to use the dictionary member that appears later when there is a collision.
NAME the problem is that ignoring duplicates can cause security issues for some headers (the headers that WebAppSec in the W3C are particularly sensitive about this). The only way to address it would be to add a flag to the API to control what to do with dups -- but that adds complexity (more to specifications than to implementations, but still). I'm not crazy about that; what do others think?
Code change:
Let member be the tuple (value, parameters). <del> Add name this_key with value member to dictionary. </del> <ins> Add name this_key with value member to dictionary.  If dictionary already contains a name this_key (comparing character-for-character), overwrite its value. </ins> Discard any leading SP characters from input_string.

Related discussion:
text: NAME Thank you for the explanation. But I wonder if it is actually the case that what those specifications forbid is having duplicate header fields, rather than forbidding duplicate dictionary members (or maybe both). By quickly searching on URL, I was able to find the prohibition on having duplicate header fields, but could not find a rule that forbids having duplicate policy tokens. Assuming that at least such specifications forbid having duplicate header fields, and based on the fact that SH draft does not forbid that (when a list or dictionary is used), I think there is no reason for the SH draft to forbid having duplicate dictionary members.
NAME NAME any comments re: the above? Specifically, if SH swallowed duplicate dictionary values rather than raising an error, would that be a concern from a security standpoint?
Given a header like , it seems like we have a few options: Fail parsing. Return . Return . Return . I think I can come up with arguments for any of these options, though I'd find 4 a bit surprising as a spec author, insofar as I'd have to deal with unexpected lists for all my dictionary values. of URL skips duplicate CSP directives. That is, it picks 2 out of the list above, choosing to retain only the first value for a given name. I do wonder whether that was the right decision, but it is consistent across browsers and provides developers with predictable behavior. We throw a warning into the console in Chrome for this case, and that's probably Good Enough.
This sounds like a bad API for working with structured header values. I'd hope that eventually we offer better APIs for operating on (what Fetch calls) header lists. I think historically there were some arguments for always using first or last based on likelihood of where header injection would happen. But I'm not sure how sound any of that rationale was. I don't think a client can reasonably protect against it. Therefore, what's most important is that the result is unambiguous and that it doesn't matter how you "spell" multiple values (commas or multiple fields or a combination) in the traditional header syntax.
Anyone have preferences between Mike's options 2 and 3?
NAME I think option 3 is preferable, because that would allow server administrators to override parameters by appending header fields.
Code change:
Let member be the tuple (value, parameters). <del> Add name this_key with value member to dictionary. </del> <ins> Add name this_key with value member to dictionary.  If dictionary already contains a name this_key (comparing character-for-character), overwrite its value. </ins> Discard any leading SP characters from input_string.

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.