jiebi/CodeConvo huggingface dataset:
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: Clarify the optionality of the cnf claim (to
please see issue and note that the text in this PR has "This [cnf] claim MUST be present when cryptographic Key Binding is to be supported." Also note this PR isn't for issue and it was probably a mistake on my part to have suggested text there that touches two issues. But they were both on cnf so I did what I did [no pun intended]. This PR only attempts to clarify the optionality of the cnf claim for issue . There doesn't yet seem to be consensus on .
URL
NAME you probably made the comment while I was updating my original comment based on re-reading the PR. I still think it should remain "required when cryptographic binding is used"
what does this mean? you believe sd-jwt-vc should have more than one way to do cryptographic holder binding? or that many of the credentials will not use cryptographic holder binding?
No, I just mean SD-JWT VCs can be key bound, but they don't need to be. Therefore it is an optional feature.
I see, the difference here is that if key binding shall be used, then cnf must be used while the other formulation leaves more space?
If that's the intent, sounds more appropriate to me. just saying would lead to confusion that it is optional even when cryptographic binding is used.
I also like the proposed version more. The proposed language addresses which is based on developer feedback that were confused by the current language that uses REQUIRED if ... . So I think that OPTIONAL seems to solve that issue. IMO, it is also appropriate since we have the additional requirement in the paragraph that says MUST be present if cryptographic binding is required.
Sorry, I don't understand why more space is needed here? The less optionality in key binding, more interop. with the current PR, it would be ok to use a top level sub claim and put a DID there (instead of using URL). I think it is harmful for the interop, that SD-JWT VC is hoped to bring
I don't see that this optionality is allowed by the following?
I see your point. The proposed text opens a door for key binding without using the cnf claim.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: However, the new text is more initiative and we could add this constraint as an additional sentence or in the section on key binding
Okay, it is already present. Sorry I didn't recheck the changes. Lgtm then
I'm struggling to understand the disagreement/argument here. But I'm trying... The text for cnf in the PR has: which seems to me to clearly says that cnf is the required way to do key binding, if doing key binding. Especially the "This claim MUST be present when cryptographic Key Binding is to be supported" sentence. Would changing that sentence to "This claim is REQUIRED when cryptographic Key Binding is to be supported" help? Maybe I'm missing the point of contention but that and the current PR text and the current text in the draft all say the same thing - that cnf is the one and only way to do key binding in SD-JWT VC but b/c key binding isn't itself required, the claim also isn't required.
I thought that was better phrasing anyway so made the change w/ 9edae9d4aa1dc2b647c77029b7d415d384cded49
Seems great to me.
You're suggested pedantic wording is indeed better than what I'd had. Thanks. I've accepted it w/ c6b138036e035e6df2a2f983aa4cf8b183d39fc2
Not all VCs require key binding. For those, cnf should be made optional.
I've read the text in URL that says "REQUIRED when Cryptographic Key Binding is to be supported." as being optional or not required when key binding isn't needed. Perhaps we need to discuss and/or make things more clear?
Do you think we should also explain the OPTIONAL case or replace the REQUIRED with something else? CONDITIONAL is not a reserved word unfortunately.
I would propose to clarify this. From a quick reading this is not obviously optional and it does not match the other claims that only state REQUIRED/OPTIONAL without any conditions. As cryptographic binding is optional, I think this line should begin with "OPTIONAL. [...]"
URL attempts to do just that
thank you!lgtm, see my comment in the discussion.I like this version.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: CNF is more optional to me and having required as the first keyword seems less rightI'm generally fine with the change, but I think I want to be pedantic here and resolve the contradiction.
Code change:
propscope, rather than on interactive media use cases or on-demand use cases. The reasoning behind this proposal can be found in analy-interact. <del> The considerations for protocol work to satisfy the proposed use cases can be found in considerations. </del> <ins> The requirements for protocol work to satisfy the proposed use cases can be found in req-sec. </ins> Most of the rest of this document provides background for these sections.

Related discussion:
text: Move "considerations" to a separate draft, and do various related cleanup work (for example, removing unneeded references that supported text that has been deleted.
(but document focus is on all media categories, not just live media) (moving the considerations section to its own draft) (moving this diagram to the considerations draft)
Our diagram shows "media transport protocol" as one layer, which can be true, but the text points out that anything running over HTTP/3, or even WebTransport over HTTP/3, will have multiple media transport protocols. It would be helpful for readers if we showed this.
Sports fans of this draft may remember that this section was called Requirements, and true sports fans may remember that the contents had changed very little from when James and I thought this draft would be focused on Interactive use cases - and now it's focused on live media use cases. Rather than go into the BOF with a "Requirements" section that was a natural attraction for protocol designers, and almost completely mistargeted, I provided text for some of the considerations that I could type off the top of my head, before the I-D deadline. The existing list of considerations is not a complete list, and some of the considerations that are described in this section are "To Do", where the first thing To Do is to decide whether that consideration is a consideration for Live Media. To mention one significant example, the discussion about WebTransport doesn't mention one of the biggest advantages - the use of existing CDN infrastructure for live media streaming. But there are other examples - and I may think about this issue, and let other people also provide thoughts here, before I try to resolve the issue with PRs. (tagging the group, so you can be thinking about this as well) NAME NAME NAME NAME NAME
NAME and NAME - It is occurring to me that all the use cases we're recommending in this draft, and all the use cases that are named in , are pointing towards LIVE media. This document is even explaining why we think that's what matters first.
Code change:
propscope, rather than on interactive media use cases or on-demand use cases. The reasoning behind this proposal can be found in analy-interact. <del> The considerations for protocol work to satisfy the proposed use cases can be found in considerations. </del> <ins> The requirements for protocol work to satisfy the proposed use cases can be found in req-sec. </ins> Most of the rest of this document provides background for these sections.

Related discussion:
text: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?
Code change:
Responses that include informational status codes (see HTTP) are encoded by repeating the response control data and associated header <del> section until the final status code is encoded. </del> <ins> section until a final response control data is encoded.  The status code distinguishes between informational and final responses. </ins> The format of the informational response control data is shown in format-informational.

Related discussion:
text: Just a little more explanation. And .
Comment by NAME : I see that the talks about "final status code": and that explains why you called it "final" in , but I think you need to define why "final" is used in the "final response control data" when it first appear (so in ), or you can remove "final" in 3.5 and explain that only in 3.5.1.
Code change:
that requires immediate termination of the connection.  The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon.  Endpoints MUST NOT increase the <del> value they send in the last stream identifier, since this could cause their peers to erroneously retry streams if a GOAWAY frame is lost. </del> <ins> value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. </ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under which circumstances they should never scan a QR code (e.g. display a message that the QR code will only be displayed on kiosks within trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). </ins> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as

Related discussion:
text: Incorporating feedback based on
Follows . (CC NAME User Experience (extension) During potentially dangerous operations (e.g., reading the QR code on the Authorizing Device), advise users to verify the trustworthiness of the source, for instance by checking that the connection is protected through TLS or by verifying that the URL really belongs to the Authorization Server. In particular, when activating the camera to read the QR code on the Authorizing Device, the activity could also display a warning message advising users to only scan QR codes displayed on a specific website. Limitations: those already reported in the mitigation
After discussing with Daniel, this is very close to the recommendations on user education. We will review that addition and incorporate the recommendation to add warning messages when scanning a QR code, if it is not sufficiently clear already.
Code change:
NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, <del> such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </del> <ins> such as SSL or TLS, or if the host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </ins> secure protocol and "localhost" to be trusted host. If the cookie's http-only-flag is true, then exclude the cookie

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
The response SHALL include a single "Upgrade" header field with the value "connect-tcp". <ins> The response SHOULD include a "Capsule-Protocol: ?1" header. </ins> If the request is malformed or impermissible, the proxy MUST return a 4XX error code.  If a TCP connection was not established, the proxy MUST NOT switch protocols to "connect-tcp", and the client MAY reuse this connection for additional HTTP requests. <del> After a success response is returned, the connection SHALL conform to all the usual requirements for classic CONNECT proxies in HTTP/1.1 (RFC9110).  Additionally, if the proxy observes a connection error from the client (e.g., a TCP RST, TCP timeout, or TLS error), it SHOULD send a TCP RST to the target.  If the proxy observes a connection error from the target, it SHOULD send a TLS "internal_error" alert to the client, or set the TCP RST bit if TLS is not in use.  These behaviors avoid truncation of transfers between the client and the target on vulnerable protocols (e.g., HTTP/1.1 without TLS) while preserving the confidentiality and integrity guarantees of the "https" scheme. </del> 3.2. In HTTP/2 and HTTP/3, the proxy MUST include

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:
If the client and authorization server are using DPoP binding of access tokens and/or authorization codes, then the "auth_session" <del> value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </del> <ins> value SHOULD be protected as well.  The authorization server SHOULD associate the "auth_session" value with the DPoP public key.  This removes the need for the authorization server to include additional claims in the DPoP proof, while still benefitting from the assurance that the client presenting the proof has control over the DPoP key. To associate the "auth_session" value with the DPoP public key, the authorization server: MUST check that the same DPoP public key is being used when the client presents the DPoP proof. MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by

Related discussion:
text: Clarify that the binding is not done through cryptographic means but rather through association by the authorization server since the binding is only between the client and the authorizations server. See issue cc NAME , NAME
Since RFC 9449 does not specify how "additional" parameters can be bound, please say explicitly that (presumably) this is a claim within the DPoP proof JWT named "auth_session".
It is not a new claim in the DPoP proof, because that would imply the binding happens from the client, not the AS. Brian's suggestion was to require the AS to do the binding, in which case it's internal and not part of the spec.
So can you please fine tune the language in 9.6.1. At least this reader understands the word "binding" when used in this context as cryptographic binding, and this is obviously not what you want. Maybe use "associate" instead.
Fixed by .
Code change:
how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. <del> model describes the object model employed by MOQT </del> <ins> model describes the object model employed by MOQT. </ins> session covers aspects of setting up a MOQT session.

Related discussion:
text: No real changes here (other than adding a missing period) but changes newlines for checker tools
LGTM, as it seems to just whitespaces only change.
Code change:
Header and trailer sections consist of zero or more field lines; see HTTP.  The format of a field section depends on whether the message <del> is known- or intermediate-length. </del> <ins> is known- or indeterminate-length. </ins> Each field line includes a name and a value.  Both the name and value are length-prefixed sequences of bytes.  The field name length is at

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
"aud" trust domain.  Unlike OpenID Connect, the "sub" claim is NOT associated with the "iss" claim. <del> REQUIRED A string defining the purpose or intent of this </del> <ins> REQUIRED A String defining the purpose or intent of this </ins> transaction. OPTIONAL A JSON object that conatains values that remain immutable

Related discussion:
text: I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?