jiebi/CodeConvo huggingface dataset:
Code change:
"keyid": The identifier for the key material as a String value. <ins> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify signatures relevant for specific applications or protocols. </ins> Additional parameters can be defined in the iana-param-contents. Note that there is no general ordering to the parameters, but once an ordering is chosen for a given set of parameters, it cannot be

Related discussion:
text: That seems like way more work than just signing the right things. An app could fail to require all of an operation's inputs to be signed. In this case, the only way helps is if it is unique per request, e.g., a hash of all the operation inputs. This is definitely way more work than just signing the right things. Two apps could fail to require the request audience (e.g., the target URI authority) to be signed, allowing signatures to be replayed across them. Here only helps if it is set to something that is app specific. That rules out the use of standardized values based on protocol (e.g., ) or intent (e.g., ). And if is being set to something app-specific, why not just sign the app-specific thing that is already in the request? Are there other failure modes that I'm not considering, where would prove more useful? So far this leaves me feeling that is more likely to encourage bad habits and give implementers a false sense of security than it is to address any actual security risks.
I do not see how having a fixed signature prefix will solve any security issues with signature base generation. All the same problems with bad implementations occur internally in the signature base, the only difference is that you've got MAYBE a good first line -- and as NAME mentioned this is not stopping people from doing different bad things like having newlines in the content identifier. We can add a security or implementation considerations section on newlines in the signature base. Even then, I am failing to see how this prefix idea is related to the signature context concept. And as NAME said, apps failing to sign enough is an issue for the app. Having a signature context isn't going to magically get that necessary content signed, nor will it make a badly written verifier reject unsigned required content. Again, I'm fine with adding context as an optional parameter for applications that want to make use of it for signaling, but I don't think it solves things in the way that is being presented here.
Works for me. Thanks!
Code change:
A server that does return a continuously aggregating ("live") response should return data using chunked transfer coding and not <del> provide a Content-Length header.  A 0-length chunk indicates the end of the transfer, per RFC7230. </del> <ins> provide a Content-Length header field.  A 0-length chunk indicates the end of the transfer, per RFC7230. </ins> 3.

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
8. <del> Unless advertised by a Transparency Service, every Issuer must treat Signed Statements it registered (rendering them as Transparent Statements) as public.  In particular, a Signed Statement Envelope and Statement payload MUST NOT carry any private information in </del> <ins> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in </ins> plaintext. <ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </ins> 9. On its own, verifying a Transparent Statement does not guarantee that

