jiebi/CodeConvo huggingface dataset:
Code change:
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The SETTINGS frame is also used to acknowledge the <del> receipt of those parameters.  Individually, a SETTINGS parameter can also be referred to as a "setting". </del> <ins> receipt of those settings.  Individually, a configuration parameter from a SETTINGS frame is referred to as a "setting". </ins> <del> SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same parameter can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </del> <ins> Settings are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same setting can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </ins> A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection.  Implementations MUST support all of <del> the parameters defined by this specification. </del> <ins> the settings defined by this specification. </ins> Each parameter in a SETTINGS frame replaces any existing value for <del> that parameter.  Parameters are processed in the order in which they </del> <ins> that parameter.  Settings are processed in the order in which they </ins> appear, and a receiver of a SETTINGS frame does not need to maintain <del> any state other than the current value of its parameters.  Therefore, </del> <ins> any state other than the current value of each setting.  Therefore, </ins> the value of a SETTINGS parameter is the last value that is seen by a receiver. <del> SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: </del> <ins> SETTINGS frames are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the ACK flag: </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0).  If an

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
status code is similar to , but it indicates that the client needs to authenticate itself in <del> order to use a proxy.  The proxy MUST send a </del> <ins> order to use a proxy for this request.  The proxy MUST send a </ins> header field (field.proxy-authenticate) containing a challenge <del> applicable to that proxy for the target resource.  The client MAY repeat the request with a new or replaced </del> <ins> applicable to that proxy for the request.  The client MAY repeat the request with a new or replaced </ins> header field (field.proxy-authorization).

Related discussion:
text: P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .
Code change:
for making security decisions about the identity of a resource accessed through the proxy. <del> 4. </del> <ins> 5. </ins> This document registers the "next-hop-aliases" parameter in the "HTTP Proxy-Status Parameters" registry <<https://www.iana.org/assignments/

Related discussion:
text: I think the alias draft should probably have a (non-normative) reference to , in particular noting that: can be populated from the output of . can be used to emulate or substitute for .
I think the flag to only gives you the "canonical name" which is the final CNAME target at the end of the CNAME chain. If you want the full set of interior names across a chain of multiple CNAME records I don't believe you can retrieve that with .
Yeah, I'm hesitant to add references to system APIs like , and particularly for the reason given above. NAME what do you think?
I think AI_CANONNAME is important historical context here. You can't understand where the draft is coming from without it. I also think that this extension will often be implemented by wrapping getaddrinfo, and some guidance about whether that is compliant would be appropriate. I think Robert's comment raises a good example of why this is not trivial, and hence is worth mentioning.
I'm not sure is really required to understand the context of the draft. We don't use it at all on iOS/macOS implementations for current CNAME cloaking detection. I do see that it may be good to warn that it is not sufficient to just wrap up .
Thanks LGTM
Code change:
6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the

Related discussion:
text: This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!
Code change:
6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the

Related discussion:
text: Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above.
Code change:
6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the

Related discussion:
text: (we can discuss whether URI scheme is a good solution in general but this is a separate topic and whether we should not limit to be a URI)
NAME at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain
I think there is nothing wrong with: using an HTTPS URI for the value hosting a well-known for that URI including a header with a URI SAN entry that matches the iss value adding to the header In that case, using the to indicate whether well-known is supported or not would not work because like NAME mentioned, apparently OpenID federation uses as well and I believe in that case, well-known is not required. Please correct me if I'm wrong. NAME Can you explain how OpenID federation resolves the ?
To be clear, the above is valid. To be clear, the above just means that using to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a .
NAME sure, thank you for asking imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor. the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies. once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on). using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata
the resolution of the kid is interesting we may have a discovery, using well known endpoints we may have a static trust chain, provided like a x.509 certificate chain
NAME To be even more clear, they might not host a SD-JWT VC Issuer Metadata well-known endpoint but they might host an OpenID Federation well-known endpoint.
Code change:
6.3. <del> A type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.4. 6.4.1. </del> <ins> 6.3.1. </ins> A URI in the

Related discussion:
text: Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.
Code change:
The Transaction Token Service MAY provide additional processing and verification that is outside the scope of this specification. <del> 7.3. </del> <ins> 7.4. </ins> A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token

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

Related discussion:
text: Just editorial suggestions here, but all good ones.
Nice wording, I really like this new version. Thanks!
Code change:
6.2. When defining ecosystem-specific rules for the verification of the <del> public key, as outlined in public-key-discovery-for-issuer-signed- jwts, it is critical that those rules maintain the integrity of the relationship between the </del> <ins> public key, as outlined in issuer-signed-jwt-verification-key- validation, it is critical that those rules maintain the integrity of the relationship between the </ins> value within the Issuer-signed JWT and the public keys of the Issuer.

Related discussion:
text: This PR introduces the following changes: - - Fixed SAN Extension rule Removed all options for X509 except
NAME pls review again.
Fixed merge conflicts and reconciled with PR . Nothing new should have been introduced than what has been approved already. If NAME or NAME can approve again, then we can merge imo.
The section should be renamed to "Issuer-signed JWT verification key validation" since the section is about checking that the value corresponds to the key that signed the JWT. The process of obtaining it via different means is just the first step. We should also fix the language in the "Verification and Processing" section to say: instead of
Fixed by
The rules to obtain the verification key from X.509 should be changed to use the from the SAN extension instead of the (which does not exist). Furthermore, since can potentially start with a https scheme, the JWT Issuer Metadata rule should only be enforced if no x5* JWT header was set.
We also need to add JWT header.
Fixed by
Code change:
5.2. <del> One of the functions of message framing is to assure that messages are . A message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the transport connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport- level error indicates that it is not complete. </del> <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </ins> 5.3.

Related discussion:
text: When I was restructuring Semantics, the paragraphs for defining when a message is complete stuck out like a sore thumb. I moved them to their own section and added a comment for later definition. This issue tracks that definition (editorial).
Code change:
stream zero.  Multiple "CERTIFICATE_NEEDED" frames on any other stream MUST be considered a stream error of type "PROTOCOL_ERROR". <del> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> 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" setting. </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: 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:
1. In HTTP/1.1 (see RFC7230), header fields are not compressed.  As Web <del> pages have grown to include dozens to hundreds of requests, the </del> <ins> pages have grown to require dozens to hundreds of requests, the </ins> redundant header fields in these requests unnecessarily consume bandwidth, measurably increasing latency.

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.