jiebi/CodeConvo huggingface dataset:
Code change:
The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" <del> setting. </del> <ins> setting.  An endpoint which receives a "CERTIFICATE_NEEDED" frame but did not advertise support MAY treat this as a connection error of type "CERTIFICATE_WITHOUT_CONSENT". </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that

Related discussion:
text: though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.
Code change:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.

Related discussion:
text: is saying something about using From for authentication, but I don't understand it: I think that this could be saying one of two things, maybe the latter: From contains only an unsupported claim about the identity of the generator of the message, so it can't be used for authentication. Including a From value that also contains a secret, such as a password, that could be used to authorize a request is unwise because recipients of the message won't necessarily treat the value as confidential and so the secret might leak. That latter is a bit strange, because an authorization could be bound to the specific request in various ways that might limit these risks. I can't tell because the logical chain between "this is who made the request" and use of the value for authorization isn't very well developed. It might be better to say nothing here instead.
My .02 - I think the intent was more the first -- just a warning that this is not an authentication mechanism to ward off the uninformed and optimistic. Given that this isn't widely used anyway, I don't think the text causes harm; I propose we just leave it as is.
Please, drop everything from "since" onward in that case. The reasoning makes no sense to me and the unsupported recommendation is clear enough.
+1
Code change:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.

Related discussion:
text: though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.
Code change:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.

Related discussion:
text: I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.
Code change:
unwanted, or invalid requests. A server SHOULD NOT use the From header field for access control or <del> authentication, since most recipients will assume that the field value is public information. </del> <ins> authentication. </ins> 10.1.3.

Related discussion:
text: ... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.
Code change:
The format of "UNSUBSCRIBE" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> 6.8.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification <del> might provide a way to support this use case. </del> <ins> might provide a way to support this use case.  Alternatively, a server might use a ConnectionErrorHandler of type to request the client use a protocol which supports renegotiation. </ins> 9.2.2.

Related discussion:
text: This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.
Code change:
6.2.5. <del> Trust in clients that submit Signed Statements for Registration is implementation-specific.  An attacker may attempt to register any Signed Statement it has obtained, at any Transparency Service that accepts them, possibly multiple times and out of order.  This may be mitigated by a Transparency Service that enforces restrictive access control and Registration Policies. </del> <ins> Authentication of client applications is out of scope for this document.  Transparency Services MUST authenticate both client applications and the Issuer of signed statements in order to ensure that implementation specific authentication and authorization policies are enforced.  The specification of authentication and authorization policies is out of scope for this document. </ins> 6.2.6.

Related discussion:
text: This is an alternate proposal to to This PR: Keeps Client as : an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization. Replaces Verifier with Relying Party: a relying party depends on Signed or Transparent Statements to verify an Artifact.,
Thanks, NAME Definitely looking for more input, and I’m also ok to close the PRs and issue and use the existing terminology. My main concern is a Relying Party is a consumer of information. They rely on the receipts and signed statements from the Transparency Service. Which makes it a good candidate to replace Verifier If we replace Client with Relying Party, this confuses what we call the entity that registers signed statements. They are not the issuer, as the issuer signs statements, but is not the entity with access rights to the Transparency Service. Both the producer and consumer need access rights. That was what we had as client.
There is still additional work that needs to be done. Client applications submit signed statements, and obtain receipts, so they can include transparent statements in downstream products. A consumer of a downstream product is a relying party, they either verify the transparent statements themselves, or they delegate the verification role to the "verifier" role.
As discussed on today's call. Folks expressed concern that "Verifier" was not friendly enough to "Consumers or Relying Parties", that are supposed to process receipts. Editors Update: We can choose to: [ ] Accept [ ] Accept [ ] Close both PRs and this issue, and keep the doc with Client and Verifier
NAME wanted to take a look for a proposal
Just an update, I plan to send a PR with proposed changes this week. NAME shall we sync up in the comments or out of band elsewhere?
A.J. Yes, let’s get together and work out a proposal. I’m booked today but tomorrow is open except for 07:00-08:00 and 14:00-15:00 PST (10:00-11:00 and 17:00-18:00 EST) Monty
Sorry, NAME I had to dig a bit to find your email in my inbox from the mailing lists but I found it. Invite sent. I think we can make quick progress and draft a PR tomorrow.
Code change:
6.2.5. <del> Trust in clients that submit Signed Statements for Registration is implementation-specific.  An attacker may attempt to register any Signed Statement it has obtained, at any Transparency Service that accepts them, possibly multiple times and out of order.  This may be mitigated by a Transparency Service that enforces restrictive access control and Registration Policies. </del> <ins> Authentication of client applications is out of scope for this document.  Transparency Services MUST authenticate both client applications and the Issuer of signed statements in order to ensure that implementation specific authentication and authorization policies are enforced.  The specification of authentication and authorization policies is out of scope for this document. </ins> 6.2.6.

