jiebi/CodeConvo huggingface dataset:
Code change:
4.3.1. An attacker obtains a smart TV and attempts to access an online <del> streaming service.  The smart TV obtains a QR code from the authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </del> <ins> streaming service.  The smart TV obtains a QR code from the streaming service authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </ins> streaming service wants to thank them for their loyal support and by scanning the QR code, they will be able to add a bonus device to their account for no charge.  One of the recipients open the e-mail

Related discussion:
text: Addresses feedback in issue NAME
Feedback from Dean Saxe on WGLC Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. URL
Adressed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
Code change:
4.3.1. An attacker obtains a smart TV and attempts to access an online <del> streaming service.  The smart TV obtains a QR code from the authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </del> <ins> streaming service.  The smart TV obtains a QR code from the streaming service authorization server and displays it on screen.  The attacker copies the QR code and embeds it in an e-mail that is sent to a large number of recipients.  The e-mail contains a message stating that the </ins> streaming service wants to thank them for their loyal support and by scanning the QR code, they will be able to add a bonus device to their account for no charge.  One of the recipients open the e-mail

Related discussion:
text: Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes
Code change:
Abstract <del> Abstract Text </del> <ins> This document describes a tree algorithm for COSE Signed Merkle Tree Proofs specifically designed for implementations that rely on Trusted Execution Environments (TEEs) to make the tree more tamper-resistant. </ins> 1. <del> Introduction Text </del> <ins> The Concise Encoding of Signed Merkle Tree Proofs (CoMeTre) I- D.steele-cose-merkle-tree-proofs defines a standard format for carrying COSE-encoded Merkle Tree proofs and the associated signed root value.  This is helpful to pove to a verifier that a given serializable element is recorded at a given index in the Merkle Tree, or to prove that a tree is an extension of another. In this document, we describe how to verify such CoMeTre proofs for a new type of trees associated with the Confidential Consortium Framework (CCF).  Compared to RFC9162, the leaves of CCF trees carry additional opaque infomation that is used to verify that elements are only written by the Trusted Execution Environment, which addresses the persistance of committed transactions that happen between new signatures of the Merkle Tree root. </ins> 1.1.

Related discussion:
text: Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged
Code change:
as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of <del> RFC5234, including the VCHAR, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </del> <ins> RFC5234, including the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </ins> This document uses algorithms to specify parsing and serialisation behaviours, and ABNF to illustrate expected syntax.

Related discussion:
text: Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!
Code change:
all three tactics, to measure the network path and try to optimize its operating point. <del> BBR's state machine uses two control mechanisms.  Primarily, it uses the pacing_gain (see the "Pacing Rate" section), which controls how fast packets are sent relative to BBR.bw.  A pacing_gain > 1 decreases inter-packet time and increases inflight.  A pacing_gain < 1 has the opposite effect, increasing inter-packet time and while aiming to decrease inflight.  Second, if the state machine needs to quickly reduce inflight to a particular absolute value, it uses the cwnd. </del> <ins> BBR's state machine uses two control mechanisms: the pacing_gain and the cwnd.  Primarily, it uses the pacing_gain (see the "Pacing Rate" section), which controls how fast packets are sent relative to BBR.bw.  A pacing_gain > 1 decreases inter-packet time and increases inflight.  A pacing_gain < 1 has the opposite effect, increasing inter-packet time and while aiming to decrease inflight.  The cwnd is sufficiently larger than the BDP to allow the higher pacing gain to accumulate more packets in flight.  Only if the state machine needs to quickly reduce inflight to a particular absolute value, it uses the cwnd. </ins> 4.2.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
only because the header field is defined as end-to-end rather than hop-by-hop. <del> It should also be noted that the use of a header field carrying a textual value makes the prioritization scheme extensible; see the discussion below. </del> 15. RFC7540 stream prioritization relies on dependencies.  Considerations

