jiebi/CodeConvo huggingface dataset:
Code change:
If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the <del> origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del> <ins> origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  In those cases, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. </ins> The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.

Related discussion:
text: Our API servers are light-weight and stateless so this is a huge requirement for us. Instead, we would prefer a way simpler approach of always sending back along with responses, but we need to comply with RFC7232 thus this discussion. So, the proposal is to do one of the following (preferred) Remove the following clause from RFC7232: (If aforementioned clause is kept) Explain the reason of not sending in that sub-condition (at least) Change to in that clause.
These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag. Hence, I intend to remove the requirement as being too obscure to implement in a testable way.
Code change:
If the selected representation has a last modification date, the origin server MUST NOT perform the requested method if that date is more recent than the date provided in the field value.  Instead, the <del> origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del> <ins> origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  In those cases, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. </ins> The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
The authorization server issues an access token and optional refresh token, and constructs the response by adding the following parameters <del> to the entity-body of the HTTP response with a 200 (OK) status code: </del> <ins> to the payload of the HTTP response with a 200 (OK) status code: </ins> REQUIRED.  The access token issued by the authorization server.

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
7.4. <del> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </del> <ins> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits. </ins> Note that minimum 128 bits would be necessary when SHA-256, HMAC- SHA256, or a function of similar strength is used, but a smaller salt size might achieve similar level of security if a stronger iterative derivation function is used. <ins> The issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name appear, but each of them has a different salt. </ins> 7.5. For the security of this scheme, the digest derivation algorithm is

Related discussion:
text: Addresses Issue
I also revisited the security recommendations for the salt and made some smaller changes there.
user has 2 SD-JWTs from the same issuer, same blinded claim names can be used to correlate the user. advice to have a fresh blinded claim name for each credential.
Instead of opening a new issue from our conversation this morning - here is the excerpt & suggestion from the document we discussed: First off, maybe it's informational or maybe it's specified - issuers should not include "secrets" in claim labels. If a label for something is actually a secret, it should be treated as such. That said, I get that this scenario must be addressed. Sensitive predicates or graduated disclosure contexts can benefit from this capability. It seems to me that the most useful and easy algorithm to implement is to use the same hash algorithm + salt for the node value to blind the label where: SALTED LABEL = HASHALGO(LABEL + SALT) Of course, this assumes that specific guidance is included for best practice salt generation (fresh entropy gathering for each attribute block salt, sufficient bits of entropy, etc.) for strong cryptographic outcomes. In this representation, the salted hash of the label's value ("name") "9-J2445ap91..." can be addressed directly by the digest "h" value in compact form: Side-note: Informative statements that recommend large sd-jwt claim sets should be 'broken down' into much smaller sets, or individual claims, then wrapped and sealed as a JWP may be better than including too many claims in an sd-jwt.
Right now, it is RECOMMENDED that a random string is chosen for the blinded claim name. HMAC(salt, claim-name) and HASHALGO(LABEL + SALT) would be fine as well, but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar. I don't see a real advantage of using HMAC/HASHALGO for the blinded claim name. I therefore propose to stick with the current recommendation. We should stress that a fresh random value must be chosen for each claim in each issued credential.
Code change:
7.4. <del> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </del> <ins> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits. </ins> Note that minimum 128 bits would be necessary when SHA-256, HMAC- SHA256, or a function of similar strength is used, but a smaller salt size might achieve similar level of security if a stronger iterative derivation function is used. <ins> The issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name appear, but each of them has a different salt. </ins> 7.5. For the security of this scheme, the digest derivation algorithm is

Related discussion:
text: NAME it's not super clear to me how: would alleviate your concerns here: "but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar" Maybe I'm missing something obvious but I don't see much difference in how holders & verifiers would treat these various approaches. They still have to reconcile with the encoding and/or hashing algorithms expressed in the security envelope.
My point was about the selection of the blinded clame name (or 'placeholder claim name' as it is called in the current draft). We have two options on the table: Select a random string as the placeholder Select the placeholder as some function of the original claim name (the label in your proposal) and the salt What I wanted to express is that I think option 1 is better. From a security perspective, both are equivalent. There is no need to choose the placeholder claim name in a particular way, we just need to ensure that it does not leak information about the original claim name. Just numbering all placeholder claim names would be fine as well (as long as the numbering does not reveal anything, e.g., the position of the original claim in the list of claims.) But for option 2, I see two drawbacks: We need to explain more, in particular how to assemble the input for the function, similar to the discussion we had about the hidden claim values. For example, we need to define how the original claim name and the salt are concatenated such that there can be no prefix collisions. A verifier receiving an SD-JWT with blinded claim names according to option 2 may be tempted to (needlessly) check that the claim name was created in a particular way by recalculating the hash. If the issuer has made a mistake when calculating the hash or the verifier makes a mistake, this check will fail. Since such a check is not needed, it would be better if we don't set this trap in the first place. I see no advantages of option 2 over option 1, so I propose to go for option 1.
I see, thanks for explaining that. I'm fine with option 1 if the goal is to reduce cognitive complexity for the application developers - it makes sense.
Code change:
7.4. <del> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </del> <ins> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits. </ins> Note that minimum 128 bits would be necessary when SHA-256, HMAC- SHA256, or a function of similar strength is used, but a smaller salt size might achieve similar level of security if a stronger iterative derivation function is used. <ins> The issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name appear, but each of them has a different salt. </ins> 7.5. For the security of this scheme, the digest derivation algorithm is

