jiebi/CodeConvo huggingface dataset:
Code change:
Generate a Vulnerability Disclosure Report (VDR) listing all the known vulnerabilities and mitigation plans to meet Executive Order <del> 14028 and OMB M-22-18 requirements. </del> <ins> 14028 and OMB M-22-18 requirements with the date the report was generated. </ins> Digitally sign the VDR artifact. <del> Place the VDR and digital signature artifacts within an access- controlled location, i.e., a customer portal, and provide the end consumer with a link to these artifacts for downloading to the customers environment. </del> <ins> Submit the VDR and digital signature to the same SCITT instance, providing a common feed of supply chain information. If the VDR contains critical vulnerabilities, a SCITT claim may be generated, identifying any potential mitigations such as new versions. </ins> 4.2.2.

Related discussion:
text: A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.
Code change:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <del> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run hidden iframe-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </del> 10. This document does not require any IANA actions.

Related discussion:
text: The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.
Code change:
MAY overlap with other objects.  This means timestamps may be interleaved between objects. <del> MAY reference frames in other objects, but only if listed as a dependency. </del> Media objects are encoded using a specified container (containers). 4.2.

Related discussion:
text: It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.
Code change:
authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client <del> Authentication and Auhorization Grants" RFC7521. </del> <ins> Authentication and Authorization Grants" RFC7521. </ins> 2.5.1.

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
11.1.  URIs <del> [1] https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry [2] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </del> <ins> [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </ins> issues/79

Related discussion:
text: Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this
Code change:
Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. <del> 9.2. </del> <ins> 9.3. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity
Code change:
Given a string of Unicode characters as input_string, return an ASCII string suitable for use in an HTTP field value. <ins> If input_string is not a string of Unicode characters, fail parsing. </ins> Let byte_array be the result of applying UTF-8 encoding UTF8 to <del> input_string.  If there is an error in doing so, fail parsing. </del> <ins> input_string. </ins> Let encoded_string be an empty string. For each byte in byte_array: <del> If byte is %x25 ("%"), append "%25" to encoded_string. </del> <ins> If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff: </ins> <del> If byte is in the ranges %x00-1f or %x7f-ff, apply the percent- encoding defined in Section 2.1 of URI to byte and append the result to encoded_string. </del> <ins> Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding (Section 8 of RFC4648) to byte. Append encoded_byte to encoded_string. </ins> Otherwise, decode byte as an ASCII character and append the result to encoded_string. <del> Let formatted_string be the result of running Serialising a String (ser-string) with encoded_string. </del> <ins> Let output be a string containing "%" followed by DQUOTE. </ins> <del> Return the character "%" followed by formatted_string. </del> <ins> Append encoded_string to output. Append DQUOTE to output. Return output. </ins> 4.2.

Related discussion:
text: Looks good except for minor details and potentially a bug (encoding vs decoding). I'd also like to see the spec enforce a consistent form of percent encoding (lower vs upper)
I am sceptical wrt "use the URI percent encoder". The reason being: percent encoding rules depend on what part of the URI needs encoding (and many APIs do not get that) calling the API for a single character multiple times usually requires converting a char to a string, and that might not be good for perf if we really care about that
I've removed the reliance on URI for percent encoding; was clean as NAME said it would be. Regarding case -- NAME RFC4648 Section 8 is explicitly case-insensitive. Given that and the discussion in the group yesterday, I've left this case-insensitive. Say if you still disagree.
NAME , I was suggesting an inline definition. The fact that uppercase is base16 would just be an observation (and not a particularly useful one). Lowercase tends to be the default mode in several places.
NAME it wasn't at all clear that's what you were suggesting. I'll make an attempt.
Looking at it, I think I prefer referring to 4648. This this addresses the original issue, I'll merge; if someone wants to propose an alternate way to specify this, please feel free to open a PR.
As currently defined, the two serialized DisplayStrings %"foo\"bla%22bar" and %"foo%22bla\"bar" are semantically identical. We should either use %-escapes or \-escapes, mixing them this way is asking for smuggling-attacks.
I think probably -escapes; will work up a PR.
I don't believe that relying on a different RFC for the hex encoding makes this much better (so I sort of disagree with Martin's proposal). Just define the escaping exactly inline, and then we can choose upper/lower.
Code change:
replacement Txn-Token except for the "req_wl" claim which MUST be updated to include the requesting workload identifier. <del> 7.4.1. </del> <ins> 7.5.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

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:
implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol <del> extensions; for example, RFC7838.  Likewise, the set of servers that a connection is considered authoritative for can be changed with a </del> <ins> extensions; for example, RFC7838.  Likewise, the set of servers for which a connection is considered authoritative can be changed with a </ins> protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a

