jiebi/CodeConvo huggingface dataset:
Code change:
Clients (user-agents and intermediaries) that sent the request in early data MUST automatically retry the request when receiving a 4NN (Too Early) response status code.  Such retries MUST NOT be sent in <del> early data, and SHOULD NOT be sent if the TLS handshake on the original connection does not successfully complete. </del> <ins> early data. </ins> Intermediaries that receive a 4NN (Too Early) status code MAY automatically retry requests after allowing the handshake to complete

Related discussion:
text: NAME was confused by the text here and I confess that I don't remember why it was added. There are actually esoteric cases where you get server data that you can read before the handshake is complete (QUIC tends to enable that sort of mess), but there is no circumstance where the client can read the 425 but can't also determine whether that the handshake is not done to its satisfaction. The client might decide that it wants to abort and not provide a certificate or something, but most implementations don't really allow that sort of messing around.
Code change:
Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.

Related discussion:
text: adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!
Code change:
Claim Name: "status" <ins> Claim Key: TBD (requested assignment 65535) </ins> Claim Description: Reference to a status or validity mechanism containing up-to-date status information on the CWT.

Related discussion:
text: Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.
Code change:
message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was <del> received on the default TCP port, if any, for the received-protocol. </del> <ins> received on the default port, if any, for the received-protocol. </ins> A sender MAY generate comments to identify the software of each recipient, analogous to the

Related discussion:
text: Source:
It's completely irrelevant to the recipient what port number was used for an upstream intermediary, which is why it says MAY here.
There are two issues here: 1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here. 2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.
This is for Via. HTTPS is not a separate protocol. "https" is a scheme that, among other things, doesn't allow an intermediary to forward HTTP messages until they are beyond the origin secured connection (and hence no longer HTTP/TLS). Whatever the post-TLS origin does to forward its messages via CDN or downstream origins is beyond the scope here.
Yes, we can just remove TCP from that sentence.
That would be acceptable.
Code change:
explicit expiration time is present in the stored response.  Because of the requirements in response.cacheability, this means that, effectively, heuristics can only be used on responses without <del> explicit freshness whose status codes are defined as cacheable by default (see overview.of.status.codes), and those responses without </del> <ins> explicit freshness whose status codes are defined as " " (e.g., see overview.of.status.codes), and those responses without </ins> explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive). <ins> Note that in previous specifications heuristically cacheable response status codes were called "cacheable by default." </ins> If the response has a header field (header.last-modified), caches are encouraged to use a

Related discussion:
text: For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.
Code change:
NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. <del> 6.2. </del> <ins> 5.3.2. </ins> Most infrastructure networks at present do not provide NAT64 service. Many infrastructure networks do not provide DHCPv6 Prefix Delegation.

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
"urn:ietf:params:oauth:token-type:txn-token" "subject_token" REQUIRED.  The value MUST represent the subject of <del> the transaction.  This could be an OAuth access_token received by an API Gateway, a JWT assertion constructed by a workload initiating a transaction or a simple string value all identified by "subject_token_type". </del> <ins> the transaction.  This could be an inbound token received by an API Gateway, or a self-signed JWT constructed by a workload initiating a transaction, the type of which is identified by "subject_token_type". </ins> "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter

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:
Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple <del> such objects into one object, and provides Key Binding using means </del> <ins> such objects into one object, and provide Key Binding using means </ins> other than the Key Binding JWT. 8.

Related discussion:
text: first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.
Code change:
component: If the resource identifier value contains a path component, any <del> terminating "/" MUST be removed before appending "/.well-known/" and the well-known URI path suffix.  The consumer of the metadata would make the following request when the resource identifier is </del> <ins> terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI path suffix between the host component and the path component.  The consumer of the metadata would make the following request when the resource identifier is </ins> "https://resource.example.com/resource1" and the well-known URI path suffix is "oauth-protected-resource" to obtain the metadata, since the resource identifier contains a path component:

Related discussion:
text: As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.
Code change:
parameter's functionality is already covered when the "key" parameter is used on a dictionary item, since "key" requires strict serialization of the value.  The "bs" parameter, which requires the <del> raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </del> <ins> raw bytes of the field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters can be defined in the HTTP Signature Component Parameters registry established in component-param-registry.

