jiebi/CodeConvo huggingface dataset:
Code change:
requests with "unsafe" HTTP methods (as was the case prior to the introduction of the "SameSite" attribute). <del> For example, a login flow may involve a cross-site top-level "POST" request to an endpoint which expects a cookie with login information. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method.  On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. </del> <ins> For example, the concluding step of a login flow may involve a cross- site top-level "POST" request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login.  For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow. </ins> The "Lax-allowing-unsafe" enforcement mode described in lax-allowing- unsafe retains some of the protections of "Lax" enforcement (as <del> compared to "None") while still allowing cookies to be sent cross- site with unsafe top-level requests. </del> <ins> compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests. </ins> As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF.

Related discussion:
text: Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.
Code change:
requests with "unsafe" HTTP methods (as was the case prior to the introduction of the "SameSite" attribute). <del> For example, a login flow may involve a cross-site top-level "POST" request to an endpoint which expects a cookie with login information. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method.  On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. </del> <ins> For example, the concluding step of a login flow may involve a cross- site top-level "POST" request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login.  For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow. </ins> The "Lax-allowing-unsafe" enforcement mode described in lax-allowing- unsafe retains some of the protections of "Lax" enforcement (as <del> compared to "None") while still allowing cookies to be sent cross- site with unsafe top-level requests. </del> <ins> compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests. </ins> As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF.

Related discussion:
text: The Lax-allowing-unsafe applicability to "cookies which were created recently [~2 mins]" is quite helpful in this case because that transactional state specific cookie will typically be set right at the beginning of the whole login flow and only needs to live as long as it takes for the user to complete the login journey. Oh yes, of course, it's very messy. I'm sure it wasn't the only pattern that motivated Lax-allowing-unsafe but I'm almost as sure that it was the primary pattern that motivated it. Let me see if I can tweak the text to cover things generally (without screwing it up) and the commit message can reference this issue to link back for more info?
Hi NAME Have you had any progress?
I'm sorry NAME probably my fault in the way I left the prior but I wasn't sure if I was supposed to be working on a PR or was waiting for an okay from you/WG/etc to do so. And in the intervening time my attention for it was sort of overtaken by events. Apologies again and I'll try and do something soon.
URL is a minimalist attempt at some adjusted text for this
LGTM, thanks! I'll wait for NAME to take another look before mergingCatching up on things after being out sick: this still LGTM. :)
Code change:
The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: <del> Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.  Origin: An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </del> <ins> An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </ins> The ORIGIN frame does not define any flags.  It can contain one or more Origin-Len/Origin pairs.

Related discussion:
text: Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.
Code change:
A related category of attacks use protocol disagreement to exploit vulnerabilities in the server's request parsing logic.  These attacks apply when the HTTP client is trusted by the server, but the post- <del> upgrade data source is not.  If the server software was developed </del> <ins> transition data source is not.  If the server software was developed </ins> under the assumption that some or all of the HTTP request data is not <del> attacker-controlled, optimistic use of HTTP Upgrade can cause this </del> <ins> attacker-controlled, optimistic transmission can cause this </ins> assumption to be violated, exposing vulnerabilities in the server's HTTP request parser. 4. <del> If the server rejects the upgrade, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to an upgrade rejection, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected upgrade. </del> <ins> If the server rejects the transition request, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to a rejected transition, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected transition. </ins> 5.

Related discussion:
text: This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME
Code change:
most Internet flows. Furthermore, many IoT applications do not a have a human in the loop, <del> and therefore can have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </del> <ins> and therefore might have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </ins> 7.5.

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in <del> Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the </del> <ins> Section 7 of I-D.ietf-oauth-selective-disclosure-jwt) against the </ins> JSON Schema document provided by the or

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.
Code change:
property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in <del> Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the </del> <ins> Section 7 of I-D.ietf-oauth-selective-disclosure-jwt) against the </ins> JSON Schema document provided by the or

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in <del> Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the </del> <ins> Section 7 of I-D.ietf-oauth-selective-disclosure-jwt) against the </ins> JSON Schema document provided by the or

Related discussion:
text: and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: for and based largely on text suggested on list by Neil Madden
from this thread URL Neil Madden has suggested the following for "Choice of a Hash Algorithm" section. I think (with maybe some minor tweaks) the text works and it would also address issue .
Saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. resulting from this thread URL / URL etc "... indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms."
How to actually write this in an appropriate way for a draft RFC feels kinda tricky though. JWE has some text about using that I was hopping to borrow from but the context is (unsurprisingly) different enough that using text straight from it doesn't quite work. Maybe adding a very general statement in would be sufficient.
At IETF 118 Tuesday meeting, Orie proposed locking the hash to the one committed to by the Issuer. Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use.
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: URL signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”. current venue. And as the end of the draft’s intro states, “this specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms” which is why a regular old secure hash function is being used - SHA-256 specifically and as the default, which I believe is completely suitable for the purpose. It seems like some tightening up or changes around the approach provided for hash algorithm agility might be in order. But I think the overall salted hash based approach is okay/appropriate/sufficient. “inclusion in the [...] registry alone does not indicate a hash algorithm's suitability for use in SD-JWT” after attempting to describe what makes a hash algorithm suitable for use with SD-JWT. We wanted to allow for some hash algorithm agility but really didn’t want to create yet another hash algorithm registry. That "Named Information Hash Algorithm Registry" isn’t an ideal fit but was the best one we were able to find. Pointing to that registry and having the associated security considerations seemed like a reasonably reasonable approach. originally) and I’m very reluctant to make any such statements that venture into legal territory. model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation.
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: Also had to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change? hard-wired set of claims/constraints enforced/required by verifiers is appropriate and necessary even when selective disclosure isn’t at play. It’s how regular JWT works (or should work) in practice already. And don’t think it harms future evolution because any new security constraints would necessarily need updates all around because they won’t be understood otherwise. The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”. And I know some have expressed the need/desire to have key/holder binding type claims (such as “cnf” but not only that) be made selectively disclosable for privacy reasons. I also don’t think a new registry would really help the situation. At this level we're describing a generic mechanism and don’t necessarily even have a list of all claims that could be interpreted as constraints in a particular context or application. Note, for example though, that URL does say that certain claims must be included directly and not made selectively disclosable. Which leads back to ultimately needing that requirement that Verifiers ensure that all the claims they deem necessary are present (in the clear or disclosed) when checking the validity and accepting the token. It’s not meant to preclude that kind of thing (and reading it again, I don’t think it does preclude it). But rather to just say that whatever the Verifier’s requirements on key binding are have to be based on its policy and not on the content of the token (some of which could be manipulated by the holder). A Verifier’s policy could, as you describe, afford different levels of access based on different security characteristics of the presented token/credential. Or the Verifier’s requirements could, for example, say that for credential type A, Key Binding is always required, while for credentials of type B, it is only required when the credential was issued by an issuer that is known to issue credentials supporting Key Binding.