This case seems easily avoidable by a subscriber, so the simplest option is to close the session.
Draft 04 currently doesn't mention about sending any response when the SUBSCRIBE_UPDATE is successful or when it fails even though the draft hints on possible failures The above suggests that an error should be sent to inform the client that it is making invalid subscription updates.
documents some other aspects of SUBSCRIBE_UPDATE that are underspecified.
Table 4 is missing SUBSCRIBEUPDATE, so there's no code for this message type. Section 6.5 doesn't say what to do when the update is malformed, in some way. SUBSCRIBEERROR? Is a bogus SUBSCRIBE_UPDATE ignored, or does it nuke the original subscribe?
One nit, but LGTMLGTM


Small editorial clarification on duplicate track alias for subscriptions that addresses aspects of
As I read the draft, is the distinguisher of a given subscription. is made unique for a subscription state by indicating "If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error." The is mentioned as "A session specific identifier for the track.". It is initially set by the subscriber, where the publisher MAY reject... likely not if it wants to avoid long subscribe times. The draft does not indicate that the track alias is a hash of track or not. If the client implementation uses a sequence ID for both subscribe ID and track alias, then it could result in duplicate subscribes that would result in the relay building state, propagating the subscribe toward the publisher to solicit a response of OK/ERROR. In some implementations that support headless publishers, the relay would send a subscribe OK immediately. The edge relay that has the connection to the publisher performs state compression of subscribes, but that's only at the level per the draft. In this case, the track alias is different, resulting in a new subscribe (duplicate when looking at the ) being created to the publisher. The publisher receives the subscribe with a new and and starts to publish data objects using the and that match internally the track . If one or more clients do this repeatedly, it would result in all relays and the actual publisher itself sending duplicate data that matches . Below diagram illustrates the above. I'm sure there are many reasonable fixes for this... below are a few. This would change the verbiage of duplicate track detection to perform duplication check on and instead of only on track alias. The state machine for subscribe SHOULD change to move from TO . This simplifies the state machine by reducing the complexity in: detection and elimination of duplicate subscribes eliminating the challenges with having to deal with trial and error responses A hash of namespace and name would allow for the duplicate track detection to work per draft, but... Track alias has a max value of 62 bits. Collisions are the largest pitfall for using a hash of two values. Registry/directory service could act as gatekeeper of track aliases. While this would work, it introduces another micro service for a simple pub/sub, which isn't great. It will also slow the subscribe process down. Many other issues will likely arise with this approach.
I don't understand duplicate subscribes issue here ? can you please elaborate .
If a subscriber sends 2 subscriptions for the same track to a publisher ( ignoring relays for a bit here and also ignoring any form if Ids ), what should be the expected behavior of the publisher ? There are few options Publisher sends 2 copies of the objects (wherever they overlap) Publisher rejects the second subscribe since it is in the same connection Publisher sends only 1 copy of the overlapping objects What is in draft today allows for 1.
Clarification on relay vs publisher needs to be distinct here. When discussing this topic, we need to be distinct on is the request for a range of objects (aka fetch operation where there is a start and finish?) or subscribe to live stream where there is no known end? Some of the challenges here are introduced with the MOQT decision to overload to support both fetch operation and subscribe to live stream, possibility starting at X. In the case of fetch operation, subscribes do not get forwarded to original publisher or to other relays, they are instead immediately fulfilled by the first hop relay, which may pull the data from some distributed/localized cache. It is totally acceptable that fetch based subscribes (aka filter type 0x4), can be in duplicate... although I suspect that is a mistake/error on the client side to request at the same time overlapping/exact same data. Regardless, it's not a big deal for the relay to satisfy this repeated request over the same data at the exact same time, but there needs to be some level of rate limits established to mitigate DoS. While MOQT doesn't need to define the limits, it does need to support error responses that the limit has exceeded. In the case of live stream, IMO it's 100% mistake for any client to ask for the same live stream twice via the same QUIC connection. While talking with NAME , he mentioned a possible use-case where there are two or more displays that you want to display the same content to. If the display has IP connectivity, it should be reasonable that the display would have connected and subscribed to the content, hence moot. In the case where the display does not have IP connectivity, a HUB device could be used that does have IP to act as the MOQT client to receive the data content. IMO, it does not make sense that anyone would want duplicate live feeds of the same data via the same QUIC connection. Instead, if the HUB device has multiple displays that are not IP connected and cannot make MOQT connections themselves, they likely have some other method to mirror content, such as an HDMI splitter. I'm interest in hearing the use-cases that require MOQT to directly support and require relays to support duplication of live streams to the same QUIC connection. Per discussion with NAME , the relay peering would never duplicate the live feeds. It would de-dup all these requests using the track , regardless of how many track aliases were used by a client subscribe. The original publisher would realize this aggregation/de-duplication. In other words, each subscribe from the same QUIC connection or from multiple QUIC connections (in theory different clients) would be grouped together by the relay using the . Each of the and values together represent a feed. In this sense, only or is needed for this process, not both when considering live feeds. Again, fetch is different and is distinguished not only by , , but also by start and end ranges. I'm interesting in hearing the use-cases of why MOQT requires of the relay to support duplicate fetch requests for the exact same ranges at the same time when the other hasn't finished yet. Seems like it would make sense that if the same QUIC connection (aka client endpoint) request range X - Y and while still sending X - Y, it requests it again, that it would cancel the previous and start over. Add some text around that endpoint to relay can establish duplicate live streams by using different track aliases for the same namespace/name. The relay or original publisher MAY implement rate limits on the number of active subscribes for the same namespace+name. The relay and/or original publisher may implement different rate limits based on FITLER TYPE. For example, filter type 04 may allow a maximum of 10 active subscribes for the same namespace+name, while filter types less than 4 that involve live stream feeds is restricted to 1.
The status quo of having both needs to be fixed at some point, see
Does this mean we close the complete quic session? Can we just reject the subscribe?


Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM


