jiebi/CodeConvo huggingface dataset:
Code change:
5.2. HTTP does not place a predefined limit on the length of each field <del> line, field value, or on the length of the header or trailer section as a whole, as described in conformance.  Various ad hoc limitations on individual lengths are found in practice, often depending on the </del> <ins> line, field value, or on the length of a header or trailer section as a whole, as described in conformance.  Various ad hoc limitations on individual lengths are found in practice, often depending on the </ins> specific field's semantics. A server that receives a request header field line, field value, or

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. <ins> 8.10. Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the header parameter when the SD-JWT is issued, and for Verifiers to check this value. When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. </ins> 9. The privacy principles of ISO.29100 should be adhered to.

Related discussion:
text: Thanks, editorial comments taken.
Whether this format is JWT or JWT-like, the considerations in the still apply. Please consider adding a claim. cc NAME
Explicit typing via the header can and should be done by specific applications or types of SD-JWT. But this SD-JWT draft is defining the general JWT-like construct and explicit typing of the generic thing isn't particularly useful or meaningful.
The The next draft will have a media type and structured suffix that can help with specific applications or types of SD-JWT doing explicit typing FWIW URL
I would be open to adding one sentence in the draft saying "applications of SD-JWT SHOULD be explicitly typed". I agree there cannot be only one type for all SD-JWTs.
I'm not quite sure where to add that one sentence. And a bit more context might be needed with it. I'll see what I can figure out. Maybe a small section like 3.11 in rfc8725. But (helpful) suggestions/ideas would be welcome in the meantime.
Add this sentence at the end of 5.1: The header parameter is RECOMMENDED, see Sec. 5.1.4 for more details. And as a new Sec. 5.1.4, "Explicit Typing": A commonly seen attack is for one kind of JWT to be confused for another. Both regular JWTs as well as SD-JWTs are vulnerable to confusion attacks. To prevent these attacks, it is RECOMMENDED to specify an explicit type by including the header parameter when the token is issued, and for Verifiers to check this value. The relevant token's content type can be used, e.g. , but often a more application-specific value is preferred. See Sec. 3.11 of RFC 8725 for more details.
Thanks NAME I took some inspiration from you words in creating PR .
merged PR to close this one
Thanks for preparing this! LGTM, just two small editorial comments.
Code change:
example, if the publisher is a relay that has received ANNOUNCE messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", <del> "participant=200"), a SUBSCRIBE_NAMESPACE for ("example.com", </del> <ins> "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", </ins> "meeting=123") would match both. Parameters: The parameters are defined in version-specific-params. <del> The publisher will respond with SUBSCRIBE_NAMESPACE_OK or SUBSCRIBE_NAMESPACE_ERROR.  If the SUBSCRIBE_NAMESPACE is successful, </del> <ins> The publisher will respond with SUBSCRIBE_ANNOUNCES_OK or SUBSCRIBE_ANNOUNCES_ERROR.  If the SUBSCRIBE_ANNOUNCES is successful, </ins> the publisher will forward any matching ANNOUNCE messages to the subscriber that it has not yet sent.  If the set of matching ANNOUNCE messages changes, the publisher sends the corresponding ANNOUNCE or

Related discussion:
text: On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.
Code change:
Even a simple mechanism for end-to-end validation is thus valuable. <del> 8.4. </del> <ins> 8.5. </ins> Digital signatures are widely used together with checksums to provide the certain identification of the origin of a message NIST800-32.

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:
in Receipt. The last two steps may be shared between a batch of Signed Statements <del> recorded in the Append-only Log. </del> <ins> registered in the Append-only Log. </ins> A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt.

Related discussion:
text: We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM
Code change:
The "next-hop-aliases" parameter's value is a String that contains one or more DNS names in a comma-separated list.  The items in the <del> list include all names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS.  Since DNS names can include comma (",") characters in them, any commas that appear in a DNS names MUST be represented using a percent-encoded "%2C" value instead.  The aliases SHOULD appear in the order in which they were received in DNS; that is, if a name has a CNAME record with a first alias, which has a CNAME record for a second alias, the aliases should appear in that order. For example: indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </del> <ins> list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they were received in DNS. If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the value in the CNAME record for the original hostname, and the final name in the "next-hop- aliases" list would be the name that ultimately resolved to one or more addresses. For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </ins> "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Related discussion:
text: This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:
Code change:
It may be sufficient to store the result of the verification and any End-User data that is needed for the application. <del> If reliable and secure key rotation and revocation is ensured according to issuer_signature_key_distribution, Issuers may opt to publish expired or revoked private signing keys (after a grace period that ensures that the keys are not cached any longer at any Verifier).  This reduces the value of any leaked credentials as the signatures on them can no longer be trusted to originate from the Issuer. </del> 11.3. If the SD-JWT is transmitted over an insecure channel during issuance

Related discussion:
text: to
As far as I know, the idea of burning private keys to facilitate repudiation or reduced data value didn't resonate with any of the audiences for whom it was intended. I think the document would be better off without the paragraph copied below from URL And we might avoid some potentially difficult/confusing/painful/etc conversations in various latter stage IETF process steps.
I'm told that my statement that it "didn't resonate with any of the audiences for whom it was intended" might be premature.
I agree with deleting the text about publishing private keys. Yes, it's a technique that could be used with SD-JWTs but it's in no way specific to SD-JWTs. It could be used with normal JWTs, CWTs, SAML tokens, X.509 certs, etc. It doesn't add to the specification to describe this here.
leaving this open with no action for the time being because, as Dr. NAME says, "it's complicated".
agreed to remove.
Code change:
Claim Description: The authorization context details <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section txn-token-claims of this specification