Related discussion:
text: This PR elaborates on the privacy analysis a bit. Describe why it is important (because we cannot delete items from the log) Remove the BCP 14 keyword (MUST NOT). Both the Privacy and Security Considerations sections should have the character of an analysis. They should be recommendations, or highlight gotchas to implementors. Anything binding should be in the main body of the RFC. Yes, this would need to be fixed in the Security Considerations, too. Expand the "Unless advertised by a Transparency Service" phrase into a paragraph about access control. This way it's more actionable. (Why would you advertise it? When would it be okay to advertise?)
Authors: (NAME NAME NAME NAME NAME I'm inclined to merge this as is. Any disagreements, or additional changes? We can iterate afterward, but seems like a good baseline to add
Yes. this looks pretty stable and uncontroversial. Thanks a ton, NAME
Code change:
The method SHALL be "GET". <ins> The request's target SHALL correspond to the URI derived from expansion of the proxy's URI Template. </ins> The request SHALL include a single "Host" header field containing the origin of the proxy.

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
If the final character of input_number is ".", fail parsing. <ins> If the number of characters after "." in input_number is greater than six, fail parsing. </ins> Parse input_number as a float and let output_number be the product of the result and sign.

Related discussion:
text: Is this PR meant to include ?
Yeah, oops. Need more coffee.
Try now.
Otherwise, looks alright to me.
The current definition of sh-float is surprisingly hard to serialize correctly, the best C-code I could come up with is: int serializeshfloat(char buf[18], double d) { int p = 0, l, dig; buf[0] = ''; buf[1] = '\0'; if (isnan(d)) return (-1); if (fabs(d) >= 99999999999999.95) return (-1); if (d = 99999999999999.95) return (-1); if (d < 0) { buf[p++] = '-'; d = -d; } p += snprintf(buf + p, 18 - p, "%-16f", d); while (buf[p-1] == ' ') p -= 1; buf[p] = '\0'; return (p); }
+1 from me, our primary focus should be on data types that will have good interop. That level of precision isn't necessary for any current use of HTTP headers I'm aware of, off the top of my head.
Proposal: Call these decimal. Allow a maximum of 9 digits on the left of the decimal place and 6 after. This matches the definition for int and allows storing this in the same sized slot with a or conversion factor.
ABNF gets much simpler.
NAME That would probably curtail the range too much. I think it is desirable to be able to move posix time_t timestamps in these.
If this really is an integer with fixed point semantics, why do we need it at all?
Because it's easier than making people specify "divide the number by a million to get its real value"? That said, I agree that 9 digits to the left of the point is probably not enough, so a floating point representation is more useful. This is the ABNF equivalent of NAME C code, yeah?: That easily gets us a current 32-bit time_t plus microseconds, and a whole range of other values besides.
Why do the arguments about size of integers not also apply here? is 64-bit on my system, which doesn't fit in the sh-integer definition either.
The current time is ish. You don't need to prefix it with 30 bits worth of zeroes.
Code change:
If the final character of input_number is ".", fail parsing. <ins> If the number of characters after "." in input_number is greater than six, fail parsing. </ins> Parse input_number as a float and let output_number be the product of the result and sign.

Related discussion:
text: I've read the IETF105 minutes, and thought about the fixed-point discussion. All the uses for "decimal number with fractional part" I can think of\ would reasonably served by at least 10 digits to the left\ and at least 3 to the right of the point. So I would support any fixed- or floating-point representation that supports that range of values. \ that's all that matters, right? \ a ten-decimal-digit time_t gives us until November 20, 2286
Using the max-six-decimal definition, and allowing 15 digits with no period or decimals, this C-code will do the job: static char * sh_float(double d) { static char buf[40]; int n; if (fabs(d) < 1000000000) { n = snprintf(buf, sizeof(buf), "%f", d); while (buf[--n] == '0') buf[n] = '\0'; if (buf[n] == '.') buf[n] = '\0'; } else { n = snprintf(buf, sizeof(buf), "%.15g", d); } return (buf); }
Sorry, wrong button.
If I take , then I can almost represent that in a JS float in the most horrific way imaginable: But that doesn't quite fit. 69999999999999999 doesn't fit into a double. If you want to remember the number of additional decimal places so that you don't lose any precision on those trailing decimal places (things like 0.3 are surprisingly tricky to re-encode), you are left with supplementary values. Can someone make a better case for any more than 10^10 values here? I couldn't see a good one. You can fit a 32-bit value in that. If you really think that time_t is valuable, which I'm totally not convinced of, then fewer steps might be acceptable. I can pack this:
PR updated. Any further comments, or ready to merge?
Code change:
of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del> <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track

Related discussion:
text: Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM
Code change:
of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del> <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track

Related discussion:
text: This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM
Code change:
4.1. An SD-JWT, at its core, is a digitally signed document containing <del> hash digests over the claim values with unique random salts and other </del> <ins> hash digests over the claim values with random salts and other </ins> metadata.  It MUST be digitally signed using the issuer's private key. <del> can be a simple object with claim names mapped to hash digests over the claim values with unique random salts: </del> <ins> is an object with claim names mapped to the digests over the claim values with random salts calculated using digest derivation function such as hash function, HMAC, or other: </ins> The claim name (

Related discussion:
text: added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged
Code change:
(e.g.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (e.g. "sha", "crc32c"). <ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas digest is only used in relation to the value of the fields. </ins> 2. The representation digest is an integrity mechanism for HTTP

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
Such signatures can protect one or more HTTP fields and there are additional considerations when "Digest" is included in this set. <del> Since digest fields are hashes of resource representations, they </del> <ins> Since digest fields are checksums of resource representations, they </ins> explicitly depend on the "representation metadata" (e.g. the values of "Content-Type", "Content-Encoding" etc).  A signature that protects "Digest" but not other "representation metadata" can expose

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
Byte Sequences can be conveyed in Structured Fields. <del> When serialised in a textual HTTP field, a Byte Sequence is delimited </del> <ins> When serialized in a textual HTTP field, a Byte Sequence is delimited </ins> with colons and encoded using base64 (RFC4648, Section 4).  For example:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
described in this document.  By restricting the protocol to only be executed on devices trusted by the authorization server, it prevents attackers from using arbitrary devices, or by mimicking devices to <del> initiate the protocol.  Trusted devices include devices that are pre- registered with the authorization server or are subject to device management policies.  Device management policies may enforce </del> <ins> initiate the protocol. Authorization Servers MAY use different mechanisms to establish which devices it trusts.  This includes limiting cross-device flows to specific device types such as intractive whiteboards or smart TVs, pre-registering devices with the authorization server or only allow cross-device flows on devices managed through device management systems.  Device management systems may enforce policies that govern </ins> patching, version updates, on-device anti-malware deployment, revocation status and device location amongst others.  Trusted <del> devices may have their identities rooted in hardware (e.g., a TPM or equivalent technology).  By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </del> <ins> devices MAY have their identities rooted in hardware (e.g., a TPM or equivalent technology). By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </ins> An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to

Related discussion:
text: Refined the trusted device section to make it clear that restricting to a specific device type is another option to limit the impact of deploying cross-device flows (issue )
Limit it to specific devices.
Code change:
specialty content field listed in specialty-content or its associated registry. <del> Signers SHOULD include "@request-target" in the covered content list. </del> <ins> Signers of a request SHOULD include some or all of the control data in the covered content list, such as the "@method", "@authority", "@target-uri", or some combination thereof. </ins> <del> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature metadata parameter can fulfil this role. </del> <ins> Signers SHOULD include the "created" signature metadata parameter to indicate when the signature was created. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, note that

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:
relating to the transaction being performed.  Most of these elements are provided by the OAuth 2.0 Token Exchange specification and the rest are defined as new parameters.  Additionally, this profile <del> defines a new token type URN "urn:ietf:params:oauth:token-type:txn- token" which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. </del> <ins> defines a new token type URN "urn:ietf:params:oauth:token- type:txn_token" which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. </ins> To request a Txn-Token the workload invokes the OAuth 2.0 RFC6749 token endpoint with the following parameters:

Related discussion:
text: We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.
Code change:
To sign using this algorithm, the signer applies the "RSASSA-PSS-SIGN (K, M)" function RFC8017 with the signer's private signing key ("K") <del> and the signature input string ("M") (create-sig-input).  The hash SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </del> <ins> and the signature input string ("M") (create-sig-input).  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes. The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </ins> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input <del> string ("M") re-created as described in verify.  The hash function SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> string ("M") re-created as described in verify.  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes.  The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.2.

Related discussion:
text: This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.