jiebi/CodeConvo huggingface dataset:
Code change:
by ecosystem rules, application-specific profile, or the credential format and MAY include claims other than those listed herein. <del> 10.9. </del> <ins> 10.8. </ins> This specification does not define how signature verification keys of Issuers are distributed to Verifiers.  However, it is RECOMMENDED

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
2.1. <del> Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences.  The user can be given the choice to enable, disable, or override specific hints. </del> <ins> Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations.  Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions.  Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. </ins> The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for

Related discussion:
text: Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM
Code change:
6.6. <del> A subscriber issues a "UNSUBSCRIBE REQUEST" message to a publisher indicating it is no longer interested in receiving media for the specified track. </del> <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. </ins> <del> The format of "UNSUBSCRIBE REQUEST" is as follows: </del> <ins> The format of "UNSUBSCRIBE" is as follows: </ins> Full Track Name: Identifies the track as defined in (track-name). <del> Track Request Parameters: As defined in track-req-params. </del> 6.7. <del> A "UNSUBSCRIBE OK" control message is sent in response to a successful "UNSUBSCRIBE REQUEST" message. Full Track Name: Identifies the track for which this response is provided. On successfully validating the "UNSUBSCRIBE REQUEST" message, the publisher SHOULD cease delivering objects for the track to the subscriber. 6.8. A publisher sends a "UNSUBSCRIBE ERROR" control message in response to a failed "UNSUBSCRIBE REQUEST" message Full Track Name: Identifies the track in the request message for which this response is provided. Error Code: Identifies an integer error code for the failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for unsubscription error and "Reason Phrase Length" field carries its length. 6.9. </del> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

Related discussion:
text: This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.
Code change:
Service may restrict access to Signed Statements through access control policies.  However, third parties (such as Auditors) would be granted access as needed to attest to the validity of the Artifact, <del> Feed or the entirety of the Transparency Service. </del> <ins> Subject or the entirety of the Transparency Service. </ins> Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,

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:
Service may restrict access to Signed Statements through access control policies.  However, third parties (such as Auditors) would be granted access as needed to attest to the validity of the Artifact, <del> Feed or the entirety of the Transparency Service. </del> <ins> Subject or the entirety of the Transparency Service. </ins> Trust in the Transparency Service itself is supported both by protecting their implementation (using, for instance, replication,

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:
A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware of.  However, once a valid and authenticated commitment has been <del> received, clients SHOULD NOT use an unauthenticated alternative service.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services.  A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </del> <ins> received, clients SHOULD NOT use an alternative service without both reasonable assurances (see auth) and strong authentication.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services. A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </ins> 5.3.

Related discussion:
text: …ng authentication if Erik is cool with it.
NAME
ETIMEDOUT NAME if you object please reopen.
Code change:
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP2 which is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del> <ins> to HTTP/2 HTTP/2 which is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.

Related discussion:
text: NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!
Code change:
service can be used for establishing new connections, not limiting the use of existing ones. <ins> Alternative services are fully authoritative for the origin in question, including the ability to clear or update cached alternative service entries, extend freshness lifetimes, and any other authority the origin server would have. </ins> When alternative services are used to send a client to the most optimal server, a change in network configuration can result in cached values becoming suboptimal.  Therefore, clients

Related discussion:
text: An alternate can send an Alt-Svc field that overrides that sent by the origin and is cached on an equal basis.
Code change:
10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, <del> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Justin Richer, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Add Justin to Acknowledgements (he suggested the array for _sd in sid…e meeting) and fix the commas + and in that list of names
Code change:
prioritization, since the stream could be given a priority that is higher than intended. <del> To avoid these problems, endpoints SHOULD maintain prioritization state for closed streams for a period after streams close. An endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </del> <ins> To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </ins> This could create a large state burden for an endpoint, so this state MAY be limited.  An endpoint MAY apply a fixed upper limit on the

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
6.2. <del> Integrity fields can help detect "representation data" or content </del> <ins> Integrity fields can help detect representation data or content </ins> modification due to implementation errors, undesired "transforming proxies" (see SEMANTICS) or other actions as the data passes across multiple hops or system boundaries.  Even a simple mechanism for end- <del> to-end "representation data" integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </del> <ins> to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could

Related discussion:
text: Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that
Code change:
The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. <del> That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache- Control: no-store). </del> <ins> For example, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This specification does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).  In particular, when an application caches data and does not make this apparent to or easily controllable by the user, it is strongly encouraged to honour basic control mechanisms like Cache-Control: no-store, as they indicate the resource's intent regarding caching. </ins> 7.

Related discussion:
text: It seems to me that cross-page loads are exactly the type of thing that a sender of no-store is trying to avoid. It is the type of flag sent on highly sensitive or volatile data. Images, stylesheets, etc which have cross-page relevance should not be using it.
Code change:
used to satisfy the request.  Proxy configuration is implementation- dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually <del> identified by an "http" or "https" URI.  If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. </del> <ins> identified by an "http" or "https" URI. If an "http" or "https" proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.3.3. If no proxy is applicable, a typical client will invoke a handler <del> routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. </del> <ins> routine (specific to the target URI's scheme) to obtain access to the identified resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. http.origin defines how to obtain access to an "http" resource by establishing (or reusing) an inbound connection to the identified origin server and then sending it an HTTP request message containing a request target that matches the client's target URI. https.origin defines how to obtain access to an "https" resource by establishing (or reusing) an inbound secured connection to an origin server that is authoritative for the identified origin and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.4.

Related discussion:
text: In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.
Code change:
<del> Description: The SHA-256 algorithm FIPS180-3.  The output of this algorithm is encoded using the base64 encoding RFC4648. </del> <ins> Description: The SHA-256 algorithm RFC6234.  The output of this algorithm is encoded using the base64 encoding RFC4648. </ins> <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC6234, RFC4648, this document. </ins> Status: standard <del> Description: The SHA-512 algorithm FIPS180-3.  The output of this algorithm is encoded using the base64 encoding RFC4648. </del> <ins> Description: The SHA-512 algorithm RFC6234.  The output of this algorithm is encoded using the base64 encoding RFC4648. </ins> <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC6234, RFC4648, this document. </ins> Status: standard

Related discussion:
text: Simplifies references to sha algorithms pointing to RFC 6234 instead of FIPS180 documents.
NAME ping :)
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
Code change:
mandatory frame data.  A frame size error in a frame that could alter the state of the entire connection MUST be treated as a ConnectionErrorHandler; this includes any frame carrying a FieldBlock <del> (that is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any frame with a stream identifier of 0. </del> <ins> (that is, HEADERS, PUSH_PROMISE, and CONTINUATION), a SETTINGS frame, and any frame with a stream identifier of 0. </ins> Endpoints are not obligated to use all available space in a frame. Responsiveness can be improved by using frames that are smaller than

Related discussion:
text: : We had trouble parsing this sentence. Is a word missing? If neither suggestion below is correct, please clarify what "any frame carrying ... SETTINGS" refers to. Original: A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION), SETTINGS, and any frame with a stream identifier of 0. Suggestion (... and a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION) and a SETTINGS frame, and any frame with a stream identifier of 0. Suggestion (... or a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSH_PROMISE, and CONTINUATION) or a SETTINGS frame, and any frame with a stream identifier of 0.
Suggestion 1 is correct.
I think that the list structure is supposed to be... includes: any frame carrying a field block (...), a SETTINGS frame, and any frame with a stream identifier of 0. Which suggests option 3, in my PR.
LGTM.