Related discussion:
text: Addresses Eb, Ec, Ed of This cuts some text to reduce the waffle factor ;)
This is nice condensation.
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: PR updated, PTAL
This came out of discussion on When a relay receives an SUBSCRIBE it may need to issue its own SUBSCRIBE to a publisher that has previously ANNOUNCE'd a namespace matching that track. The current draft doesn't specify how this match is done. A relay could implement an exact match on Track Namespace (requires a tweak to SUBSCRIBE), or could do a longest prefix match on track name vs all ANNOUNCE'd namespaces, or possibly something else. Is it ok to leave this up to implementations or should the draft specify this behavior more exactly? If more than one matching type is allowed, does it need to be negotiated, and by whom (publisher, subscriber, or both)?
An issue that came up in interop that is somewhat related - NAME relay was implemented to take the namespace from the connect URL, because in his use-case, ANNOUNCE can be made redundant with the connect URL (eg it contains a namespace and enough auth). However, this caused an interop problem because my chat application assumes a certain functionality from relays, and that includes supporting ANNOUNCE messages to determine routing to publishers. Do we need to be more prescriptive about relay behavior?
ANNOUNCE is what my implementation expects as well. A producer can announce track namespaces at any point (after being connected). Overloading connect URL with track info is limiting
This is going to be a slightly long comment but this is how I think this should work. The catalog has two fields for the track namespace , and track name. We also specify in the catalog a way to form a URL from these two fields. See Teds proposal and that is catalog specific. The things we put in these track namespaces and track name fields are already canonicalized in a way defined by the catalog and URL. When the application using the moq transport puts these two fields into message, they are treated as just a bunch of bits and any comparison of them is done with bitwise compare. A relay that needs to check if a namespace matches another does not need to worry about string prep or escape encoding of the bits, the will all have been done when the catalog was formed. This allows the relays to work faster by just doing bitwise compare yet at the same time allows us to use URI at the application level. The transport draft just needs to deal with a bag of bits.
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: The catalog draft pushes the work to the URL definition, and the URL definition does the heavy lifting but that is where this type of stuff should be
NAME Just to clarify that when you say "bitwise compare" you also mean exact matching the entire namespace field from announce to the one in subscribe?
I would like to decouple the media layer from the transport layer. A tool like ffmpeg should be able to generate a MoQ catalog without knowing the namespace it will be served from, much like a tool like zip should be able to generate a file without knowing the path it will be stored. HLS/DASH provides this functionality with absolute or relative paths. If the playlist contains relative paths, then it can be served from any HTTP host/path provided the segments are served from the same host/path. If you want to decouple the two (ex. application serves playlist, CDN serves segments), then you use absolute URLs. To accomplish the same thing, the namespace should be optional in a MoQ catalog. This would mean media tracks are served from the same namespace as the catalog: whatever that might be.
To expand further, I think that MoQ broadcasts should be namespace agnostic: a broadcast ingested with namespace XXX is NOT required to be delivered as XXX. I understand where Cullen is coming from: an application like WebEx can use the same namespace for contribution/distribution because it controls the full pipeline. The application has all of the information required for all future routing/identification so it can set it on the first hop and expect any relays to blindly proxy. However, for a more generic or distributed system, this is not true. A client like OBS knows nothing about how the broadcast will eventually be distributed, fanned out, or the requirements of potentially multiple CDNs that might be used, nor will those requirements be the same between vendors (present or future). So I don't think we should require that input namespace == output namespace. In the HTTP world, this would be like requiring that all HTTP paths match the origin. It's quite restrictive and just means a CDN needs find another way to perform routing via a custom header/parameter. I propose we emulate the HTTP model where there's non in-band notification that a path/namespace was modified. An origin might serve and a CDN might decide to serve it as .
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: Any namespace remapping from XXX -> YYY is business logic and not signaled over the wire. If you don't want any remapping, then that's a business agreement between you and the CDN, wherein you may need to encode namespaces in a vendor-specific way.
I think we have agreement on that from past discussions. Can the catalog draft have a mechanism to inherit the namespace for tracks from somewhere else, like a relative URL in an HTML page? I'm not sure this is relevant for how relays perform matching between SUBSCRIBE and ANNOUNCE though. The only available information in announce is the namespace.
Yeah I'm probably rambling about something unrelated. But in order to support namespace remapping, the downstream ANNOUCE/SUBSCRIBE won't necessarily match the upstream ANNOUCE/SUBSCRIBE.
This is a useful property. I opened to address this issue and PR URL to fix it.
So if the input full track name does not equal output full track name ( for some version of matching the two ), what is it that tells the relays there is mapping between the two. I'm not objecting to some other way to do this, I just don't understand what it is that tells the relays to do that. Keep in mind relays do not need to read the catalog.
To clarify the "bitwise compare" ... yes I mean exact matching the entire namespace field from announce to the one in subscribe? If the namespace was utf-8 or even a url restricted utf-8, that would match. I am just aruging that a relay should not have to verify every string is a valid utf-8 string, it should just match the bits.
HTTP proxies will not modify the path by default. A downstream request for arrives, there's some rules to match it to a backend, and then an upstream request for is sent. A simple MoQ relay would work the same way. However, you can configure a HTTP proxy to perform special behavior, including rewriting the path. Note that a the HTTP server does rewrite the HLS/DASH playlist provided they are using relative URLs since both the playlist and segment would match the same prefix rules. For example, here's a simple nginx configuration: I would allow the same exact thing for MoQ, but of course use our terminology instead. I think a key improvement with MoQ over HTTP is actually the namespace/name tuple.
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: I propose: A relay SHOULD NOT change the track name. That means a producer can make a track called "video_480p" and reference it in a catalog, inheriting the current namespace. A relay MAY change the track namespace when negotiated out-of-band. It's RECOMMENDED that an application support being served from arbitrary namespaces, including using relative namespaces when tracks reference each other. Basically, the track name is controlled by the application (encoder/decoder) while the track namespace is controlled by the relay (hop-by-hop). This makes a ton of sense if the namespace is primarily meant for routing (critical for relays), and it allows relays to do stuff like encode the route or a unique ID into the namespace itself.
Going back to the original issue Alan posted (if I understand it correctly), I think we need to support out-of-band negotiation given the nature of fanout. Maybe we can provide something in-band but it won't always be possible. For example, an OBS client sends: In theory, the server could reply with the information required to watch the broadcast (final hop), including any remapping along the way: But this gets really messy when you factor in auth, multiple CDNs, multiple edge hosts, and just the nature of ingest being on the other side of the pipe from distribution. In this example, I think the application has to negotiate with Akamai on how they need to ingest and how they need to egress. I'm not opposed to using extensions to make this mapping explicit though. It would be cool to have a scheme that defines routing/authentication using globally unique namespace, kind of like a decentralized CDN. But it shouldn't be required as part of the base protocol and there's a LOT of sharp edges to figure out.
Individual Comment: My opinion is that anything that does this kind of rewriting is out-of-band, at least for now? For a completely generic relay input=output.
Yes. I opened issue URL to address this and PR URL to fix it. I really like the flexibility that relative names bring. We know this works at scale for current web and media delivery across disparate systems. I'd hope that relative track names are the normal mode of operation. We should allow absolute namespaces in catalogs to allow mixing between sources, however I think this will be an edge case. By default, a relay SHOULD NOT modify the track namespace or track name.
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track