Related discussion:
text: Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!
Code change:
implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol <del> extensions; for example, RFC7838.  Likewise, the set of servers that a connection is considered authoritative for can be changed with a </del> <ins> extensions; for example, RFC7838.  Likewise, the set of servers for which a connection is considered authoritative can be changed with a </ins> protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.12. </del> <ins> 6.11. </ins> The receiver sends an ANNOUNCE_ERROR control message for tracks that failed authorization.

Related discussion:
text: Into SUBSCRIBEDONE. I didn't remove the SUBSCRIBEERROR message in favor of SUBSCRIBE_CLOSED as NAME suggested in this PR. Addresses some comments in , but possibly not all
So my notes from this discussion. CLOSE is confusing with QUIC layer. People seemed to prefer UNSUBSCRIBE over SUBSCRIBE_CLOSE. I love the move aware from RST and FIN as naming.
Propose names from my understanding of discussion call Announce (send by publisher) , AnnouceOK, AnnouceError UnAnnounce (send by publisher) UnAnnounceOK, UnAnnounceError AnnouceEnd ( sent by thing that received Annouce) , AnnouceEndOK, AnnouceEndOK Subscribe (send by subscriber) , SubscribeOK, SubscribeError UnSubscribe (send by subscriber) , SubscribeOK, SubscribeError SubscribeEnd (send by thing that received subscriber), SubscribeOK, SubscribeError Mostly trying to get rid of FIN / RST and have different names for the messages that flow in opposite directions.
I don't like the name of the different messages used to terminate. I'd rather have one message that transitions to the terminal state, with an optional error code and final group/object. IMO the subscription flow: And the ANNOUNCE flow mirrors: The brackets mean a message is optional. The sender is responsible for creating and the receiver is responsible for closing, possibly at the bequest of the sender (like QUIC's STOP_SENDING).
has been merged, adding yet another term (CANCEL), but I figured we'd clean that up with this issue.
Since we are bikeshedding, I prefer ANNOUNCE_RESCIND instead of CANCEL, since an announce is more of a declarative statement than an active request from the sender.
Heh and UNANNOUNCE and UNSUBSCRIBE stick out because they don't share the same prefix.
I like the names being proposed as they help make make is easier to understand. I do want to separate out one issue. The STOP / CLOSE type thing happens way after the initial SUBSCRIBE thus it can end up in a situation where auth has expired or something else has gone wrong this I like the current design that allows an OK or ERROR to be returned for those. I think it is also key for sender of the things stoping the subscribe to know that the other side has acted on that so we need the OK.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.12. </del> <ins> 6.11. </ins> The receiver sends an ANNOUNCE_ERROR control message for tracks that failed authorization.

Related discussion:
text: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.12. </del> <ins> 6.11. </ins> The receiver sends an ANNOUNCE_ERROR control message for tracks that failed authorization.

Related discussion:
text: 4) You got everything I have but i'm not sure if that's everything
is somewhat relevant to this issue.
As mentioned in , there are 3 different ways for a publisher to close a subscriber, each with minor differences. : I never sent you an object. : There are no more objects to send after group/object X/Y. : There are more objects after group/object X/Y... but I won't send them. A few things: I think it should be renamed since it's not the only ERROR message. Maybe ? The only difference is that one has an error code. Otherwise they both include a final group/object and it's up to the application/library to decide if they wait for the final object(s). I'd like to only implement this once but right now I have to copy/paste any code to handle these almost identical messages. What if we merged them and use error code 0 to signal a FIN. The reason phrase should be removed as part of . There really needs to be a state machine like with this many ways to terminate a subscription. I think these are all protocol violations: then then then My interpretation of the draft is that a followed by a is invalid, which is not obvious and unlike QUIC. I don't think so. The library/relay behavior doesn't change based on . The only thing that miiiight differentiate between the two is the application, which can use errors codes for this purpose. At the very least I would merge these two messages. But I would also like to explore a single way for the publisher to close a subscription. The application can signal the nuanced differences between errors (ex. error code 404 vs 410). The library/relay doesn't care, it just forwards the error code.
Individual Comment: The inspiration for FIN vs RST in moq came from HTTP caching. If a resource has no content-length, and the caching proxy has received N bytes, does it have the entire resource, or does it need to refetch the tail? If that response was terminated with a FIN (H2 or H3), then it has the whole resource. If it was terminated by a RST, it can't assume that it does. So the value I see in these two messages is for a moq relay is similar.