jiebi/CodeConvo huggingface dataset:
Code change:
presented at the same time, etc. It is important that a Verifier does not make its security policy <del> decisions based on data that can be influenced by an attacker or that can be misinterpreted.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account: </del> <ins> decisions based on data that can be influenced by an attacker.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT. Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether the SD-JWT supports Key Binding or not. </ins> If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or

Related discussion:
text: More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key
Code change:
fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). <ins> Classic HTTP CONNECT requests cannot carry in-stream metadata.  For example, the WRAP_UP capsule I-D.schinazi-httpbis-wrap-up cannot be used with Classic HTTP CONNECT. </ins> 1.3. This specification describes an alternative mechanism for proxying

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
could include additional information known to the application, such as an external host name. <ins> The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is inappropriate, the validity time window is out of specification, a component value cannot be calculated, or any other errors in the signature verification process.  For example, if a signature is being used as an authentication mechanism, an HTTP status code of 401 Unauthorized or 403 Forbidden could be appropriate.  If the response is from an HTTP API, a response with an HTTP status code of 400 Bad Request could include details as described in RFC7807, such as an indicator that the wrong key material was used. </ins> When choosing these parameters, an application of HTTP message signatures has to ensure that the verifier will have access to all required information needed to re-create the signature base.  For

Related discussion:
text: This is a non-normative suggestion for applications to define what to do when a signature is invalid.
This is not necessarily a spec issue, but I thought it should be recorded and maybe discussed here. Is there a recommendation how a server should respond when a request is signed but the signature is invalid. It's likely a 400, unless we want to define a more specific code? Maybe a pointer to the HTTP problem format would be useful?
Good question. If one was using signatures for authentication would 401 be correct? Clearly an additional error message would be useful.
This really depends on how the signature is applied, and I don't think that the signatures spec should really have a strong opinion on the matter.
I agree it depends on signature, but a bit of confrontation is beneficial. Even some non-normative guidance is ok to me. WDYT about: 400 in a generic case (malformed signature) 401/403 if signature is used for authnz This is the case of Content-Encoding and Content-Type. Eg.
Is this the problem format document: URL ?
Almost: URL
I like the approach in PR to make a suggestion on the error codes and leave it up to the application to determine what makes sense in its context.
Code change:
2.5. <del> The client presents the authorization grant it received from the authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" RFC7521. </del> <ins> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1. <del> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7523.  Otherwise, the client SHOULD request an access token using the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the </del> <ins> The authorization grant is a JWT bearer token, which the client uses to request an access token as described in the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523.  For the </ins> purpose of this specification the following descriptions apply: The client MAY indicate the audience it is trying to access through

Related discussion:
text: example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT
Code change:
request. An origin server that receives an If-Unmodified-Since header field <del> MUST evaluate the condition (evaluation) prior to performing the </del> <ins> MUST evaluate the condition as per evaluation prior to performing the </ins> method. If the selected representation has a last modification date, the

Related discussion:
text: this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.
Code change:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del> <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del> <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

Related discussion:
text: HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!
Code change:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> following claims are used within the Key Binding JWT: </del> <ins> Key Binding JWT MUST adhere to the rules defined in Section 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins> <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.

Related discussion:
text: This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.
Code change:
5.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the <del> following claims are used within the Key Binding JWT: </del> <ins> Key Binding JWT MUST adhere to the rules defined in Section 5.10 of I-D.ietf-oauth-selective-disclosure-jwt. </ins> <del> The Key Binding JWT MAY include addtional claims which when not understood MUST be ignored. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. </ins> 5.2.

Related discussion:
text: This fixes Issue . Note that this removed the "exp" claim which I think we don't need to mention explicitly.
SD-JWT defines the KB-JWT header, SD-JWT-VC only refers to the claims. Is it necessary to reference to the SD-JWT spec for this?
We do refer to the Key Binding JWT: URL Is there anything else missing?
Closing this issue since got merged.
LGTM
Code change:
9.5.20. <del> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a </del> <ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a </ins> <del> status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body </del> <ins> status code is inappropriate), and the syntax of the request payload is correct, but was unable to process the contained instructions. For example, this status code can be sent if an XML request payload </ins> contains well-formed (i.e., syntactically correct), but semantically <del> erroneous, XML instructions. </del> <ins> erroneous XML instructions. </ins> 9.5.21.

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.
Code change:
9.5.20. <del> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a </del> <ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a </ins> <del> status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body </del> <ins> status code is inappropriate), and the syntax of the request payload is correct, but was unable to process the contained instructions. For example, this status code can be sent if an XML request payload </ins> contains well-formed (i.e., syntactically correct), but semantically <del> erroneous, XML instructions. </del> <ins> erroneous XML instructions. </ins> 9.5.21.

Related discussion:
text: I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.