Related discussion:
text: Met with NAME and we discussed perspectives and work on this in the near-term, summarized with URL More to follow.
Adding some more notes to plot out the work, Monty and I discussed aligning the diagram with the separate/distinct RATS architecture, but the separate call out of a distinct Relying Party role and how it pertains to agent was discussed when we met, per discussion I missed in today's author/editor meeting. For my future reference, I need to re-review the doc, as well as compare/contrast ,
So I did not make as much tangible progress today and have spent a lot of time thinking and reading as I re-read this SCITT Architecture draft and related WG drafts (RATS, OAuth) where Relying Party is defined. So, before I spend a significant effort in drawing this with aasvg, I would like to quickly highlight the gaps in my understanding via Mermaid so I can quickly iterate. I have tried reading the mailing list but it not 100% clear where the dichotomy between Auditor and Verifier occurred, but they seem overlapping and redundant to me unless Verifier is, in fact, some non-person entity, like the software doing the verification itself (so this goes to what should we rename client to in , separate of this), but does that not in fact mean Auditor is the Relying Party of sorts? It seems Auditor is just giving a specific name to a general kind of consumer and that is not what a Verifier is. So on that note, this is the current version of the SVG diagram in Mermaid ( I hope I got this right, I cannot just have labels like "Issuer" on the left-hand side so I use subgraphs to box those and not do something clever with dotted lines and cause more problems). (Source: URL) It would seem we really need to change the diagram and the terminology to get rid of Auditor altogether, so first, we would move to this. (Source: URL) I was going to do a subsequent edit, but at this point I will have to ask the group: what is a verifier doing that is different from a relying party owner with a relying party? Could you separate one from the other? (Don't you need to replay the log to verify the sequence of statements?)
Code change:
6.2.5. <del> Trust in clients that submit Signed Statements for Registration is implementation-specific.  An attacker may attempt to register any Signed Statement it has obtained, at any Transparency Service that accepts them, possibly multiple times and out of order.  This may be mitigated by a Transparency Service that enforces restrictive access control and Registration Policies. </del> <ins> Authentication of client applications is out of scope for this document.  Transparency Services MUST authenticate both client applications and the Issuer of signed statements in order to ensure that implementation specific authentication and authorization policies are enforced.  The specification of authentication and authorization policies is out of scope for this document. </ins> 6.2.6.

Related discussion:
text: For reference, there is so much overlap with I think we need to either add compare statements to terminology and touch up the current state diagram to disambiguate the use of these terms. Screenshot below. ! So would that mean, if they are in fact separate, Edit 2 incrementing after Edit 1 to reflect my understanding would be ... this? (Source: URL) If we start to think this way, do we consider the software (client/agent/what have you) used by the Issuer to be distinct? Similar but with one of two functionalities (an agent/client/what have you can be for Issuers to get receipts of signed statements or a verifier that reads all of them)? /cc NAME I am not sure this update at the end of the day reflects our discussion, but I feel like I lost the thread of what we discussed and seemed concrete in discussion. Translating it into diagram and wording updates has left me scratching my head.
And just for the sake of dissing RATs... ! IMO this is reversed... to rely on something you must trust a verifier or be a verifier. I think what they mean is for the relying party to depend on a verifier, but what it looks like is that a verifier sits in front of an RP.
A verifier can be a person or automation that was configured by a person. This is likely a great conversation for the NAME would you be able to lead that discussion with NAME
hm... if we are talking RATS an entity can take on both the Roles of Verifier and Relying Party at the same time (rendering the creation and conveyance of Attestation Results moot)
It seems now obsoletes the diagrams in URL and review in a previous meeting reflecting improvements and viable changes based upon answers to the questions posed in strawman diagrams in that comment.
Also of not my updates to the potential (and beneficial) overlap and possible alignment between relying party and client per URL
Ping NAME NAME
I wrote some of my thoughts on URL and aj-stein-nist/ietf-wg-scitt, but for me Client was going to replace Relying Party (Client==RP), so I am not sure if making Verifier==RP is what my intent was when I revived the issue, so I will leave to others to decide.
Code change:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del> <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del> <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del> <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del> <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF

Related discussion:
text: HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!
Code change:
2.1.4. <del> The following examples demonstrate valid Expect-CT response header fields: </del> <ins> The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances): </ins> 2.2.

Related discussion:
text: URL too wide artwork by changing the second example to use multiple field instances (which, in itself, is good to have in the examples anyway)
Thanks!
Code change:
Specification: [this document] <del> 4. </del> <ins> This document registers the following entry in the HTTP/2 Settings Registry, as per RFC7540: Code: 0x7 Name: ACCEPT_CACHE_DIGEST Initial Value: 0x0 Reference: [this document] 5. </ins> The contents of a User Agent's cache can be used to re-identify or "fingerprint" the user over time, even when other identifiers (e.g.,

Related discussion:
text: The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.