jiebi/CodeConvo huggingface dataset:
Code change:
3.1. <del> If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK HPACK or QPACK QPACK) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </del> <ins> If the connection between the TTRP and origin is capable of field compression (e.g., HPACK HPACK or QPACK QPACK), and the TTRP multiplexes more than one client's requests into that connection, the size and variation of "Client-Cert" and "Client-Cert-Chain" field values can reduce compression efficiency significantly.  An origin could mitigate the efficiency loss by increasing the size of the dynamic table.  If the TTRP determines that the origin dynamic table is not sufficiently large, it may find it beneficial to always send the field value as a literal, rather than entering it into the table. </ins> 3.2.

Related discussion:
text: reword the header compression section with more consistent terms for the roles (to
LGTM modulo nit
This section talks about header compression and says Elsewhere in the document, you've used TTRP and Origin to identify the roles in play. I think it would be clearer to use them here. For instance, I might rewrite this as something like
Code change:
implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service -- <del> i.e., SETTINGS changes, small frames, field section compression -- </del> <ins> such as SETTINGS changes, small frames, field section compression -- </ins> have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess.

Related discussion:
text: : Please confirm that "i.e.," is correct here (in which case "SETTINGS changes, small frames, field section compression" should be "SETTINGS changes, small frames, and field section compression") instead of "e.g.,". Original: Most of the features that might be exploited for denial of service - i.e., SETTINGS changes, small frames, field section compression - have legitimate uses.
I think that this should probably e.g., not i.e.
Code change:
where "d(0)" is the payload.  This algorithm takes no extra data. <ins> 4.2. The "QLDB_SHA256" tree algorithm uses the Merkle tree definition from TBD with SHA-256 hash algorithm. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. </ins> 5. TBD

Related discussion:
text: Informal reference: URL TODO: Add QLDB reference to Merkle tree definition. Change target branch to after is merged.
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: Replaces
Thanks!
IMHO we need to be clear what the requirements of SF support are. The way the spec currently is written (referencing RFC 8941) means that SF-shaped field values using the new sf-date format are not supported. I don't think this is what we want, so unless we want to wait for sfbis to be ready, we'll need to add some consideration of how compat with SF extensions/revisions is supposed to work.
The intent of the current text is not to limit the use of the flag to only the currently defined formats. New formats are supported if the signer and verifier support the formats. The agreement of what format to use for a particular field is out of scope for this specification, and needs to be agreed upon by the signer and verifier outside of the signature process. This is true for all the current types and will remain true for any additional types defined in the future.
On a high level, this sounds right. As an implementer of a signature library, calling an SF library, what is your expectation what it'll do with sf-date once the spec is published? What if the sender want to sign an integer param in a dictionary, but the field instance contains another param using sf-date?
I would expect a library of that nature to publish its mapping between field names and SF types, and ideally allow that mapping to be edited by the caller of the library. Otherwise, how would a user of the library be able to provide a type mapping for a custom field that the library doesn't know about, let alone a new sf-type?
Understood. Different layers of libs. What I meant is a generic SF library, that just parses/serializes SF fields.
Then you need to know what you're parsing it in to. SF fields aren't entirely discoverable from the syntax alone, you need to know the type explicitly. I ran into this when implementing my own signature libraries. So the signature library needs to have that mapping, and if the underlying SF library doesn't support some new type, then you can't map to it. Once the dependencies are updated, you can provide that feature up the chain. It all seems pretty standard and simple to me, honestly.
How so? I still don't see the path to interop for any update of the structured field syntax, unless this spec at least provides some hints.
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: You need to know the top-level type (Dictionary, List, or Item) for each field. The consequence of that (AIUI) is that a recipient wishing to validate a signature that uses will need to understand the top-level type of each 'd field in the signature. It'll also need to support the permissable types in those fields -- e.g., if a field allows Date, the recipient needs to be able to handle that. As a result, it won't be possible to reliably verify a signature if your processor doesn't have knowledge of the top-level type, or if it doesn't have support for an extension type in use in one of those fields. However, there is a chance of verifying it still, if the SF-produced form is sent on the wire and not changed at all in transit, and the processor just ignores processing (and in some ways, this is worse than reliably failing). I think this all can be reasoned out by reading the specs appropriately. Documenting it as a tripping hazard would help users avoid interoperability issues, but this specification is already long and dense, and if we also make it a user guide, it will risk becoming unusable. So, speaking personally -- if the above summary is correct, I could see adding a sentence or two to section 2.1.1 at the most; I could also see leaving it to a separate profile/user guide.
[ chair hat on ] This issue is the last thing holding the Signature spec going to IETF LC. NAME NAME please respond to above, particularly: whether such text is necessary whether such text will address the issue when such text, if necesary, would need to be incorporated (before/after LC). Thanks,
I believe it would be good to have such text; and that it should be in the spec, not in a guide that is unlikely to materialize. It should be incorporated before LC (I hope you mean a new WGLC here...?). Given the amount of changes, we really should spend some time reviewing all that changed, and to verify that the open issues have been addressed properly.
NAME can you propose something? I don't see any reason to rerun WGLC, based upon the current PRs; there are some changes (especially in one or two), but they're based on AD review and can be discussed during IETF LC.
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: cc NAME
I would prefer to see your proposal :-). The RFC diff since the last WG version has 143 change blocks: URL We also currently have 17 open issues/PRs: URL IMHO we need to get these closed (can be rejecting or fixing), and also have a look at those that we raised since -13 and closed in the meantime. I don't think we do the community a service by sending this to IETF LC right now.
NAME you are grossly misrepresenting the state of the document. For one, the last WG version, and the one that went to the AD, is -15, not 13, so your diff above is misleading at best. The changes since then have largely not been substantive in nature, and all have been made publicly with the view and input of the WG. The open issues are nearly all addressed by open PRs, which I am waiting for AD feedback before merging (I'm not sure if the AD wants to review the PR text or the merged draft that results). What remains is this issue, as NAME pointed out above. To answer NAME 's question about how to resolve this: I think pointing out as a potential tripping hazard is not necessary but would not be harmful. The precondition to know the type is already in the text as the first sentence about the flag in section 2.1.1: Additionally, the lack of knowledge of the type of the field is already called out explicitly as a required error condition in section 2.5: I would propose we simply add a note to 2.1.1 of the form:
Well, it's hard to say what remains to be done until an issue is actually closed. We're all volunteers here, so it's good to make things as easy as possible to reviewers. So, trying to rephrase: let's get all open issues closed (one way or the other), and let the people who raised the issues give an opportunity to provide feedback before sending this back to the IESG. (I, for once, am not convinced that I agree with the proposed solutions, but due to the type of diffs (long lines) it's a bit tricky to understand what actually changed) works for the sending side; but what is a recipient supposed to do when the sf flag is present and the field value does not parse due to sender and receiver disagreeing about the SF version?
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: Also, that only affects the toplevel type of the structured field. It does not address the case where an extension parameter is added is an sf-date (or any future new type).
NAME until you propose text, it will be hard to say what kind of text you think would close this issue.
Except for this issue and two others recently raised by you (which will be considered as IETF LC issues), all of the issues and PRs you mention were generated by the AD review before IETF LC; this is a normal part of the process that does not require going back to WGLC unless the AD asks for WG review, which . NAME made a reasonable proposal. If you disagree with it, make your own.
If the proposal was: Then this isn't sufficient as it only applies to the toplevel type (see URL). NAME - I believe you are in the best position to make a proposal; but that said; I can try something later today.
So, we have in 2.1.1: This implies that the "sf" parameter can only be used on fields that conform to RFC 8941, no extensions allowed. I would suggest clarifying that, at the end of 2.1.1, with: "Note that the normative requirement to use the SF serialization algorithm precludes any use of future extensions of the structured field syntax. Support for future versions of SF will require an update to this specification." I believe this matches what NAME suggested.
Except that your proposed text is incorrect. The implication you are drawing is not true, nor what others have taken from that text. The use of the parameter does not preclude extensions to RFC 8941, as has been discussed at length here and on the mailing list. Extensions to sf types would not require changes to the signatures spec. I propose closing this issue without change to the signatures spec.
Sorry. Mark asked me to propose text, and that's what I did. The text has a normative requirement to use an RFC8941 serializer, so the proposed text is correct. That we disagree here is proof that a clarification is needed. If you feel that that p.o.v.
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: is too restrictive, we'll have to somehow relax the requirement on the serializer (for instance, by stating that the serializer needs to implement 8941 or a successor RFC - that is an RFC that obsoletes 8941). FWIW, I agree that this would be good. But it is not what the spec says.
No, we reference the current document and if that document is updated or obsoleted by something else after publication then you as an implementer go and follow that. That's how updating RFC's already work. All the specs and systems that implemented RFC2616 didn't suddenly break and become invalid when 7230 or later 9110 came out. Here, It's up to the updaters of 8941 to make sure there's A serialization section. Your view of specification dependency is not at all in line with reality.
I see where you're coming from; I'd appreciate if you would do the effort to understand where I'm coming from. The difference here is that any spec that extends 8941 with new types by definition is not backwards compatible. This is because 8941 has no extension points, has drastic error handling and thus requires a wholesale spec update for new things. This is very different from most other RFCs that we're using here. If there is agreement about what we want, why don't we just say it?
To illustrate further: RFC8941-vs-8941bis is like XML1.0-vs-1.1 or HTTP1.1-vs-2.0, not like RFC2616-vs-RFC9112.
That's a very specific definition of 'not backwards compatible' and one that I suspect many would be surprised by. Just because there are no explicitly nominated extension points doesn't mean you can't evolve the specification in a backwards-compatible fashion; the key requirement is that valid inputs per the 'old' version are also valid inputs per the 'new' revision. That is the case for sf-bis. It is true that an invalid input for RFC 8941 will now become valid; specifically, a type value beginning with 'NAME used to generate an error, and now will not (provided that the following characters are appropriate). The reasonable question to ask at this point is whether it's realistic / probable that an application will be depending upon that error being thrown to operate.
Code change:
STRUCTURED-FIELDS on the "member_value" and its parameters, not including the dictionary key itself.  Specifically, the value is serialized as an Item or Inner List (the two possible values of a <del> Dictionary member). </del> <ins> Dictionary member), with all parameters and possible sub-fields serialized using the strict serialization rules defined in STRUCTURED-FIELDS (or the applicable section of its extensions or updates). </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature base.  Parameterized keys MAY appear in any

Related discussion:
text: Can you suggest when that might be the case? Because I find it doubtful in the extreme that this will cause real-world problems.
I agree that this wouldn't cause real-world problems. I just also wish that our specs actually say what we think should happen, instead of requiring people to figure out. So in this case, I think we can solve this by saying "RFC 8941 or a revision obsoleting it".
Since NAME acknowledges that this doesnt affect interoperability and this is merely a "wish", NAME why don't you go ahead and incorporate your proposal so we can ship this spec?
NAME - please don't claim what I said something I did not say. My position remains: the spec should be clear about what it expects implementers to do. Right now it is not. If the agreement is "use RFC 8941 or a future revision", why don't we say that?
Proposed change: URL
Code change:
to authorize its calls to subsequent workloads.  Subsequent workloads may obtain Txn-Tokens of their own. <ins> If the requesting service does not have an inbound token that it can use in its request to the Txn-Token Service, it generates a self- signed JWT and passes that in the request in place of the external authorization token. </ins> 2.2.2. A service within a call chain may choose to replace the Txn-Token.

Related discussion:
text: Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.
Code change:
(e.g., a smartphone) to authorize access to a resource (e.g., access to a streaming service). <del> Cross device flows have several benefits, including: </del> <ins> Cross-device flows have several benefits, including: </ins> There are three cross-device flow patterns for transferring the authorization request between the Initiating Device to the

Related discussion:
text: See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).
Code change:
This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends <del> use cases on live media contribution, syndication, and streaming as the basis for discussions that should guide the design of protocols to satisfy these use cases. </del> <ins> use cases on live media ingest, syndication, and streaming as the basis for discussions that should guide the design of protocols to satisfy these use cases. </ins> Note to Readers

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). </del> <ins> Aside from the well-known exception noted below, a sender MUST NOT generate multiple header fields with the same field name in a message, or append a header field when a field of the same name already exists in the message, unless that field's definition allows multiple field values to be recombined as a comma-separated list [i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values)]. </ins> A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the

Related discussion:
text: I had in mind something a little more general, that would include fields which are defined like Vary:
Code change:
3. This section defines the abstract types for Structured Fields, and <del> summarises how those types are serialised into textual HTTP fields. </del> <ins> summarizes how those types are serialized into textual HTTP fields. </ins> In summary:

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.