Related discussion:
text: PR and PR
I agree with these changes, but it really made me think that we need to clarify various options we have introduced how claims in SD-JWT can be represented as it is becoming a bit hard to follow.. issue filed
Code change:
From this state either peer can send a frame with a END_STREAM flag set, which causes the stream to transition into one of the <del> "half closed" states: a client sending a END_STREAM flag causes the stream state to become "half closed (client)"; a server sending a END_STREAM flag causes the stream state to become "half closed (server)". </del> <ins> "half closed" states: an endpoint sending a END_STREAM flag causes the stream state to become "half closed (local)"; an endpoind receiving a END_STREAM flag causes the stream state to become "half closed (remote)". </ins> An endpoint can send RST_STREAM from this state, causing it to transition immediately to "closed".

Related discussion:
text: half closed (client/server) is no longer used. :scheme header MUST include HTTP Request
NAME The fixes of the commit of 73dce91fcccecce7079d7ccf6294e80350d5ce19 were somehow lost after ea5abcf90460dc300b94eb27d82162f56a1dc526 . I'm not sure why it happened without conflicting. Please fix them by your hand.
Will do. It's easy enough to fix.
Code change:
the distributed identifier of the Issuer (or its resolved key manifest), <del> the expected name of the Artifact (i.e., the Feed), </del> <ins> the expected name of the Artifact (i.e., the Subject), </ins> the list of service identities of trusted Transparency Services.

Related discussion:
text: PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report. The current definition likely needs to expand a bit to account for: What are the versions of a specific artifact What are all the statements for a version of an artifact What is the latest statement for a specific of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.
This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.
NAME I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it? Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.
Code change:
the distributed identifier of the Issuer (or its resolved key manifest), <del> the expected name of the Artifact (i.e., the Feed), </del> <ins> the expected name of the Artifact (i.e., the Subject), </ins> the list of service identities of trusted Transparency Services.

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
such a connection by the use of the "PRI" method in the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST <del> use TLSALPN. </del> <ins> use TLS-ALPN. </ins> Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections.  It is possible for

Related discussion:
text: Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.
Code change:
9.2.2. A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher <del> suites that are listed in BadCipherSuites. </del> <ins> suites that are listed in the BadCipherSuites. </ins> Endpoints MAY choose to generate a ConnectionErrorHandler of type <del> if one of the prohibited cipher suites are negotiated.  A deployment that chooses to use a prohibited cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </del> <ins> if one of the cipher suites from the black list are negotiated.  A deployment that chooses to use a black-listed cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </ins> Implementations MUST NOT generate this error in reaction to the <del> negotiation of a cipher suite that is not in the prohibited list. Consequently, when clients offer a cipher suite that is not prohibited, they have to be prepared to use that cipher suite with </del> <ins> negotiation of a cipher suite that is not on the black list. Consequently, when clients offer a cipher suite that is not on the black list, they have to be prepared to use that cipher suite with </ins> HTTP/2. <del> The effect of prohibiting these cipher suites is that TLS 1.2 deployments could have non-intersecting sets of available cipher suites, since the prohibited set includes the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </del> <ins> The black list includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non- intersecting sets of permitted cipher suites.  To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </ins> Note that clients might advertise support of cipher suites that are <del> prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2 and support only prohibited cipher suites.  This allows servers to select HTTP/1.1 with a cipher suite that is prohibited for HTTP/2.  However, this can result in HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. </del> <ins> on the black list in order to allow for connection to servers that do not support HTTP/2.  This allows servers to select HTTP/1.1 with a cipher suite that is on the HTTP/2 black list.  However, this can result in HTTP/2 being negotiated with a black-listed cipher suite if the application protocol and cipher suite are independently selected. </ins> 10.

Related discussion:
text: Kathleen Moriarty's IESG review noted some confusion that I think derived from the use of the word "prohibited" in relation to the cipher suite black list.
Code change:
. <del> Subsequent to the challenge in age-challenge, a client might direct the user agent to the following example authorization request URI where the </del> <ins> After the challenge in age-challenge, a client might direct the user agent to the following example authorization request URI where the </ins> parameter indicates to the authorization server that the user authentication event needs to have occurred no more than five seconds

Related discussion:
text: updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL