jiebi/CodeConvo huggingface dataset:
Code change:
This document creates two registrations for the identification of HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol <del> IDs" registry established in TLSALPN. </del> <ins> IDs" registry established in TLS-ALPN. </ins> The "h2" string identifies HTTP/2 when used over TLS:

Related discussion:
text: Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.
Code change:
same-origin resource requests initiated by the page constructed from the response. <del> 2.2.2. </del> <ins> 3.2. </ins> Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable

Related discussion:
text: NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!
Code change:
belonging to the same brand as the authorization server.  For example, a bank publishing their own mobile application. <del> 8.2. </del> <ins> 9.2. </ins> There are two ways using this specification increases the risk of phishing.

Related discussion:
text: I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Code change:
parameter can also be used to identify keys in an application- specific fashion. <del> The "salt" parameter contains a base64url-encoded octets RFC7515 that is used as salt in deriving a unique content encryption key (see derivation).  The "salt" parameter MUST be present, and MUST be exactly 16 octets long when decoded.  The "salt" parameter MUST </del> <ins> The "salt" parameter contains a base64url-encoded octets that is used as salt in deriving a unique content encryption key (see derivation).  The "salt" parameter MUST be present, and MUST be exactly 16 octets long when decoded.  The "salt" parameter MUST </ins> NOT be reused for two different payload bodies that have the same input keying material; generating a random salt for every application of the content coding ensures that content encryption

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
Code change:
5.2.2.3. There is no requirement on the Initiating Device to support specific <del> hardware.  The authorizing device must be registered/associated with the user and it must be possible for the Authorization Server to </del> <ins> hardware.  The Authorization Device must be registered/associated with the user and it must be possible for the Authorization Server to </ins> trigger an authorization on this device. 5.2.2.4.

Related discussion:
text: The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.
Code change:
the covered components.  Single named parameters MAY occur in any order in the covered components. <del> The component value of a single named parameter is the "valueString" of the named query parameter defined by "application/x-www-form- urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded.  Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" are included with an empty string as the component value. </del> <ins> The component value of a single named parameter is calculated by the following process: Parse the "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded Encode the "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section of HTMLURL, which results in an ASCII string This ASCII string is the component value Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value. </ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the

Related discussion:
text: So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
Code change:
11.1.4. The "Vary" header field in a response describes what parts of a <del> request message, aside from the method, Host header field, and target URI, might influence the origin server's process for selecting and representing this response. </del> <ins> request message, aside from the method and target URI, might influence the origin server's process for selecting and representing this response. </ins> A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the

Related discussion:
text: Vary is described as: 'Host header field' is redundant; the target URI has that information already (and correctly) included.
Code change:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 16. </del> <ins> 17. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may

Related discussion:
text: splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!
Code change:
10.3. <del> The HTTP/2 field block encoding allows the expression of names that are not valid field names in HTTP.  Requests or responses containing invalid field names MUST be treated as malformed.  An intermediary therefore cannot translate an HTTP/2 request or response containing an invalid field name into an HTTP/1.1 message. Similarly, HTTP/2 allows field values that are not valid.  While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed.  Valid characters are defined by the ABNF rule in HTTP. </del> <ins> HPACK permits encoding of field names and values that might be treated as delimiters in other HTTP versions.  An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in HttpHeaders roles before translating a message to another HTTP version.  Translating a field that includes invalid delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform any validation of fields other than the minimum required by HttpHeaders could forward messages that contain invalid field names or values. </ins> 10.4.

Related discussion:
text: Well, that's consistent with HTTP/1.1 :-)
I hate having to do this, but what is possible and what is permissible need to be more clearly separated.
I'm going to tag this as editorial: the possible/permissible split is clearly editorial. And we've decided to depend on the core docs, and whether or not it was clear before what was allowed or not, this is now very crisp in the core semantics. I want to wait until we get in before doing this though.
Discussed in the context of leading and trailing whitespace in -semantics. I think that we should be clearer here about a few things: CRLF and NUL are strictly prohibited leading and trailing WS are strictly prohibited Maybe loosen the requirement a little so that it is less strict about adherence to the ABNF That makes this non-editorial, I think.
Code change:
Append ";" to output. <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to parameter's param-name. </del> <ins> Let name be the result of applying Serialising a Key (ser- key) to parameter's param-name. </ins> Append name to output. If parameter has a param-value: <del> Let value be the result of applying Serialising a Key (ser-key) to parameter's param-value. </del> <ins> Let value be the result of applying Serialising an Item (ser-item) to parameter's param-value. </ins> Append "=" to output.

Related discussion:
text: Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.
Code change:
HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- <del> handshake authentication as a connection error (see section 5.4.1 of </del> <ins> handshake authentication as a connection error (see Section 5.4.1 of </ins> RFC7540) of type PROTOCOL_ERROR. RFC7540 permitted renegotiation before the HTTP/2 connection preface

Related discussion:
text: (Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL
Code change:
HTTP/2 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. <del> 8.1.2.2. </del> <ins> 8.1.2.4. </ins> A single ":status" header field is defined that carries the HTTP status code field (see RFC7231).  This header field MUST be included

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
Code change:
7.2.1. IANA will be asked to establish a registry of tree algorithm <del> identifiers, named "Tree Algorithms", with the following registration procedures: TBD </del> <ins> identifiers, named "Tree Algorithms" to be administered under a Specification Required policy RFC8126. Template: Identifier: The two-byte identifier for the algorithm Tree Algorithm: The name of the algorithm </ins> <del> The "Tree Algorithms" registry initially consists of: </del> <ins> Reference: Where this algorithm is defined </ins> <del> The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD]. </del> <ins> Initial contents: Provided in </ins> 8.  References 8.1.  URIs <del> [1] https://github.com/ietf-scitt/cose-merkle-tree-proofs/issues/6 </del> <ins> [1] https://www.iana.org/assignments/ </ins>

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
gateways) need to agree and either reject the request or delay processing. <ins> Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay.  Server instances can implement any of these measures and be considered to be consistent, even if different instances use different methods.  Critically, this means that it is possible to employ different mitigations in reaction to other conditions, such as server load. </ins> A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data.

Related discussion:
text: Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.
Code change:
otherwise, REQUIRED.  The scope of the access token as described by access-token-scope. <del> The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by RFC7159.  The </del> <ins> The parameters are included in the payload of the HTTP response using the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings.

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
3.2. <del> In IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </del> <ins> In the IT industry it is a common practice that once a software product is released, it is evaluated on various aspects.  For example, an auditing company, a code review company or a government body will examine the software product and issue authoritative reports about the product.  The end users (consumers or distribution entities) use these report to make an accurate assessment as to whether the software product is deemed fit to use. </ins> There are multiple such authoritative bodies that make such assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or <del> identity of the authoritative bodies adds a significant cost to the </del> <ins> identities of the authoritative bodies adds a significant cost to the </ins> end user or consumer of the product. A consumer of released software product wants:

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
1. <del> The JSON-based content of signed JSON Web Token documents as defined in RFC7515 is secured against modification using digital signatures. A consumer of a JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving a JWT can read all contents of the document. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> A common use case is that the signed document represents a user's identity credential, created by an issuer.  The issuer includes the

Related discussion:
text: In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.