jiebi/CodeConvo huggingface dataset:
Code change:
protocol. The cleartext version of HTTP/2 has minimal protection against cross- <del> protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </del> <ins> protocol attacks.  The preface contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </ins> 10.3.

Related discussion:
text: As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.
Code change:
after validating the Digest. If received in trailers, Digest MUST NOT be discarded; instead it MAY <del> be merged in the header section (See Section 7.1.2 of !MESSAGING=I- D.ietf-httpbis -messaging). </del> <ins> be merged in the header section (See Section 5.6.2 of SEMANTICS). </ins> Not every digest-algorithm is suitable for trailers, as they may require to pre-process the whole payload before sending a message

Related discussion:
text: HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)
Code change:
value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. <del> 5. This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 5.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> 6. The Security Considerations in the SD-JWT specification I-D.ietf-

Related discussion:
text: And not to forget, this well-known location also could work well with openid-federation. Moreover, any additional VC issuer metadata we will come across can be added to this endpoint. BTW: I think a dedicated issue would be the better place for this discussion.
I am actually in favor of . This mechanism is meant to be general enough to be used with not just a 'verifiable credential'. and I don't think anyone would think to use with ID Tokens and Access Tokens, UserInfo responses , etc. that are JWTs.
I understand your point NAME below my thoughts Why defining jwt-issuer for general purpose in a spec that's specialized for VC? Requirement: definition of a specs in IETF for general purpose JWT Issuer metadata (enabling client metadata, that today is only available in openid-federation...) I agree that jwt-vc-issuer semantically collides with credential-issuer, and we should not do collisions why we can't use .well-known/openid-federation? Federation entity discovery is required for the entities that builds trust chain according to the federation specs, nothing prevent to publish all the metadata of all thw "JWT-role" in a single metadata, that should not be signed if request (content-type) asks it in plain text I suggest to use to consolidate a unique way to publish all the metadata types and roles of an entity. coming back to the name change proposal. Why we use the term since the metadata contains also general capabilities not related to the issuance? in a more general purpose way, wouldn't it be a ? then the question: if that entity has more functionalities and roles, being at the same time a RP and a AS, how the metadata should be organized? We've resolved this issue in openid-federation, with the below schema, where a RP can be also a OP, AS, Client, credential-issuer and so on: URL
I'm a little embarrassed, but to be honest, I still don't understand the reasoning. "A stable issuer identifier" is represented by the claim, not by the URL of the well-known endpoint, isn't it? A possible reason for necessity of a well-known path I guess is "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path under the domain."
Code change:
value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. <del> 5. This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 5.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> 6. The Security Considerations in the SD-JWT specification I-D.ietf-

Related discussion:
text: If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.
Code change:
code (unless specified otherwise) and includes the following parameters with the response: <ins> This specification requires the authorization server to define new error codes that relate to the actions the client must take in order to properly authenticate the user.  These new error codes are specific to the authorization server's implementation of this specification and are intentionally left out of scope. </ins> The parameters are included in the content of the HTTP response using the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each

Related discussion:
text: Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types
Code change:
Abstract <del> This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). </del> <ins> This specification nominates a selection of existing HTTP fields whose values are compatible with Structured Fields syntax, so that they can be handled as such (subject to certain caveats). </ins> To accommodate some additional fields whose syntax is not compatible, <del> it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. </del> <ins> it also defines mappings of their semantics into Structured Fields. It does not specify how to convey them in HTTP messages. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data model with associated parsing and serialization algorithms for use by new HTTP field values.  Fields that are defined as Structured Fields <del> can realise a number of benefits, including: </del> <ins> can bring advantages that include: </ins> Improved interoperability and security: precisely defined parsing and serialisation algorithms are typically not available for