Related discussion:
text: Proposed fix in URL - note that this is an incompatible change.
FWFW, if the argument is that not escaping the escape character is actually ok for this purpose...: in that case the prose should actually explain this.
I actually do think it's ok to not escape the escape character. If you've got non-ASCII header values you're already kinda out in the weeds in terms of processing the header bytes. Ultimately the signature base really only needs to have bytes, but its input is constrained to ASCII because (1) all derived components are already constrained this way (2) component names and arguments are already constrained and (3) header component values (here) are SUPPOSED to be constrained to ASCII, but might not be in some weird corners as you've pointed out. All that the newly-introduced percent encoding is doing is putting bumpers around the weird corner that isn't supposed to happen but might in some cases. I'd honestly be happier with putting advice to use the binary sequence wrapping ( flag) on problematic non-ASCII header values instead of doing percent-encoding and requiring universal escape of the escape character when the encoding isn't going to hit the VAST majority of use cases. That would reverse the previously-applied fix but I'm fine that.
That works for me. If we combine that with the "MUST produce an error for non-ASCII" in the signature base generation (and people actually do that check), we should be safe.
OK, I'll work on that, unless you want to take a swing at it.. Since we've already got the cut-out for fields that don't behave nicely as lists (specifically Set-Cookie), we've got a good space to put this advice. I think an error on generation makes perfect sense here too. I'll back out the percent-encoding for non-ASCII headers at the same time (but note it'll stay for query parameters, where I do think it makes sense to use).
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.8. </del> <ins> 6.9. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.8. </del> <ins> 6.9. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon"). <del> By its nature, this technique is vulnerable to active attacks.  A mechanism for partially mitigating them is described in commit. </del> <ins> A mechanism for partially mitigating active attacks is described in commit. </ins> 1.1.

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a <del> single comma (",") and optional whitespace (OWS). </del> <ins> single comma (",") and optional whitespace ( , defined in whitespace). </ins> 5.6.1.1.

Related discussion:
text: Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.
Code change:
computation.  For some algorithms, one or more parameters can be supplied. <del> The BNF for "parameter" is defined in Section 4.4.1.4 of I-D.ietf- httpbis-semantics.  All digest-algorithm values are case-insensitive. </del> <ins> The BNF for "parameter" is defined in Section 4.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
Transparency Services MAY support additional APIs for auditing, for instance, to query the history of Signed Statements. <del> Typically a Transparency Services has a single Issuer identity which </del> <ins> Typically a Transparency Service has a single Issuer identity which </ins> is present in the "iss" claim of Receipts for that service. Multi-tenant support can be enabled through the use of identifiers in

Related discussion:
text: Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM
Code change:
inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with <del> Signed Merkle Tree Proof. </del> <ins> Signed Inclusion Proof. Editors note: We may want to move inclusion path representations to the specification that is required to register a new algorithm in the proposed tree algorithms registry. Editors note: We recommend tree algorithm simple take the inclusion path as opaque bytes. </ins> If the tree size and leaf index is known, then a compact inclusion path variant can be used: <del> Otherwise, the direction for each path step must be included: </del> <ins> Leaf index is also sometimes referred to as sequence number. Otherwise, the direction each path step must be included: </ins> FIXME bit vector: 0 right, 1 left, so no bit labels

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del> <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.

Related discussion:
text: Good clarification, with a few nits to reduce and clarify the text
All edits have been addressed. I believe this is ready for merging.
Thanks, NAME Sounds like we can address this suggestion separately and we can merge this as-is
For the next submission deadline, RegInfo needs more detail to convey it's purpose. Maybe... it may even need a new name, as RegInfo might not be limited to key/value pairs about registration policy?
LGTMI would prefer "The key/value pair semantics are application-specific, or even possibly specified by each Issuer for each of their Feed." but I am fine with both formulations. Thanks.
Code change:
priority order. The sender MUST respect flow control even if means delivering streams <del> out of delivery order.  It is OPTIONAL to prioritize retransmissions. </del> <ins> out of send order.  It is OPTIONAL to prioritize retransmissions. </ins> 6.2.

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.