jiebi/CodeConvo huggingface dataset:
Code change:
4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve <del> readability in the definitions of some header field values. </del> <ins> readability in the definitions of some list-based field values. </ins> A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element"

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:
Code change:
The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the <del> specific query format Content-Type's that may be used. </del> <ins> specific query format media types that may be used. </ins> <del> The Accept-Search header specifies a comma-separated listing of media types (with optional parameters) as defined by RFC7231. </del> <ins> The Accept-Search header field specifies a comma-separated listing of media types (with optional parameters) as defined by RFCHTTP. </ins> <del> The order of types listed by the Accept-Search header is </del> <ins> The order of types listed by the Accept-Search header field is </ins> insignificant. 4.

Related discussion:
text: content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See
Code change:
The "Viewport-Width" request header field is a number that indicates the layout viewport width in CSS px.  The provided CSS px value is a <del> number rounded to the largest smallest following integer (i.e. ceiling value). </del> <ins> number rounded to the smallest following integer (i.e. ceiling value). </ins> If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.

Related discussion:
text: WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL
Code change:
simulate their interaction with those algorithms.  To the extent they are not, experiments can be conducted where possible. <del> Note that in many deployments, real-time flows are directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic.  However, a proposal targeting general Internet use </del> <ins> Real-time flows can be directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which can substantially reduce the interplay with other traffic.  However, a proposal targeting general Internet use can not assume this is always the case. </ins> 4.2.3.

Related discussion:
text: Fixed an editorial problem resulting in removing the end of the sentence, which went on to say that you can't assume DSCP, etc. Also changed /many deployments/ to simply say this happens without saying it is often.
From NAME review: Section 3.2.2: Although there are clearly a number of network especially access networks that do deploy and use DSCP classes for its real-time media traffic I think this sentence is misleading. I would think that the majority of the WebRTC traffic carrying audio and video will in fact not be marked or have DSCP markings that survive into the general Internet. I would at least suggest to rewrite the above first sentence to indicate that although this may occur, the CC algorithm under consideration will have to deal with this type of traffic.
Code change:
3.6. <del> Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP, unlike RUSH and SRT, as well as using existing Datagram frames </del> <ins> Some drafts attempt to use existing payloads of RTP, RTCP, and SDP, while others do not. Some use QUIC Datagram frames, while others use QUIC streams. </ins> All drafts take differing approaches to flow/stream identification <del> and management; some address congestion control and others just omit the subject and leave it to QUIC to handle Both QRT and RUSH specify ALPN identification; the Engelbart, Warp, and SRT drafts do not. </del> <ins> and management.  Some address congestion control and others just defer this to QUIC to handle. Some drafts specify ALPN identification, while others do not. </ins> 3.7.

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
additional response header fields to convey related values to aid client processing. <del> 2.2.1. </del> <ins> 3. Servers can advertise support for Client Hints using the mechnisms described below. 3.1. </ins> <del> Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </del> <ins> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure.  Its value MUST be an sh- list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:

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:
3.3. A client that makes a request to an "https" URI without prior <del> knowledge about support for HTTP/2 uses TLS12 with the TLSALPN. </del> <ins> knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.

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:
using frames and streams. While some of the frame and stream layer concepts are isolated from <del> HTTP, the intent is not to define a completely generic framing layer. The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </del> <ins> HTTP, this specification does not define a completely generic framing layer.  The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </ins> 2.2.

Related discussion:
text: Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.
Code change:
Editors note: tree-size-1, could be ommited, if an inclusion-proof is always present, since the inclusion proof contains, tree-size-1. <del> 4.2. </del> <ins> 5.4. </ins> In a signed inclusion proof, the previous merkle tree root, maps to tree-size-1, and is a detached payload.  In a signed consistency proof, the latest merkle tree root, maps to tree-size-2, and is an attached payload. <del> 5. </del> <ins> 6. </ins> See the privacy considerations section of:

Related discussion:
text: This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
Code change:
Editors note: tree-size-1, could be ommited, if an inclusion-proof is always present, since the inclusion proof contains, tree-size-1. <del> 4.2. </del> <ins> 5.4. </ins> In a signed inclusion proof, the previous merkle tree root, maps to tree-size-1, and is a detached payload.  In a signed consistency proof, the latest merkle tree root, maps to tree-size-2, and is an attached payload. <del> 5. </del> <ins> 6. </ins> See the privacy considerations section of:

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
Code change:
SEMANTICS) of a resource identified according to Section 6.4.2 of SEMANTICS together with an indication of the algorithm used: <ins> When a message has no representation data it is still possible to assert that no representation data was sent computing the representation digest on an empty string (see usage-in-signatures). </ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.

Related discussion:
text: Clarifies . 1- + HEAD is used to get a resource checksum 2- no Digest in request for clarity 3- only use sha-256 to focus on the actual example.
Digest can be sent in requests and response Nope, in the example Digest is both in the request and in the response. See the hidden 607 line URL When used in conjuction with signatures, the client that want to certify that no-payload was attached will: compute the Digest of an empty string sign that Digest header with some signature mechanism attach the signature and digest to the request send the request with no payload data The server will then: verify the signature according to the chosen mechanism if no payload is provided, the Digest is the one of an empty string eventually store the signature to prove that the request had no payload Clearly the signature mechanism should provide enough information to define the semantic of the request (eg. the method and all relevant headers). HTH, R.
Well. So the Digest is for the empty request payload. Maybe it would be good to state this in the spec? (That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload...
+1
NAME PTAL :)
I'll repeat what I said earlier: "That said, this is IMHO a very misleading example, as the HTTP spec is very clear that GET/HEAD request bodies ("A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request."). It would probably better to have this example on a request that actually can take meaningful payload..."
In order to make progress here, I suggest we simplify the example to remove the Request digest. That keeps the example focused on it's name "Server Returns No Representation Data".
NAME removed Digest from the HEAD request.
NAME PTAL ;)
NAME PTAL :)
YAY :rocket:
In 10.2 Server Returns No Representation Data: what does the Digest request header field on the HEAD request refer to, and what is the recipient supposed to do with it?
Code change:
SEMANTICS) of a resource identified according to Section 6.4.2 of SEMANTICS together with an indication of the algorithm used: <ins> When a message has no representation data it is still possible to assert that no representation data was sent computing the representation digest on an empty string (see usage-in-signatures). </ins> The checksum is computed using one of the digest-algorithms listed in algorithms and then encoded in the associated format.

Related discussion:
text: there's only one digest in the response, but the prose talks about two
Requests without payload data can still send a field applying the digest-algorithm to an empty representation. The recipient can validate that the digest-value matches the one of an empty representation or not. True. this is confusing, should reference the previous example.:
Code change:
Additional considerations can be found in OWASP_SSRF. <ins> 6.2. When defining ecosystem-specific rules for the verification of the public key, as outlined in verifying-public-key-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the value within the Issuer-signed JWT and the public keys of the Issuer. In situations where an attacker tampers with an SD-JWT VC, it is paramount to ensure that they cannot exert influence over the verification process while employing the same value. </ins> 7. The Privacy Considerations in the SD-JWT specification I-D.ietf-

Related discussion:
text: This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR
Code change:
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does

Related discussion:
text: This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.