Related discussion:
text: draft-nottingham-binary-structured-headers already has a flag, so it probably could just use the original names, though pseudoheader names would work too I suppose. The existing names has the minor benefit of being able to reuse the existing HPACK static table. Some sort of SF-based HTTP API like probably (?) doesn't want pseudoheaders in the API and can just use the original names. But I haven't put much thought into that. If one wanted to send them in their textual form in existing frames, we probably need pseudoheaders. Though I don't know if we really get much value out of defining that, over just using the existing syntax. shrug We can also punt this problem to documents that want to use this, if we're not sure yet. :-)
If you want to use an invalid field name, there are a lot more options than putting a ":" in the first byte. You need to negotiate that usage, but then you can do anything at all, including using that to signal lots of stuff. (If you want to avoid the extra byte, you can pack data into the high bit of each byte...)
I feel like punting is the right solution, unless we can come up with a convention that addresses the identified issues in all cases.
Not acting is a decision of a sort. But I'm not sure what that would concretely mean for retrofit? No prefix? Or just that we shouldn't worry yet about the effect this has on smuggling through WAFs and whatnot?
I think it means: No new header names; applications that use mapped fields need to define their own way to distinguish them A new section about these considerations
Code change:
other means of determining appropriate associations between protected resources and authorization servers are also possible. <del> To support use cases in which the set of legitimate authorization servers to use with the protected resource is fixed and enumerable, this specification defines the "authorization_servers" metadata value, which enables explicitly listing them.  Note that if the set of legitimate protected resources to use with an authorization server is also fixed and enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile. </del> 7.7. The OAuth client is expected to fetch the authorization server

Related discussion:
text: cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.
Code change:
8.3. <ins> The ADLER32 algorithm defined in RFC1950 has been deprecated by RFC3309 because under certain conditions it provides weak detection of errors and is now NOT RECOMMENDED. 8.4. </ins> "Digest" alone does not provide end-to-end integrity of HTTP messages over multiple hops, as it just covers the "representation data" and not the "representation metadata".

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
Clients receiving a pushed response MUST validate that the server is authorized to push it using the same-origin policy (RFC6454).  For <del> example, a HTTP/2 connection to "example.com" is generally </del> <ins> example, an HTTP/2 connection to "example.com" is generally </ins> "www.example.org". 8.3.

Related discussion:
text: l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or
Code change:
mapping its semantics into the protocol's wire format. CONNECT is intended only for use in requests to a proxy.  An origin <del> server that receives a CONNECT request for itself MAY respond with a status code to indicate that a connection is established.  However, most origin servers do not implement CONNECT. </del> <ins> server MAY accept a CONNECT request, but most origin servers do not implement CONNECT. </ins> The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another

Related discussion:
text: The original text here sort of implied that it was enough for an origin server to just send 2xx. That assumed that the request was for the origin server itself and elided a bunch of detail. This is shorter and clearer, I think.
I didn't intend anything here other than a clarification of what was written. I'm mostly guessing what was intended as I don't know what the original text truly intended to say. (I think that it was always possible to use CONNECT with a target of the origin server to do URL But I didn't want to highlight that here; it's a little bit of an odd thing to decide to do and so I wouldn't want to encourage it.)
Code change:
corresponding to that ACK, and generating a delivery rate sample at later a time (upon the arrival of the next ACK).  This can underestimate the delivery rate due the artificially inflated <del> "rs.interval".  As with any effect that can cause underestimation, it is RECOMMENDED that applications or congestion control algorithms using the output of this algorithm apply appropriate filtering to mitigate the impact of this effect. </del> <ins> "rs.interval".  The impact of this effect is mitigated using the BBR.max_bw filter. </ins> 4.5.2.4.3.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
2.1. <del> An example of a cross-device flow that relies on the user copying information from the Initiating Device to the Authorization Device is shown below: The Device Authorization Grant (RFC8628) follows this pattern. </del> <ins> The Device Authorization Grant (RFC8628)is an example of a cross- device flow that relies on the user copying information from the Initiating Device to the Authorization Device.  The figure below shows a typical example of this flow: </ins> 2.2. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization on the user's authorization device via the backchannel. </del> <ins> The Client Initiated Backchannel Authentication CIBA transfers the session on the backchannel with the Authroization Server to request authorization on the Authroization Device.  The figure below shows an example of this flow. </ins> The Authorization Server may use a variety of mechanisms to request user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action. The Client Initiated Backchannel Authentication CIBA follows this pattern. 2.3. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization request via the backchannel. </del> <ins> Examples of the user-transferred authorization data pattern includes flows in which the Initiating Device requests the Authorization Server to send a one time access code (e.g. as a text message or e-mail) to the Authorization Device.  Once the Authroization Device receives the code, the user enters it on the Initiating Device.  The Initiatng Device presents it back to the Authroization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </ins> The Authorization Server may choose to authenticate the user before sending the access code.  The access code may be delivered as a text

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:
Values to be added to this name space require Expert Review (see Section 4.1 of RFC5226). <del> 7.3.2. </del> <ins> 7.4.2. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been populated with the registrations below:

Related discussion:
text: The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.