Related discussion:
text: We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager
Code change:
If input is a type other than an integer, float, string or binary content, fail serialisation. <del> Let output be an empty string. If input is an integer, let value be the result of applying Serialising an Integer ser-integer to input. </del> <ins> If input is an integer, return the result of applying Serialising an Integer ser-integer to input. </ins> <del> If input is a float, let value be the result of applying Serialising a Float ser-float to input. </del> <ins> If input is a float, return the result of applying Serialising a Float ser-float to input. </ins> <del> If input is a string, let value be the result of applying Serialising a String ser-string to input. </del> <ins> If input is a string, return the result of applying Serialising a String ser-string to input. </ins> <del> If input is binary content, let value be the result of applying Serialising Binary Content ser-binary to input. Return output. </del> <ins> Otherwise, return the result of applying Serialising Binary Content ser-binary to input. </ins> 4.1.5.

Related discussion:
text: Serialised wasn't getting appended to
Would it be better to just have each of the steps before return their result?
I did wonder that when writing it. Or make them all . Or however you think looks best. I probably should have just filed it as an Issue. :thinking:
Code change:
4.3. <ins> Finally, the "On-Demand" use cases described in this section do not have a tight linkage between ingest and streaming, allowing significant transcoding, processing, insertion of video clips in a news article, etc.  The latency constraints for the use cases in this section may be dominated by the time required for whatever actions are required before media are available for streaming. </ins> 4.3.1. *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: On Demand Where media is ingested and processed for a system to later serve it <del> to clients as on-demand media.  This may be media captured from live output or provided as a pre-recorded source, and may optionally be transcoded upon ingest. </del> <ins> to clients as on-demand media.  This media provided from a pre- recorded source, or captured from live output, but in either case, this media is not immediately passed to viewers, but is stored for "on-demand" retrieval, and may be transcoded upon ingest. </ins> 4.3.2.

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
Code change:
7.4. <ins> If a client expects to interact with multiple resource servers, the client SHOULD request audience-restricted access tokens using RFC8707, and the authorization server SHOULD support audience- restricted access tokens. Without audience-restricted access tokens, a malicious resource server (RS1) may be able to use the "WWW-Authenticate" header to get a client to request an access token with a scope used by a legitimate resource server (RS2), and after the client sends a request to RS1, then RS1 could re-use the access token at RS2. While this attack is not explicitly enabled by this specification, and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically-configured clients.  As such, the use of audience-restricted access tokens and Resource Indicators RFC8707 is RECOMMENDED when using the features in this specification. 7.5. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource.  Whether a protected resource publishes

Related discussion:
text: The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.
Code change:
7.4. <ins> If a client expects to interact with multiple resource servers, the client SHOULD request audience-restricted access tokens using RFC8707, and the authorization server SHOULD support audience- restricted access tokens. Without audience-restricted access tokens, a malicious resource server (RS1) may be able to use the "WWW-Authenticate" header to get a client to request an access token with a scope used by a legitimate resource server (RS2), and after the client sends a request to RS1, then RS1 could re-use the access token at RS2. While this attack is not explicitly enabled by this specification, and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically-configured clients.  As such, the use of audience-restricted access tokens and Resource Indicators RFC8707 is RECOMMENDED when using the features in this specification. 7.5. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource.  Whether a protected resource publishes

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
types, and constraints upon them.  For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only <del> strings beginning with the letter "Q". </del> <ins> strings beginning with the letter "Q".  Likewise, inner lists are only valid when a header definition explicitly allows them. </ins> When Structured Headers parsing fails, the header is ignored (see text-parse); in most situations, violating header-specific

Related discussion:
text: NAME Fetch Metadata will add a bunch of headers that are supposedly structured headers, but given their simplicity can be compared using equality on servers. If servers did that it would likely prevent adding parameters in the future however or making other supposedly-compatible extensions. Should we accept this for headers clients transmit to servers or should we do something akin to TLS's GREASE?
In general, greasing HTTP headers is interesting -- although I'm a little wary, given the extent of the grease-related discussions we've had in QUIC. As a baseline -- I think that the goal of grease should be to prevent casually incomplete implementation (e.g., someone using regex or splitting on commas and extracting the raw values). It can never assure complete and correct implementation overall. I think the interesting thing to grease in SH is parameters, since that's a primary extensibility mechanism, and is (now) uniform across values. Ideally, grease parameters would contain values that frustrate the casual approaches above; e.g., strings with commas in them. A couple of options I can see; We could advise / require sending implementations to generate extra parameters sporadically (not super-often, so as to limit bandwidth consumption, but not so rarely that it creates debugging nightmares). To be recognisable as grease to the receiving application, their names would have to have some convention. We could advise / require headers using SH to define their own greasing mechanisms when appropriate. I suspect that truly automatic greasing might increase friction against adoption of SH, since some people's reaction will be "what is this thing doing to my header?!?". Invoking in on a header-by-header basis (perhaps by adding an appendix with guidance) might help.
I think the main benefit is derived from clients doing this so the main party to convince would be the user agents (who are already generally on board with SH).
So, should anything in the spec change? At this point the most I can see is adding something like:
I guess I'm mainly interested if implementations are willing to do this uniformly. NAME NAME NAME
I think NAME suggestion is reasonable to recommend (though it risks a quagmire when we attempt to ship a new header defining a quotient of quietly quixotic quilting), but I'll defer to NAME or NAME to weigh in from Chromium's networking team's broader perspective for headers generally.