jiebi/CodeConvo huggingface dataset:
Code change:
For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515. <del> The disclosures (both for issuance and presentation) SHOULD be </del> <ins> The Disclosures (both for issuance and presentation) SHOULD be </ins> included in the serialized JWS using the member name at the top-level of the JSON object (the same level as the

Related discussion:
text: Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!
Code change:
This specification defines the following specialty content identifiers: <del> The target request endpoint. (content-request-target) </del> The signature metadata parameters for this signature. (signature- params) <del> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) </del> <ins> The method used for a request. (content-request-method) </ins> <del> 2.3.1. </del> <ins> The full target URI for a request. (content-target-uri) </ins> <del> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the "@request-target" identifier. </del> <ins> The authority of the target URI for a request. (content-request- authority) </ins> <del> Its value is canonicalized as follows: </del> <ins> The scheme of the target URI for a request. (content-request- scheme) </ins> <del> Take the lowercased HTTP method of the message. </del> <ins> The request target. (content-request-target) </ins> <del> Append a space " ". </del> <ins> The absolute path portion of the target URI for a request. (content-request-path) </ins> <del> Append the path and query of the request target of the message, formatted according to the rules defined for the :path pseudo- header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. </del> <ins> The query portion of the target URI for a request. (content- request-query) </ins> <del> 2.3.1.1. </del> <ins> The parsed query parameters of the target URI for a request. (content-request-query-params) </ins> <del> The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values. </del> <ins> The status code for a response. (content-status-code). </ins> <del> 2.3.2. </del> <ins> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) 2.3.1. </ins> HTTP Message Signatures have metadata properties that provide <del> information regarding the signature's generation and/or verification. </del> <ins> information regarding the signature's generation and/or verification, such as the list of covered content, a timestamp, identifiers for verification key material, and other utilities. </ins> The signature parameters specialty content is identified by the "@signature-params" identifier.

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
Code change:
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <del> TODO: HTTP2 forbids TLS renegotiation and post-handshake authentication but it's possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the "Client-Cert" header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth.  And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing. </del> 2. 2.1.

Related discussion:
text: I've opened issues for the things that were previously TODO comments in the draft; this removes them from the draft itself.
Issues and for posterity
NAME wrote: Public Keys is maybe worth considering. This too is this is an area for further discussion and consideration should this draft progress.
My take: keep the scope of this narrow. If raw keys are needed - or other certificate types for that matter - then we can define another field.
I concur with Martin's take. The TODO made its way into the individual draft (and subsequently became this issue) based largely on this brief suggestion in one part of an off-list email on the topic, "While I do not know of a use case yet, it might be worth keeping raw public keys in mind as a use case." Which is not unreasonable but I'm going to favor narrow scope here over speculative need.
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain).
Code change:
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <del> TODO: HTTP2 forbids TLS renegotiation and post-handshake authentication but it's possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the "Client-Cert" header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth.  And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing. </del> 2. 2.1.

Related discussion:
text: End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.
NAME wrote: http-core. This should be pretty simple to add, but for the purposes of having a clean PR pulling out the TODOs, I'm moving it to an issue for now anyway.
URL points to draft-ietf-httpbis-semantics for this
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.
Code change:
middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 7.6. </del> <ins> 7.7. </ins> A proposed congestion control algorithm ought not to presume that all general Internet paths reliably deliver packets in order.  RFC4653 discusses the effect of extreme packet reordering. <del> 7.7. </del> <ins> 7.8. </ins> A proposed congestion control algorithm SHOULD consider how the proposed congestion control algorithm would perform in the presence

Related discussion:
text: From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.
Code change:
a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP <del> connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </del> <ins> connection and send the preface followed by HTTP/2 frames.  Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> <del> Likewise, the server MUST send a ConnectionHeader. </del> <ins> Likewise, the server MUST send a preface. </ins> Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future

Related discussion:
text: As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.
Code change:
6. <del> TBD: Verifier provided . </del> <ins> The Security Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following security considerations need to be taken into account when using SD-JWT VCs: 6.1. The JWT Issuer Metadata configuration is retrieved from the JWT 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. Before making a request to the JWT Issuer Metadata endpoint, the 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 not address an internal service (by IP address or an internal host name) and that, if an external DNS name is used, the resolved DNS name does not point to an internal IPv4 or IPv6 address. When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure that the response is a valid JWT Issuer Metadata configuration document before processing it. Additional considerations can be found in OWASP_SSRF. </ins> 7.

Related discussion:
text: Add reference to Security Considerations in SD-JWT
E.g.: SSRF with Issuer URI
Code change:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "float". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop. If type is "integer" and input_number contains more than 15 characters, fail parsing. <del> If type is "float" and input_number contains more than 16 </del> <ins> If type is "decimal" and input_number contains more than 16 </ins> characters, fail parsing. If type is "integer":

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:
If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "float". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop. If type is "integer" and input_number contains more than 15 characters, fail parsing. <del> If type is "float" and input_number contains more than 16 </del> <ins> If type is "decimal" and input_number contains more than 16 </ins> characters, fail parsing. If type is "integer":

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.