Related discussion:
text: However, what a distribution network does within the bounds of its own network is up to it. As it restores the original namespace and name at its boundaries (to match the catalog), then external systems cannot tell and distribution intent is preserved. Additionally, there will be business logic and distribution agreements between CDNs, coordinated by the content distributor, to rewrite namespaces between networks. Such namespace rewriting is common between networks and should not be prohibited. Here's how I envisage a scalable solution working. When a twitch user wants to use OBS to publish, they would log in to URL and authenticate against the Twitch CMS. It would vend them two URLS: a connect and publish URL a playback URL to share with their followers The OBS client would use this to The client then publishes twitch/kixelated/catalog, a track which describes two relative tracks - audio and video. The playback client connects to URL and subscribes to premiergaming/gamer34/catalog. After parsing the catalog it subscribes to The Fastly relays have been configured by Twitch, out-of--band, so that when they go forward to origin (which is Akamai), they do a namespace rewrite to The subscriptions make their way back to the OBS instance. The encoder prepare Moqt Objects with in their headers. As these are received by Fastly, business logic rewrites them to , caches them as such and they are delivered to the client.
As per the discussions in person, it is more nuanced than renaming few bits in the header. It might break e2e encryption /auth for example or reencryption in some cases. As this is very application specific, one needs to be take into consideration the costs as it may not be just rewrite few bits in and out of network edges. The more appropriate or clearer framing may be - whenever the name changes, it is ,in a way, republishing the content with a new name ..
just to note, the network wouldn't have access to the catalog
Conclusion is that we'll use exact matching like specified in
Thanks for the update I'm not sure how to wordsmith this but +1 to what it is saying.