jiebi/CodeConvo huggingface dataset:
Code change:
Create an ordered list of the field values of each instance of the field in the message, in the order that they occur (or will occur) <del> in the message.  If necessary, separate individual values found in a field instance. </del> <ins> in the message. </ins> Strip leading and trailing whitespace from each item in the list. Note that since HTTP field values are not allowed to contain

Related discussion:
text: This isn't combination at the HTTP level by the client or intermediary, this is combination by either the signer or verifier when making the signature base. It's a MUST here because there needs to be only one way to do it at that step. If the lines are already combined then leave them combined.
hm. ok. So one confusing thing here is that HTTP 5.2 is already only about combining field values. So the "Specifically" is a distraction. Also, 5.2 does not mandate using COMMA SP. The section doing that is 5.3.
Also...: I think I misread that as a recommendation to parse individual field values into a list, before recombining everything. Maybe "parsing out individual field values" needs to be rephrased.
You would only parse out individual values if you: 1: Know the overall syntax/grammar of the field 2: Know that it's a list separated by commas 3: Can't send everything as a single field line 4: Know that an intermediary is going to mess with things sent as multiple lines in a way that you don't want The recommendation is really only for that one corner case, not for every value.
I agree with that, but the spec really needs to be clearer here.
(but I'll note that github's way of displaying diffs in long lines makes it extrremely hard to find out what actually changed)
Code change:
3.3. <del> An item is can be a integer (integer), float (float), string </del> <ins> An item is can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Related discussion:
text: (Related to now-closed ) Should implementations be able to store parsed floats in IEEE754 binary64? And if so, should we expect that they round trip between parsing and serialization? It seems like the current limits were designed to support that notion, but there are cases where they do not. (Note, this isn't about being able to serialize arbitrary C++ doubles; the spec sensibly only supports a tiny subset of all possible 64-bit floats. This is about whether should always be true) IEEE 754 guarantees that if a string with no more than 15 digits is converted to a double and then back to a string, it should result in the original string, but that appears to require rounding in some cases; truncation, which the serialization algorithm calls for, can change the string representation. Parsing the string "12345678901234.1" as a float, for instance, results in a binary64 representation with value 0x42a674e79c5fe433, whose exact decimal expansion is 12345678901234.099609375. Following the text of the serialization algorithm, will be 1, and so the number will be serialized as "12345678901234.0" It appears, as an implementer, that the only way to ensure that a float parsed from a valid string can be serialized back to the original string is to store it as a fixed point decimal in two parts, or else use a float with >64 bits of precision for storage.
Would it be adequate to change truncation to rounding in step 9 of Serializing a Float?
That's a can of worms. Which rounding? (nearest-or-even, nearest-or-away from zero, to zero, up, down?)
I know nearest-or-even is the recommended rounding technique. Can we specify that?
Round, nearest-or-even, to fractionaldigitsavail digits? While we're at it, should the spec be stricter about trailing zeros? My implementation currently strips any trailing zeros after the first position past the decimal point (so 1.230000 is serialized as 1.23, but 1.000000 is serialized as 1.0, as is 1.0000001, after rounding/truncation), which passes the test cases in URL The spec just says "at most fractionaldigitsavail digits, but that allows multiple "correct" serializations of a given float.
Code change:
3.3. <del> An item is can be a integer (integer), float (float), string </del> <ins> An item is can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Related discussion:
text: It's also weird to only require roundtripping for floats that can be represented in binary64. The simplest might solution here might be to just accept that floats are lossy. If an implementer needs precision, use a string. This trade-off seems to work well enough for JSON parsers.
The spec already restricts floats to those which can theoretically be round-tripped into a binary64 and back; this is just about ensuring that that actually happens, if a binary64 is used as the backing store (which is natural for at least C++ and JS implementations)
nearest-or-even SGTM. Stripping trailing zeros as well as leading ones in the integer component sounds good as well. I'll do a PR...
PTAL at the commit. I've added a test for this ("tricky precision float") -- NAME are you using the tests?
/me reads above - yes you are, sorry for the noise.
I do not think we should make stripping trailing zeros decimal digits a strict requirement, the number of decimals presented can be out-of-band metadata about the actual precision involved. For instace a timeinterval serialized as 3.0 vs 3.000 vs. 3.000000 might be used to communicate the precision of the measurements as tenths of seconds / milliseconds / microseconds respectively. But we should probably recommend stripping trailing zero decimal digits for bandwidth reasons, if there is no communicative reason to retain them.
If someone wants to use the precision of measurement that way, it'd need to be available in all implementations to be interoperable -- i.e., we'd have to require implementations to preserve that precision. I'm pretty dubious on that being possible and correctly implemented across the board. E.g., requiring every implementation to parse "0.42000" and make the trailing zeros correctly available.
If we're going to round, we probably need to do it before serializing the integer part, since the rounded fractional part may round up to 1.0, as well.
For floats, I think there are two things that we want from this spec (and please let me know if that's not right): Any string which parses as an float can have that float's value stored in a binary64, and serializing that value should reproduce the original string.
Code change:
3.3. <del> An item is can be a integer (integer), float (float), string </del> <ins> An item is can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Related discussion:
text: (modulo some number of 0's at either end) Any real value (regardless of storage implementation) in the range -(1e14-0.05) to (1e14-0.05), exclusive, should serialize to its closest valid sh-float representation. (rounding ties towards an even least-significant-digit) Is that reasonable?
Discussed in Singapore: will discuss on list, but sense in the room is to have a fixed point. Hum in the room prefers fixed point. (Need to still determine number of decimals; q-value uses 3).
Specifically pinging NAME NAME NAME for thoughts re: moving float to fixed-point (straw-man: three digits). This seemed to have strong support in the room, but wanted to make sure you're comfortable with it.
Would fixed point be materially different that what is currently specced? Currently, the spec implies a fixed-point with 6 digits of precision, and a maximum of 15 total digits, which (not at all coincidentally) is the same range that is guaranteed to round trip through an IEEE-754 binary64 representation, which is useful for actual implementations. Edit: I see the three-digit difference now; would the integer portion be restricted to 12 digits in that case?
Yes.
I don't have a strong opinion on switching to 12+3 fixed; I think it would cover all of the use cases that I can currently imagine (and I'm trying hard to discount any sunk costs from implementing the previous draft :stuckouttongue:) If implementation complexity (or perceived complexity) factors in to the decision at all, Chrome's current sh-float serializer, which passes the public test suite, is
If people think it's useful to have a fixed-point number, and can settle on the optimal number of digits for most of their use-cases, then
The (only!) two "real" reason we have float/decimal in the first place is values and subsecond resolution time-{intervals,stamps}, and the one "unreal" reason is that JSON offered that. I think has three decimals, either by norm or convention. Time-intervals such as "process-time for this request" are often sub-millisecond, and that has by and large been the argument for "at least six decimals".
Code change:
3.3. <del> An item is can be a integer (integer), float (float), string </del> <ins> An item is can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Related discussion:
text: Time-intervals do not convincingly overcome Gettys 1st rule[1] or Phil Karltons rule[2]. so 12.3 would be fine with me. [1] Do not add new functionality unless an implementor cannot complete a real application without it. [2] The only thing worse than generalizing from one example is generalizing from no examples at all.
These days at least, it's by specification. It's a number in the range 0.000 to 1.000, and all algorithms I know of that use it would be just as well served by an integer from 0 to 1000. So the only reason to include the dot is if we want to backport existing headers as-is. Not backporting existing headers was a justification for some decisions earlier on, so if that's been reversed, should we revisit some of those other decisions?
Although thinking more about it, most of the earlier decisions are sort of OBE, so it's maybe not such a big deal.
PTAL
Code change:
3.5. <del> A recipient of an SD-JWT VC MUST apply the following rules to obtain the public verification key for the Issuer-signed JWT: </del> <ins> A recipient of an SD-JWT VC MUST apply the following rules to validate that the public verification key for the Issuer-signed JWT corresponds to the value: </ins> Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations. <ins> If a recipient cannot validate that the public verification key corresponds to the value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the

Related discussion:
text: This PR introduces the following changes: - Made all public key validation rules conditional Rejecting the SD-JWT VC if public key validation cannot be done
This harms interoperability, since some implementations will use DIDs and others will use . A more interoperable approach would be to drop and to always use DIDs. Those who want to use domain names and web servers can then still use . DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the vs discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)
NAME Let's have the discussion in . As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.
Let me try to update the PR.
NAME I made all rules now conditional from a verifier perspective. In this way a verifier is compliant if they don't support all rules but the SD-JWT VC would fail validation. Note, it is impossible for a verifier to support all rules that may be defined by ecosystems anyways. Are you ok with the updated language?
As a DID maximalist, I would personally prefer DIDs to be the only mechanism that is used whenever public keys are needed, instead of allowing more static public key mechanisms like "jwt-issuer" or "cnf". Unlike "jwt-issuer", DIDs support identifiers that are persistent, decentralized, and cryptographically verifiable. Unlike "cnf", DIDs support key rotation and other updates. And as I said above, with DIDs there would be only one syntax and one resolution mechanism and one metadata format, instead of multiple different ones that individual implementations may or may not support. But I also understand that for some communities, "keeping it simple" is more important than the above properties, so yes I'm fine with the language, thanks for the effort to update it!
While I understand your points, I think some of them are not true. DIDs may be decentralized, may support key rotations and may have other features.
Code change:
3.5. <del> A recipient of an SD-JWT VC MUST apply the following rules to obtain the public verification key for the Issuer-signed JWT: </del> <ins> A recipient of an SD-JWT VC MUST apply the following rules to validate that the public verification key for the Issuer-signed JWT corresponds to the value: </ins> Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations. <ins> If a recipient cannot validate that the public verification key corresponds to the value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the

Related discussion:
text: There are enough examples of DID methods that do not have those properties. Making DIDs mandatory would limit optionality. But also with DIDs the optionality in my view shifts just shifts a layer further down as there are many DID methods. Indeed allowing DIDs expands optionality by 200+ did methods, so this could indeed be a counterargument. "Cnf" isn't actually far away from DIDs, as the content can vary, there is a registry at IANA for supported methods, with different properties. In my view the cleanest approach for the keybinding would be to register a new cnf type "did" in this registry. But that's off topic in this PR. I'm fine to keep some optionality in the specification at the beginning and then see what is actually being used
True. :) But with "JWT Issuer Metadata" discovered from domain names you will never have the kind of decentralization, persistence, and cryptographic verifiability that DIDs can offer. Sounds interesting! But I agree off-topic. You can still restrict the DID methods you want to use in a specific application such as eIDAS2. For example, if you want to support 1. domain names, 2. plain public keys, and 3. EBSI, then: With the current approach in this specification: For 1. you need to support JWT Issuer Metadata (= a new format introduced by this spec). For 2. you need to support "cnf" and JWK (= a format that has been around for a long time). For 3. you need to support DID documents (= a format that has been around for a few years). Compare that to a DID-only approach: For 1. you need to support did:web (= DID document format) For 2. you need to support did:jwk (= DID document format) For 3. you need to support did:ebsi (= DID document format) You see what I mean? Yes with a DID-only approach you would still have a layer of optionality with regard to DID methods, but you'd only have that ONE layer of optionality instead of TWO layers of optionality, and you'd have a harmonized identifiers syntax and harmonized metadata format.
Code change:
3.5. <del> A recipient of an SD-JWT VC MUST apply the following rules to obtain the public verification key for the Issuer-signed JWT: </del> <ins> A recipient of an SD-JWT VC MUST apply the following rules to validate that the public verification key for the Issuer-signed JWT corresponds to the value: </ins> Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations. <ins> If a recipient cannot validate that the public verification key corresponds to the value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the

