jiebi/CodeConvo huggingface dataset:
Code change:
8.5. <del> Digest fields may expose details of encrypted payload when the checksum is computed on the unencrypted data. </del> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest"

Related discussion:
text: Remove cleartext references.
From NAME WGLC review: I think this was added to cover the id-sha-* algorithms that we defined but have since removed. Let's consider removing this consideration unless it still applies (and if it does, maybe we need some more text).
Code change:
If the TLS certificate does not contain the new origin, but the server has claimed support for that origin (with an ORIGIN frame, see <del> RFC8336) and advertised support for HTTP-layer certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </del> <ins> RFC8336) and advertised support for HTTP-layer server certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </ins> describing the desired origin.  The client then sends a "CERTIFICATE_NEEDED" frame for stream zero referencing the request, indicating that the connection cannot be used for that origin until

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
If the Relying Party does not send an Accept Header, the response type is assumed to be known implicit or out-of-band. <ins> A successful response that contains a Status List Token MUST use an HTTP status code in the 2xx range. A response MAY also choose to redirect the client to another URI using a HTTP status code in the 3xx range, which clients SHOULD follow.  A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). </ins> The following are non-normative examples for a request and response for a Status List Token with type "application/statuslist+jwt":

Related discussion:
text: Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.
Code change:
Abstract This specification defines a new method of client authentication for <del> OAuth2 RFC6749 by extending the approach defined in RFC7523.  This </del> <ins> OAuth2 RFC6749 by extending the approach defined in RFC7521.  This </ins> new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attested key based authentication scheme. 1. <del> RFC7523 defines a way for a client to include an assertion in a token </del> <ins> RFC7521 defines a way for a client to include an assertion in a token </ins> request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide a way for a client instance to authenticate it self with the

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <ins> 1.2. This document cites productions in Augmented Backus-Naur Form (ABNF) productions from RFC7233, using the notation defined in RFC5234. </ins> 2. This document recommends a two-step process for accessing resources

Related discussion:
text: mention the syntax update the reference type the citations consistently
1) It should be RFC 5234, not RFC 4234 2) If it's there, it should actually be mentioned somewhere in the spec.
Code change:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for any stream, including idle or closed streams. </del> <ins> be sent in any stream state, including idle or closed streams. </ins> The payload of a PRIORITY frame contains the following fields:

Related discussion:
text: This was confusing a few people who weren't clear if the prohibition on frame sending for CONTINUATION trumped this or not. This isn't a perfect fix, but it should be enough.
LGTM
Merged by RFC editor.
Code change:
6.2.3.5. FIDO2/WebAuthn SHOULD be used for cross-device authentication <del> scenarios whenever the devices are capable of doing so.  It MAY be used as an authentication method with the Authorization Code Grant </del> <ins> scenarios whenever the devices are capable of doing so and a suitable FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant </ins> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/

Related discussion:
text: Addressed issue NAME NAME
Feedback from Dean Saxe during WGLC Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. URL
Adressed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
Code change:
6.2.3.5. FIDO2/WebAuthn SHOULD be used for cross-device authentication <del> scenarios whenever the devices are capable of doing so.  It MAY be used as an authentication method with the Authorization Code Grant </del> <ins> scenarios whenever the devices are capable of doing so and a suitable FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant </ins> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/

Related discussion:
text: Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes
Code change:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described <del> in section 5.2.1), which is only a speedbump along the road to </del> <ins> in document-requests), which is only a speedbump along the road to </ins> exploitation. Features like "<link rel='prerender'>" prerendering can be

Related discussion:
text: In URL under sub heading # 1 there is a paragraph, "Attackers can still pop up new windows or trigger...", which references section 2.1 for more information on that topic. However section 2.1 is "Conformance Criteria" so that doesn't seem the intended target.
Thanks!
Code change:
identifier as a concept as well] A workload needs to obtain its identity early in its lifecycle.  This <del> identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built. </del> <ins> identity is the base identity upon which further identity and security context are built. </ins> Identity bootstrapping often utilizes identity information provisioned through mechanisms specific to hosting platforms and orchestration services.  This initial bootstrapping information is used to obtain specific identity credentials for a workload.  This <del> process may use attestation to ensure the workload receives correct identity credentials.  An example of a bootstrapping process follows. </del> <ins> process may use attestation to ensure the workload receives the correct identity credentials.  An example of a bootstrapping process follows. </ins> arch-fig provides an example of software layering at a host running workloads.  During startup, workloads bootstrap their identity with the help of an agent.  The agent may be associated with one or more workloads to help ensure that workloads are provisioned with the correct identity.  The agent provides attestation evidence and other <del> relevant information to a server.  After obtaining identity credentials from the Server it passes them to the workload.  The server validates this information and provides the agent with identity credentials for the workloads it is associated with.  The server can use a variety of internal and external means to validate the request against policy. </del> <ins> relevant information to a server.  The server validates this information and provides the agent with identity credentials for the workloads it is associated with.  The server can use a variety of internal and external means to validate the request against policy. After obtaining identity credentials from the Server, the agent passes them to the workload. </ins> How the workload obtains its identity credentials and interacts with the agent is subject to different implementations.  Some common

Related discussion:
text: Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.
Code change:
The "id" value is optional. <del> 2.1.6. </del> <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
Please annotate the Permanent and Provisional Message Header registries to indicate that HTTP field name registrations have moved, <del> with an appropriate link. </del> <ins> with an appropriate link (such as: "HTTP field name registrations have been moved to <https://www.iana.org/assignments/http-fields> per [this document].") and furthermore remove the existing note pointing to RFC7231 ("See section 8.3.1 of [RFC7231] for information on registering new HTTP Header Fields."). </ins> After that is complete, please update the new registry with the field names listed in the following table.

Related discussion:
text: note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry
Code change:
The same claim may be independently registered in multiple TS.  To register a claim, the service performs the following steps: <del> Client authentication. </del> <ins> Client authentication.  This is implementation-specific, and MAY be unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. </ins> <del> So far, implementation-specific, and unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. Issuer identification.  The service must check that the ledger records a recent DID document for the "issuer" protected header of the envelope.  This MAY require that the service resolve the issuer DID and record the resulting document.  (See issuer identity above.) </del> <ins> Issuer identification.  The TS MUST store evidence of the DID resolution for the "issuer" protected header of the envelope and the resolved key manifest at the time of registration for auditing.  This MAY require that the service resolve the issuer DID and record the resulting document, or rely on a cache of recent resolutions. </ins> Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the issuer

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del> <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del> <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.

Related discussion:
text: to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!
Code change:
An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del> <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del> <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.

Related discussion:
text: In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.
Code change:
access as an entry point and perform lateral moves to obtain additional privileges and access to restricted resources. <del> 3.4.6. </del> <ins> 3.4.7. </ins> An attacker initiates an employee onboarding flow and obtains a QR code from the onboarding portal to invoke a digital wallet and

Related discussion:
text: See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Code change:
non-public content, or poison a cache.  See security.considerations for security considerations regarding message routing. <del> 5.4. </del> <ins> 5.5. </ins> The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to

Related discussion:
text: and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.