This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM


This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM


This came up during interop - A relay received a subscribe with start={g=RelativeNext/0 o=Absolute/0}. Since the relay had not received any objects, it defaulted largest to 0 and interpreted the subscribe as starting at {g=1, o=0}. When {g=0,o=0} arrived, it was not forwarded. But there's a reasonable interpretation that it should have forwarded treated this as the beginning of the next subscription. This is partially related to and maybe
If the subscriber wanted to get the largest group, it would have made request start = {g=RelativePrevious/0, o=None} .. This would have the interpretation that subscribe starts at {g=0, o=0} when {g=0, o=0} arrives. This would also work when {g=0, o=22} arrives. If my understanding of locations is correct, then the original request of {g=RelativeNext/0 o=Absolute/0} is incorrect for the answer being expected ..
I think it's reasonable to return 0,0 The subscriber uses RelativeNext if it doesn't want old data. If no data has been generated, then that requirement is still met.
But that's ambiguous. Since Group and Object IDs are zero-based, that response also describes the situation in which the relay has received the first object from the first group, which is clearly a different state. Can we solve this problem by specifying that both GroupID and Object ID are >= 1 of they exist, and 0 if they do not? This can be used to describe the situation in which the subscription is active but the publisher has not yet produced any objects.
Oh to clarify, the SUBSCRIBE_OK should return None/None as the latest group/object. The first OBJECT delivered would be 0/0. And yeah we could switch object/group to be 1-indexed instead of 0-indexed. None=0
Individual Comment: Agreed that in this particular case, the client was not really asking for what they wanted. The "Largest group/object" language comes from the draft, though, and I think it's ambiguous what it means to a relay that hasn't seen any objects. My interpretation of the spirit of the draft is that 0/0 would be forwarded in this case if the client asked to start Next/0 (eg: there's a bug in my relay), but if so, we should make it clear in the draft how it's supposed to work.
Is this
I think I can see the intent with what's there, but the draft could use some editorial text clarifying what "next/0" means when subscribe OK was "no content available".
I thought we decided on call that we were not going to steal bits from the group id / object id to indicate meta data what is going on. After that call I was expecting to see some explicit flag for "no content available" if that is what needed to be sent.
After merging , Subscribe OK has the flag you are referring to: https://moq-URL I left this issue open because I think there's still some ambiguity that can be resolved with editorial text.
makes sense - thanks
NAME can you write some editorial text to clarify this if you have something in mind?
I tried to write some text, but I got confused. Ignoring object locations for a second and just focusing on groups, I think this is what we want, but I'm unsure how to define "current" when there are no objects: I think the simplest way to resolve this is to treat the next seen group ID as the "next" one and anything attempting to match only "current" matches either a) nothing or b) . I recognize that b) may be controversial in that we don't require unitary increase in group IDs. Practically I think subscribers should usually ask for [RelativePrev/0, None] (give me the current group if you know it or the next seen group if you don't). If we assume that the publisher only says "ContentExists: false" when it hasn't published anything, and relays only repeat this when they get it from publishers, then it's somewhat easier to assume that anything before "next" simply doesn't exist. I'm unsure if this covers publisher restart cases well enough though. There's also an asymmetry in this case in that there's no message to communicate how the relative requests were interpreted, as SUBSCRIBE_OK now does when the largest object is known. Further, the algorithm for how to interpret relative object locations in groups with an unknown "largest object" may be even murkier, but let's agree what the groups mean and then move on to objects.
Now that is merged I think I can make a PR to address the concern. I think it would be something like:
LGTM


Some diffs are due to me reflowing text to fit the line limits, so please ignore those. Once we have this and a limit on announce IDs, it seems likely that we'll be able to get rid of 'Role', but for now it can stay.
Thanks NAME . this looks like a good improvement. I have few clarification questions and bit of extra work for you to add some informative text, if my comment seems ok to you.
Unfortunately, that makes it much more difficult for the server to tell abusive clients from valid ones, as we discovered with the recent HTTP/2 rapid reset attacks. In the end we did develop heuristics, but they're imperfect and in the process we broke a bunch of applications in an effort to defend against DDoS attacks. In contrast, QUIC had a system like this and experienced no issues and we didn't need to develop any new heuristics.
Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit. The simplest idea would be to have a limit specified as a parameter in the server's SETUP message. As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?
rofl I just came here to post the same issue. See: URL I think we follow QUIC and have a MAXSUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends or (TODO). I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.
Also do we need ? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.
A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: Announces also likely need some limits, but I'm less clear on how that might work.
I propose a monotonically increasing in the message. You can't reuse Subscribe IDs. We add a message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value. The corresponding messages use that ID instead of echoing the full track name. This removes ambiguity and overhead. We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example: Same for .
Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.
This is related to
may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..
As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAXSUBSCRIBEID frame to increase the limit, similar to QUIC flow control.
The consensus at the session today was to go with a QUIC style approach, so I wrote There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.
Will assign to Mike English
This seems like a really complicated way to limit the subscribes. I understand how it mirror streams but that had pretty different constrains. Why don't we just have an subscribe error of "too many subscriptions"? Discussed open issues in the 7 August 2024 virtual, not recorded here. Remaining issue (just do a SUBSCRIBE_ERROR?) went to the list and chairs declared rough consensus, although at least 2 participants would prefer not to have this.


There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM


I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments


I removed this sentence: Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header. We already have text explaining that the object payload content can be encrypted (section 2.1). I think that makes it clear that a relay can't do anything with the object payload unless it has the encryption keys or a priori knowledge they are cleartext. The sentence itself was overly restrictive (relays could use other inputs, for example out of band information from configuration or business relationships). The preceding sentence explains how to find subscribers to this track, the subsequent one says "MUST forward", and we have an entire section explaining what to do with priority order now.
Line 572. “[Relays] MUST only depend on the fields [for making forwarding decisions]”. I am not sure to understand why we would like to restrict here the behavior of Relays to forward the Objects to subscribers. We can imagine edge processing for the implementation of forwarding decisions based on third-party validation (possibly based on payload). Furthermore, this restriction is not necessary for the norm to be implemented.
The intent of the language here was that relays should only depend on being able to access the headers and not the body of the objects, as the body may be encrypted. However someone may want to build a relay that uses 3rd party logic , or that inspects the payload, in order to make forwarding decisions. I agree that this should not be prohibited by the protocol. We should relax the language to indicate that payloads MAY be encrypted and that relays MUST implement any prioritization instructions carried in the headers. The spec should make no normative statements about how relays make forwarding decisions.
I agree that this is too restrictive and yet unenforceable. The intent is to say something like "a router MUST only forward packets based on the IP header". But what about the UDP/TCP header? What about the TLS header? What about the HTTP header? It's perfectly valid to use those iff a router supports those layers (aka a load balancer). I mentioned in the other issue, but we should treat moq-transport as just a layer. There may be other layers stacked on top and which should not be restricted. It's L3/L4/L7 all over again.
I am always confused when we use the term Relay to mean more than one thing. My thinking so far is, these are the middleboxes who have no role with payload of the MOQ objects. Yes, it cannot be enforced and a implementation can do whatever it wants. However, when we define security properties, we need to be clear on Relay's role. OTOH middleboxes like SFUs, transcoders are more flexible to access payload and may be payload headers based on the architecture and they fall into different category when defining the security of the system.
This is marked not-transport, but the issue was filed against text in moqt, so maybe that's not correct.


This language exists in current draft and refers to an old scheme in which MOQT registered the streaming formats and had a scheme in which the leading varint of the catalog defined the format. This has been superseded by an externalized catalog format and this TODO should be removed. The IANA table for MOQ streaming formats should be managed instead by the Catalog draft, which references those entries.


As I observed in this comment: URL, the missing group status seems equivalent to "End of Group" with ObjectId of 0. Additionally, there is no obvious value for ObjectId in Objects with a status of "Group Missing".
makes sense to me


It's meant to be sent by the subscriber, indicating that the announce is no longer accepted. The fields should mirror ANNOUNCE_ERROR so the subscriber can indicate stuff like authentication expired, another announce was received, etc.
LG, but I noticed: "If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCECANCEL, it SHOULD close the session as a 'Protocol Violation'." I believe that's racy, because the SUBSCRIBE and ANNOUNCECANCEL can be inflight at the same time? Also, shouldn't it be "after sending an ANNOUNCE_CANCEL", or am I misunderstanding the text?lgtm


Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?


Sorry for the late response but I dont think this text is quite correct. If you're running MoQ over WebTransport, you're likely to be following the instructions in URL, which states My reading of the current text means that endpoints are likely to blend up treating things as a violation when there is no violation.
Section 3.3 says: "The control stream MUST NOT be abruptly closed at the underlying transport layer. Doing so results in the session being closed as a 'Protocol Violation'." I know we have multiple transports, but it would be good to clarify what an abrupt close is. Presumably any sort of RESET_STREAM, but what happens if there's a FIN? Is this a "clean close" of the session? Does it imply or force a reset of data streams?
LGTM


My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM


This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.


On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.


Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.


This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.


We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.


The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.


As I was reading through the draft, I found some slight typos in the publisher interactions segment. This fixes them!


As of now, we use Subscribe ID for operations on a subscriber, and Track Alias for operations on objects. In , there was an effort to remove referencing subscribe id within object header types, but one slipped through. This fixes that.


This is an attempt at clarifying MAXSUBSCRIBEID, feel free to make suggestions.
lgtm
In 6.16 of draft 6, the draft says that "receipt of a MAXSUBSCRIBEID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'." ; however, later the section mentions that "If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'." This is can be ambiguous because technically MAXSUBSCRIBEID is any message. Should all sessions be closed if MAXSUBSCRIBEID message contains an invalid Subscribe ID value? Does any message exclude MAXSUBSCRIBEID if an invalid Subscribe ID value is provided? Clarification on this would be helpful. Thank you!
lgtmAgree with Alan's comment. Otherwise LGTM


(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM


How big can a group be? I know we (probably) won't be able to set a fixed limit, but I feel like we need to answer this in order to know what kind of design assumptions to make. Is a single group expected to be small enough to fit in the cache? Will the protocol work if a media track is just a single group that is being appended to for hours if not days? I was thinking about stream mapping and the resource-use-at-relays problem earlier today, and realized we might not currently have a conclusive answer for those.
As it stands today, the group ID is merely an annotation used by SUBSCRIBE hints. It's a sync point only by convention; in actuality the relay has no idea if objects within a group depend on each other. The relay is expected to cache/serve/evict objects independently so the group size is irrelevant. For example, a valid use-case is a single audio group with an object per frame. Each OBJECT would have an expires field of 30s, effectively dropping the head of the group as time progresses. The total number of objects per group is unbounded but the cache size is bounded. I strongly disagree with this. I want groups to actually be sync points, in which a relay knows that it should not evict OBJECT N without also evicting OBJECT N+1. Then the maximum size of the group actually matters.
IMO the size of a group (in bytes, or object count, or wallclock duration) should not be defined by the moq-transport spec. Limits such as these are driven by the physical characteristics of the caches and therefore should be provided by the relay (cache) provider. A streaming format (such as WARP) may choose to define a minimum object size to be supported for interop reasons between relays, but this should probably stay outside of moq-transport.
+1 to will's point. Group Size vary depending on the application - video, audio, chat, something new If any application needs to be aware of this, we can do the following Have catalog specify the group size per track Have a MOQT message updated where the Publisher can specify it per track in Subscribe OK. This might help as hint to caches if need be.
Individual Comment: There may be something interesting for moqt here in expressing more information that's useful to a cache. Maybe an explicit expiry time would be more useful than a TTL, or a TTL at the group rather than the object level? Caches will evict stuff and can go fetch it if someone asks for it later. Maybe what needs to be specified is what happens when a cache receives Objects 0-10, evicts 0-3, then gets a SUBSCRIBE for Absolute/0-10?
Yeah, the cache needs some dependency information if it has any hope of evicting objects before the maximum TTL. That should be the purpose of group in my opinion.
I think we should allow it to be pretty much any size and as we use a VarInt for the object id so it does not matter. I guese I am not seeing a problem here from what we have today with pretty much no limit on number of of objects or number of groups. So I guess I am saying whatever max of VarInt is which I assume will be at least 2^60.
NAME are you fine with NAME point? If so, please close the issue.
I think we should add a note that groups can be in practice arbitrarily big.


Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good


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.


This error code can be sent by a publisher to a subscriber that is not consuming data fast enough, causing a queue to form at the publisher that exceeds the publisher's limits.
I added text here on when to send Too Far Behind that attempts to clarify the fidelity of subscribe. It ended up in the delivery timeout section, which may not be where it belongs, but we don't have a generic section that explains how subscriptions work, it's spread amongst the relay section, SUBSCRIBE message and Delivery Timeout.
During the interim last week, there seemed to be consensus that SUBSCRIBE's default behavior is a high-fidelity mode (eg all new objects will get to all subscribers, with the exception of DATAGRAM tracks). Based on the FETCH discussion - the status of a cache on any relay in the chain has no impact on new object fidelity. The only parameter that can affect this is the subscriber's , which opt-in. The only other issue to address is - a subscriber falls too far behind live head to sustain the subscription based on sender resource constraints. I recommend we add an error code to such as , include the final queued object ID, and remove the subscriber from the forwarding table so no new data is queued for them. When those objects are delivered, the subscriber can FETCH later objects and/or resubscribe as needed.
I do not think this was the consensus. It has been very clear that one of the main use case for sub groups was temporal scaled video where there was enough bandwidth for one sub group but not enough bandwidth for all the subgroups.
Individual Comment: Here's a clip from the minutes: My understanding of that scenario is that prioritization can deprioritize some subgroups but they are queued indefinitely unless the objects within pass the DELIVERY_TIMEOUT. If the delivery timeout is infinity, how does a relay know which subgroups can be skipped over (or when) and which are critical? Do you have a different mechanism in mind?
Individual Comment: If a publisher doesn't have enough MAXSTREAMDATA, MAXDATA or MAXSTREAM_ID to send objects, it seems to me that it needs to queue until the peer grants these credits, up to the delivery timeout, right?
If the relay is sending data to a subscriber, and the link between the subscriber and the relay cannot sustain the bitrate of the track, eventually the relay will have to buffer more and more data. At some point, the relay would have to drop the data; we should specify how that happens (lowest priority stream gets dropped first?).
Individual Comment: +1 We need to specify what happens in this case. I think there's two parts: 1) selecting what gets dropped (this is a priority question) 2) the mechanism for dropping (stream resets, etc).
+1 Expanding Alan's list, I think we should determine: (1a?) valid boundaries for dropping data (group? object? byte? bit?) (2a?) under what circumstances the subscriber needs to be informed of the dropped data (do we need different verbs with different semantics in this case, e.g. fetch/subscribe? is dropping data always permitted and something all subscribers must be able to tolerate?) (2b?) the means of informing subscribers of dropped data (implied or explicit)
The AI is to add an error code for SUBSCRIBE_DONE to indicate a subscription was cancelled because the subscription was too far behind.


Explicitly state that these IDs are numbers that can be compared to determine order. This is already implicit in a number of places in the draft.
NAME and NAME Said that group IDs may be sparsely used, particularly in cases when they were chosen in a way to avoid collisions. This sounds like an interesting set of use cases, but previously my understanding was that groups indicated some sort of temporal ordering, even if it's not strict. If Group IDs don't imply temporal ordering and join points, and instead they're a way to publish Objects in a way that don't collide with one another, it seems like a different thing? Top of head strawman: Possibly different users could have the ability to publish Objects as themself for a single track? Having a few specific use cases would be helpful here, because it feels like there are real use cases, and the existing mechanisms might be awkward at best? It would also be useful to understand the use cases so we understand if they're in scope for MoQ.
Possibly relevant to
I have advocated strongly for having Group IDs begin at 0 and increment by 1, with no gaps. This restriction (which is identical to what we have for Objects) brings us some valuable benefits: Arbitrary relays, without any other information, can know if Groups are missing Clients can tell if groups are missing, without having a catalog to define the numbering scheme. I spoke this over with Cullen and Suhas. They mentioned that they have a use-case in which clients will publish data under the same namespace and name, but using different ranges of groups IDs (correct me if I'm wrong there guys) and that therefore GroupIDs cannot increment by 1. My concern is that this one use-case is burdening the transport with a whole ton of complexity around knowing where there are gaps. Witness . I'd like to simplify moq-transport by setting restrictions on GroupsIDs and then help brainstorm alternate solutions to their multi-publisher use-case that are compliant with a simpler version of moqt.
I completely disagree with the use-case NAME and NAME have suggested. A track must have a single publisher and I just can't envision how MoQ would work otherwise. If you have multiple publishers, then make multiple tracks/namespaces. A subscriber can request them all. Or a muxer can request them all and produce a new merged track at incrementing group boundaries.
I am also in favor of Group ID beginning at 0 and incrementing by 1.
There was this issue discussion on groupId and gaps and why relays need not do the book-keeping on gaps between groupIds or such .. URL
I'm totally lost on what problem people think they are trying to solve with this issue. I really object to how we constantly reopen stuff for no reason. The protocol works fine with multiple publishers and out of order groups - we have running code that does that. We have discussed this is the past and the use cases. There is no new data that is like here is why this causes performance problems. We have multiple use cases that take advantage of this. ( some of the variations of group chat, logging, metrics ) GroupID are left to the applications using them to choose. Due to timing and priority issues, if a relay receives group 2, object 1, it can not assume it will never receive another object form group 2. Some applications use them to indicate ordering and dependency. The data model makes it clear they are a join point, and because of that things that have dependencies can use them for the dependent things. The proposal we had for make before break can results in out of oder groups.
Speaking as Chair: NAME The issue as filed is soliciting use cases. Will stated you have some, it would help if you could document them here in as much detail as possible. Other folks seem to be advocating for a particular design without seeing the full picture. It would probably help if we understood the use cases first. I'm surprised to hear about use cases where multiple publishers are publishing to the same track simultaneously in different groups. I don't ever recall talking about this pattern, apologies if I missed it. Victor pointed out here (URL) that arbitrary group or object numbering interact poorly with subscribe ranges/fetch. Because a relay can never know the how the id spaces are populated for a track, the relay/cache has to assume all ids exist until told otherwise by the original publisher. Suhas indicated that if a publisher drops (skips?) a group it will signal that. There are scalability challenges if the 62 bit space is sparse - perhaps people were talking past each other in the issue? I think the group is struggling because use cases and the protocol design elements they depend on are not well documented, in writing, in a central place. I've gone back and forth about resurrecting the use cases and requirements draft and adding new detailed sections that have this scope (eg: explaining make-before-break, and what moqt protocol elements it requires). Ideally, we would get consensus on the use cases we are trying to support. Would folks find it helpful? I'm wary of having folks invest in writing something if we're not going to read it.
As discussed at length in the other issue, "no relay should not assume any structure between groups". Groups are independent join points and we should not add more application semantics at the MOQT layer . it tends to more bookkeeping which is not really needed.
Let me take a stab at going through the range of solutions that can exists when fetch requests are made for large absolute ranges. For this discussion, I am ignoring caching since it is easy to think through caches independently. When a relay receives a fetch request for large absolute range, one the following can be the response it gets from the upstream Relay receives a marker object for each group that is not included. Relay receives some kind of maker object with range of groups that doesn't exist. [ this is optimization on 1] Relays receives no indication on the groups not included. These options apply similarly regardless of group Ids being sequential or non-sequential and when things are missing or not produced or so. Does this makes sense ? Happy to add a PR to clarify some of these .
NAME NAME and others, We're not looking for solutions to support non-sequential groups yet - we're still looking to get documentation of the application use case that drives the non-sequential group requirement.
So I know this sounds a bit snarky and I really don't mean it that way but have you read URL ? There also been a bunch of similar things. I sort of work on the assumption chairs are reading the drafts in the WG.
:D Thanks for the bump. Well now I've skimmed it at least far enough to see this: I'll take a closer look. Let's use the metrics repo for any discussion about it's design rather than having it here. Are there other use cases you would like to surface here? Even if the chairs are reading every draft, not everyone else in the wg is.
So lets imagine the client requests the range 0-10,000, but the publisher only produces group ID's at odd numbers. Is the proposal that each relay in the distribution chain send along 5,000 marker objects to indicate the gaps? That doubles the number of objects sent in response to each subscription. Compare that to a scheme in which groups IDs are sequential and zero markers need to be sent. Surely a marker-less scheme is more efficient in caches and across the wire?
So the use case for fetch has generally been VOD and getting the most recent 15 seconds on live streaming video. Both of these case would make sense to use sequential groups so I don't see this problem. The use case people have brought up about sparse groups are not so much cases where getting the old data makes much sense and also some of them the applications know what the groups are if they wanted them. I'm of course not suggesting a classic VOD use case would use non sequential groups, however it might on scalable codecs, but what I don't see why the relays do anything different if groups have to be sequential or not. Consider a live streaming like use case where groups are sequential and it is stream per group. A relay gets 3 streams coming in to it and on stream A get gets an object in group 1, on stream B it just waiting and has not received anything yet. And on stream C it gets an object from group 3. I probably don't want to have the relays not send objects from group C because they are waiting for something that might arrived from group 2. I'm not understanding what people think they want to do in the relays that requires the groups to be sequential. Overall, we need a design for fetch (lacking a better name for subscribe to old data). If fetch ends up for priority reasons to be delivered over a single stream, then it upstream just puts in order stream. Of course other designs are possible but am not getting what people want and why
My intent was not to provide a solution. I was instead proposing non-normative clarification text on the solution space which applies similarly regardless of the groupId structure. However, I feel once we resolve fetch api, flow control and limits around handling large absolute ranges, we can revisit to see if groupId are still the issue or not.
Are logging and metrics the motivating use cases for multiple publishers of the same track? Reading the drafts, it doesn't appear like that is the intent, or you could get collisions. If you have any use cases like this, can you share them?
Individual Comment: Based on how SUBSCRIBE is defined now, I think both group IDs and object IDs have to indicate an ordering. If I SUBSCRIBE at a given start group and object, only published objects with groups numerically greater than or equal to that will be delivered. This is similar with SUBSCRIBE_UPDATE specifying the end of a subscription. Object IDs are also numerically comparable for prioritization within their group and priority level. There's text all over the draft implying these comparisons are valid, for example in stream-per-track, group IDs cannot go backwards. If an application wants to pick IDs at random, use a hash scheme, or dole out ranges to multiple publishers where newer things have numerically smaller IDs, then some funny interactions and protocol violations may ensue. No one has publicly specified a use case yet for doing this.


The text we landed for to define priorities (URL) indicates that we should use a 8 bits ( where is ) to convey subscriber priority and similarly a byte to convey publisher priority. ( URL ) ( URL ) The text also indicates that lower values have higher priority which I read as meaning 1 () should be sent before 10 (), (After) is 133 (u8) Edit: We should probably recommend that implementations use a mid-range value like as a default to allow for prioritizing both above and below it. (The MoQT spec doesn't need to define a default since these values are currently always explicit on the wire, but I think it would be helpful to provide guidance here.)
I have a slight preference for treating these priorities as signed values because it makes a good default for implementations to choose. That way it's possible to go above or below the default. The same is possible with unsigned values, too, but if we go that direction we may want to provide some guidance to that effect (recommending something like or as a default mid-range value).
Oh, nevermind, NAME noticed some text I missed in section 4: "with 0 being the highest priority" which would imply these are unsigned int values, . It may still be helpful to make that more explicit and recommend a default mid-range value.
I'm fine with some editorial text here if that's how we want to resolve it? (PRs welcome NAME ) I'm also ok with it being signed, since it it nice for 0 to be a 'default' value, but we don't use signed integers anywhere else in MoQ, so I'm a bit concerned that using them in exactly one spot could be confusing or error prone?
In some cases, things would work better if we allocated some ranges of priorities to specific DSCP like "less than best effort" or "best effort". That would end up making the actually numbers here have absolute meaning too instead of just relative meaning.


Oh that makes more sense. Let's add this to the issue and see if others agree there.
NAME NAME you both approved when this PR set the value to 0 but I changed it. Please take another look.
if a Datagram object is delivered via FETCH (which doesn't really make sense, see and ), what Subgroup ID do I put in the FETCH object header? The only answers that make sense are zero, or the object ID.
I think the answer is getting datagrams via FETCH doesn't make much sense?
Agreed! The point of this issue is that there is an ambiguity in the spec unless we choose to close it via 588 or 599
I think we need to be able to fetch object that were originally delivered over datagram. Common use case is audio is over datagram and client got disconnected from the meeting for 10 seconds, rejoined, wants to get the missing 10 seconds and replay and 1.5x speed till it catches up then joins live meeting. I was sort of assuming subgroup would be zero for datagrams but I had not thought about using object ID. I would be concerned when doing that that object id can be large but size sub groups are limited to be pretty small so we could make them work with priorities. My question would be, does it every matter in anyway what the subgroup is for fetch ? If not, then zero seems fine.
Individual Comment: +1 for using zero It does if data that is FETCHed can later be subscribed to. Today it's possible because SUBSCRIBE allows Current Group (). If adding JOIN removes that (I think it should) then the protocol wouldn't have a direct use for subgroup. I wonder if there's a case of FETCHing a static asset to a re-broadcast publisher that would recreated the broadcast and want the subgroups though. I'm inclined to keep them in the FETCH stream wire format, at least for now.
The easiest way to think about this probably is, datagrams for a track have just on subgroup and thus its value is 0. I feel subgroup concept is important since it allows a publisher to control granularity of HOL blocking (based on subgroup size) support different priorities within a group I am not too sure of the requirement of fetched data to serve subscription. Even in JOIN flows, it is internally fetch + subscribe. We have following cases: Case 1: Objects are sent as datagrams and cached with subgroup of 0 On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects as datagrams. Basically fetch flattens the priorities, original stream mapping (datagram here) and just returns objects from the cache. Case2: Objects are sent over streams and can have one or more subgroups. So when cached, objects can have different subgroupIds. On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects based on the subgroup mapping in one or more streams. Even here, fetch flattened the subgroups and priorities and just returns objects from the cache. What am i missing here ?
Maybe you want this comment on ? I think for now a PR with subgroup=0 should resolve this.
I don't have that strong a preference, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.
Individual Comment: I previously +1 using zero but I'm convinced by Ian's argument to set it to the object ID. That may result in ever-so-slightly larger FETCH responses when there are more than 64 objects in a group, but I think that's in the noise.
I'm fine with this, since it resolves the issue, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.


One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary. Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.


Current definition specifies namespace is an N-tuple, with 132 is it expected to return a protocol violation, or do we leave that undefined?
+1 I think we should address this as part of refactoring the tuple type
I put up a PR addressing the issue but didn't do a larger refactor of the tuple type, which seems editorial.
Editorial suggestion, but LG


Allow clients to send GOAWAY to signal servers to UNSUBSCRIBE.
PR has GOAWAY as only sent from server to client, but there may be use cases for the reverse as pointed out by NAME
I'm not really clear, what would be the use case for client -> server GOAWAY? If the only use case is a client indicating end of subscription, then I think that would be better encoded in the SUBSCRIPTION_END that Alan mentioned, but if there's other use cases then I could see GOAWAY making more sense.
What if the client is not the original source, but rather a relay. In that case, the relay may need to restart/etc. One option is the relay sends a GOAWAY and the client starts publishing to a new relay. But does it need to do something about it's upstream subscriptions?
FWIW ... relay to relay is out of scope - we are only doing client to relay - we would need a lot more to have a full relay to relay protocol
A client-initiated GOAWAY is weird but kind of makes sense. I'm thinking of the dual ingest case when there are two connections from broadcaster to relay(s). If the client sends a GOAWAY message, it's an explicit signal to the relay that it needs to UNSUBSCRIBE to everything and find another route to the content. The party isn't over, you just can't stay here. But there's some overlap with UNANNOUNCE. I'm not sure if we actually need it.
That use case makes sense. "The party isn't over, you just can't stay here." is awesome tag line for use case. For a graceful shutdown of a publisher, I think the way to do that would be the client publishing sends un-annouce and the relay then ends all the subscriptions, once all the subscriptions are gone, the client closes the connection.
With UNANNOUNCE and ANNOUNCE_CANCEL (), I'm inclined to think we don't need this.
UNANNOUNCE tells the receiver not to send new SUBSCRIBEs, but doesn't currently mean "please UNSUBSCRIBE and find somewhere else to SUBSCRIBE if you still want content". Do we want a message to convey that semantic?
It definitely feels odd given that outside of SETUP and ROLE parameter, MoQT is a symmetric protocol.
My current thinking is that GOAWAY is useful for all publishers, even if they're 'clients' (ie: an original publisher). It also seems useful if an original publisher is publishing to an ingestion server that is about to restart and the server wants to cause them to connect to a different ingestion server. I don't have a clear use for the end subscriber sending a GOAWAY, but it also doesn't seem particularly harmful.
I think you missed a few spots to update (suggestions made), but maybe you intentionally left those as is?


Individual Comment: lgtm
I don't have a strong opinion, but why not MAXCACHEDURATION?
Section 6.1.1 has not been updated to reflect the 2 new messages with parameters.
I don't have a strong preference. Mind writing up a PR of whatever you think is a sensible proposal?
I don't have any preference at all, but I can do a straw man.
I can think of AuthInfo as the only parameter that makes sense for now. NAME please let me know if you think of anything else. I can add it to my PR. Thanks
Thanks, this should have been added originally.


Merging based on in-person discussions.
You merged a litttttle early. The wire format is good, but the accompanying text could use some tweaks. For example, it's not specified when the object sequence number should be incremented. It must be done on every independently decodable OBJECT. I'll make another PR.


This is a PR to propose changes in the data model PR. Largely work in progress, but I wanted to first propose an organization.
The introductory text seems clear to me. I have questions about what it means for an object to be 'atomic' - since it can necessarily be larger than an MTU it might not get delivered. It can be repaired of course, but what are the consequences to other objects in the group or track if the object never completely arrives? Are there restrictions on receivers attempting to use partial objects? This reader is excited to read the next chapter :D
NAME The main consequence of "atomic" is that it is way better to send one complete object than two incomplete objects. That should very much guide scheduling of transmissions at relays. The other consequence is that if publisher can split a big blob of data into several objects that can be processed independently, they should. For example, instead of sending "the entire GOB as an object", they would get better results sending the GOB as a series of objects, with each object boundary becoming a proper "cut mark". And yes, I have to develop the text. I checked in a partial PR to Suhas' PR, mostly to test my editing chain...
thanks Christian for detailed text. I will merge it into my branch and do an updated version based on this.


Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy


reworked some architectural patterns: Javascript applications accessing resource servers directly (js = oauth client)


This looks great. I'm going to merge this and make a few minor tweaks to it.


I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.


As discussed on the OSW, this PR adds a small section with security considerations on the use of (a.k.a. "web messaging") to this draft. It makes reference to , which already discusses the security implications of in-browser communication flows in detail. Since (silent) iframe flows and popup flows are especially used in browser-based apps, we think that it makes sense to include security considerations of their in-browser communication into this draft. Please let us know what you think about this. We appreciate any feedback.
Sounds good to me, thanks!


fixes URL
Thanks NAME I like it, I updated the PR
Because the UI and the backend APIs can be hosted from the same backend application, Anti-forgery tokens can also be used to protect against CSRF.
There are indeed various CSRF defenses that could be used in this architecture. The two options discussed in the current document explicitly focus on defenses that are part of the core web platform, and require minimal effort from the developer to implement. The use of anti-forgery cookies requires code on both the frontend and the backend to guarantee their effectiveness. Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?
I thought it would be good to add this as it is per default supported in some tech stacks and so easy to use. People reading the doc might read it as only the mentioned ways protect against CSRF. Adding this would make the recommendations more complete. “Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?” In my opinion, there are no benefits compared with the other two options, just another option. Samesite cookies/ anti-forgery cookies are also a viable option. If the used tech stack has this already supported per default, then there is less to do as a developer. This would make it an option.
NAME I am open to listing out this option as well for the scenario you mention. Do you have text you could suggest that captures this?
Hi NAME I'll write something Kind regards Damien
NAME NAME I created a PR with an initial draft. I don't think we should explain how it works because this is not the scope of this doc. kind regards Damien
Thanks for the suggestion NAME I believe it is important to explain why this addition is there, so I've taken a stab at rewording (see below). I have also removed some of the implementation details that are not necessarily relevant (e.g., the use of HTTPS). I also removed the note on encryption, since the value in the cookie is typically random, so there would be no need to encrypt the cookie. Let me know what you think.


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.


This PR offers an alternative to . Compared to PR it makes two changes: I removed the newly added text to avoid creating confusion between the responsibilities of a BFF. While it is technically possible to deploy a BFF as part of an API gateway, I believe this suggestion may create confusion for someone trying to grasp the pattern. An API Gateway is closely linked to an API, while a BFF is (in theory) closely linked to a frontend. Reworded the benefits of the Token Mediating Backend to more accurately represent the advantages/disadvantages of the pattern, as correctly suggested by this PR If this PR is merged, can be closed.


Arrow C is referenced in the text "[The code in the browser] obtains an access token via a POST request (C).". The arrow should have an arrowhead on both ends as it symbolizes both the token request and token response. "The JavaScript app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs." I think this sentence was misleading, because as of today there is no way for the app to store tokens securely in the browser. Arrow E was not referenced in the text.


Refined the trusted device section to make it clear that restricting to a specific device type is another option to limit the impact of deploying cross-device flows (issue )
Limit it to specific devices.


Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.


Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.


See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).


Alternative name for authenticated flow (see )
Can we find a better name for the "Authenticated Flow" mitigation?
Additional authentication on consumption device Initial authentication on consumption device Authenticate before initiating cross-device flow. Authenticate on consumption device before initiating cross-device flow. Cross-Device Flow with previous authentication Authenticate before initiating cross-device flow.
Thanks, approved with minor editorial changes


See issue
Closing issue
Add reference to VC presenation specs in section 4 and section 2.2.1
Only adding references to section 4. Adding this in section 2.2.1 will be confusing, even though a QR code is being scanned in these protocols, unlike device code flow, the session does not revert back to the consumption device.
Addressed in PR
Looks good to me, one small editorial change.


Adressing feedback in issue
NAME
Feedback from Dean Saxe on WGLC Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? URL
Fixed 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. 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


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. 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


Addresses issue NAME
WCLC Feedback from Dean Saxe 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. URL
addressed in
lgtm 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. 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


Addressed issue NAME NAME
Feedback from Dean Saxe during WGLC 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. 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. 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


Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >


Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME


Clarify the authorization server's role in detecting if a cross-device protocol is being used in a same-device scenario. See issue NAME
Give guidance that enforcement of same device use of the protocol is something the authorization server should do, in addition to a design time constraint. From Roy Williams: 1) At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let’s say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service’s Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. Full feedback here: URL I had promised at the 119 meeting that I would review this document and give feedback. I have completed that document and other than two potential clarification points, I found it to be helpful. The following two areas could be slightly improved: At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let's say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service's Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. In the case of 6.1.1 establishing proximity, there is a boundary (pun not intended) case where a device will shift between two different cellular providers. The IETF's Drone effort were examining the same problem as the drone flies close to an international boundary and flips back and forth to roaming and not. How to deal with this case or whether it is dependable is a question. I know that Pieter is suggesting Fido2, but the way this section is written a Consumption device may be on a weak Wifi and the authentication device has shifted to Cellular. Roy.


See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.


Added reference to the mitigation when describing .
NAME I made one editorial change. If your OK with it, I will merge.
Ok for me, thanks! NAME


Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph


Added clarification that CIBA is not a standard under development, but was completed in September 2021 and added references to the completed standard.
Refer back to issue
Thanks for that bit of historic context Brian. I will remove those references.
Thanks NAME and NAME - I also added you to the acknowledgment section.


fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien


Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.


Accepted proposed text to clarify that this document does not cover cases where the user is colluding with an attacker.


Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving


Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a


Included feedback based on
Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script. While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.


Corrected typo (related to )
In the first sentence of section 3.3 you say "authorizations" instead of "authorization"


Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!


See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).


Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!


Instead of referencing spray attacks, describe how they work (see )
Instead of referring to spray attacks, describe how an attacker might use the same QR or user code by sending it to the different recipients.


Consistently hypheante and clarify section on sender constrained tokens
consistently hyphenate sender-constrained tokens. Clarify limitations.
One typo from earlier.