Related discussion:
text: But I understand there are communities that simply don't want to use DIDs, so I think this current PR is a good middle ground.
The current text is basically a normative requirement to support all DID resolution. Which is too much, even to the extent we want to allow for or support some DID usage. We need to revisit how this is phrased in the document and even how much (if any) is said. created from discussion in PR : B: "IMHO DIDs can be accounted/allowed for via the "Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above" criteria below and shouldn't receive 1st order treatment like this in the spec." O: "We added DIDs to make the spec useful also for the credential market that uses DIDs. For those people it is required to demonstrate how that can be done. I'm wondering how other folks are thinking about dropping DIDs from getting 1st order treatment. You are right, one can create another draft that just explains how to use DIDs with this spec." Originally posted by NAME in URL
It was definitely not the intend to support all DID methods and all kind of DID resolutions. We need to make DID support optional for verifiers and if they don't have support they won't be able to verify DID-based SD-JWT VCs which is fine.
I made a proposal here
Code change:
chain of aliases encountered during DNS resolution when connecting to the next hop. <del> Knowing the full chain of aliases that were used during DNS resolution is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP. DNS aliases can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS aliases to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the chain of DNS aliases for the next hop by including the list of names in a new "next-hop- </del> <ins> Knowing the full chain of names that were used during DNS resolution via CNAME records DNS is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP.  CNAME records can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS names to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the CNAME chain of DNS names for the next hop by including the list of names in a new "next-hop- </ins> aliases" Proxy-Status parameter. 1.1.

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:
allow the underlying transport's flow-control mechanisms to resolve temporary overloads, rather than terminate connections with the expectation that clients will retry.  The latter technique can <del> exacerbate network congestion. </del> <ins> exacerbate network congestion or server load. </ins> A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request.  If the

Related discussion:
text: The section was talking about server load as well, but it doesn't mention that being a cost of closing connections.
I thought that the assumption was OK-ish: the expectation that clients will retry. That said, I agree that this entire thing could be better. I was looking for a minimal fix.
Code change:
security is "sender-to-receiver", but some "ends" may not be either senders or ultimate receivers, from a certain point of view. <ins> 4.8.1. </ins> 5. This document makes no requests of IANA.

Related discussion:
text: NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.