jiebi/CodeConvo huggingface dataset:
I don't think that it needs a special call-out.
I agree that it doesn't need to be specifically called out that the window can be treated as a resource, and that this is an implantation detail. However calling out the stream states when referencing frames that impact the flow control window may be overly restrictive. For example the are not the only states in which a stream may be in the priority tree. Here are what I believe to be the relevant portions of the specification which relate to flow control window and stream state. seems to be very careful about stream state and doesn't necessarily limit to just is much more restrictive and declares that is not allowed in , or . For there is special mention that these frames must be ignored, or may be an error (if it arrives ). If the clarifications in this issue are applied then it seems like the impact on the flow control windows is further limited to .
BTW, I consider the state associated with having a stream in the priority tree to be necessarily separate from the state that is maintained for an "active stream" (i.e., one with active send or receive state). Lumping them all together exposes you to some potential attacks.
Can you be more specific (particularly about the )? I guess what I'm after is two fold: Consistency amongst the sections that discuss window update and stream state. Not necessarily preventing window_update being controlled when a stream is in the priority tree, or rational as to why it makes sense to do so.
The amount of state you commit to a stream that is active is potentially large (flow control windows, primarily). That is strictly bounded though by your value of the MAXCONCURRENTSTREAMS setting. If that state has to live on the same lifetime as stream priority, then it is not covered by the setting and you are potentially in a position to commit a much larger amount of state. You can (obviously) manage this by careful management of the transition to and from the active states, but I believe that it is better to instead have separate tracking of priority.
One way to implement this cleanly is to have a (small) priority state for streams that is created and managed by a garbage-collector. Active stream state can be a separate object that maintains a reference to the priority state (that might be nullable, or you could require that only closed or idle streams be exposed to the GC).
Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged?
It seems like if a stream is allowed to be put into the priority tree (via a PRIORITY message) and its window size controllable (via SETTINGS) then why would a WINDOWUPDATE also not be allowed? I look to the following statement and think that accounting may already be required to track the PRIORITY and SETTINGS updates. The WINDOW_UPDATE accounting seems like it is very similar (or may be close to identical depending on the implementation).
We want to strictly limit the amount of state that is maintained for non-open streams. Currently, that is limited to priority. Opening that to more state isn't really necessary. For WINDOWUPDATE, there is only the case where you want to open the flow control window immediately after opening a stream, which currently causes a potential stall on the remote/sender side. As specified, you can create a priority graph that is separate from the other stream state (flow control in particular). If we allowed WINDOWUPDATE in idle (or reserved), then you need to commit more state. We already acknowledge that priority information needs special handling outside of the key stream states, so the risk is both accounted for, and already present. The most important factor though is that priority is expendable. Under DoS, you can drop priority on the floor. You can't do the same for flow control. Therefore, any state commitment needs to be strictly bounded for that.
Right. So for these cases the peer creating the stream will have to wait to expand (or shrink) the window until after the stream has transitioned out of the IDLE state. So state may not be required however if a peer wants to change the window for that stream then state will be necessary to keep and act upon when the state transition occurs. I"m not sure I follow. WINDOW_UPDATE is allowed in reserved according to . Priority is an interesting portion of the spec. It almost seems like you could ignore priority all together and be compliant :)
Hmm, strange how you forget these things. Yes, you can send WINDOWUPDATE in "reserved (remote)". This allows a client to affect the flow control window of the server that has promised a push. This is something that I know Firefox uses so that it can resume stalled pushes when it knows that they are needed. No extra credits over the initial window size are given to pushed streams until they are recognized as necessary.
You can't send WINDOWUPDATE in "reserved (local)". After all, the other side (the client) won't be sending anything on that stream. So none of this really affects processing of the setting :)
I think I agree with you in general (it is not necessary). I agree that minimizing state on IDLE streams seems like more of a driving force, and I also recognize that the peer can wait to send WINDOW_UPDATES until transitioning out of IDLE. I can also imaging a scenario that if an endpoint puts the node into a priority tree, it is possible they have an estimate of what they are going to be sending. It may then follow the theme of "a more flexible expressions of priority" (from ) to also be able to control the window of those streams (at a finer granularity than the SETTINGS frame). Anyways thanks for the discussion and clarification.
Editorial problem, I hope: The spec uses the phrase "current stream" in two places (both related to PRIORITY), but without any definition of what that means: 1) "5.1 Stream States: ... half closed (local) ... PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream." 2) "6.3 Priority ... Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream." I don't have alternate wording proposals because I'm not exactly sure what those sentences are trying to say. Note that I'm only talking about "current stream" in the singular. I see no confusion with the use of "current streams" (plural) in "6.9.2 Initial Flow Control Window Size".
"subject stream" or "identified stream" would work effectively well. I'll take suggestions.
Both sound fine, but "identified stream" is already used often in the spec and "subject stream" is never used.
Excuse me for trolling this issue but I couldn't help but notice how evil the issue number is.
I added a section about services provided by the Stub Network. This will need some more work, but it seems useful to have, and it now says that DHCPv6 is generally NOT RECOMMENDED but is permitted, and MUST be off by default.
(Based on recent discussion in v6ops) We don't specify yet the type of hosts on the IPv6 stub network in detail. For example, an IoT device host only needs an address which it can configure with SLAAC based on the /64 on-mesh/on-link prefix. However, there could also be more complex hosts in principle that need their own prefixes (e.g. /64) delegated to it for internal usage and they may like to use their DHCPv6-PD client for that. For example for running multiple virtual machines / dockers inside the host where these VMs are on their own virtual network segment. I expect these cases to be out of scope and there's no requirement on the stub router to do either DHCPv6-PD server or relay role. Do we need to make this explicit in a goal / non-goal / out-of-scope section ?
With my AD hat one, I sincerely hope to keep the stub network with simple devices, else the SNAC WG will try to make a simple problem too complex ;-) Without any hat, I do not mind having an applicability statement with non-goals in it.
Not "of the HTTP protocol".
and 9: To avoid the appearance of "of the Hypertext Transfer Protocol protocol", should these two instances of "of the HTTP protocol" be "of HTTP" (or perhaps, in the case of , "HTTP attributes" instead of "attributes of the HTTP protocol")? Original: The frame and stream layers are tailored to the needs of the HTTP protocol. ... This section outlines attributes of the HTTP protocol that improve interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.
Yeah, "of HTTP" is probably best here.
Updated terminology and other sections to clarify VCs and presentations can be repudiable or non-repudiable Minor typo fixed See preview here: URL
3 approvals, merging
The specification currently uses terms like public key validation and potentially other things when it comes to the verification of the KB-JWT. We should make sure there is no language that would prohibit the use of MAC authentication for KB-JWT and Issuer-signed JWT.
Currently blocked by SD-JWT: URL URL
NAME A few options we discussed on the editor's call today (cc NAME NAME ): not do anything in SD-JWT to enable this since SD-JWT just prohibits "symmetric algorithms". We could wait for an JOSE value specification to appear and to be registered in the IANA registry which states that the algorithm is not symmetric. One downside of this approach is that standard JOSE libs won't work today since the value is not supported. Note that technically one could implement this using standard if the key was agreed/derived using an ECDH/ConcatKDF schema. remove the normative statement completely from SD-JWT that prohibits "symmetric algorithms". change the normative statement to a SHOULD NOT use "symmetric algorithms" and explain in the SD-JWT security - considerations section where symmetric values are acceptable and when not. keep the MUST NOT statement in SD-JWT but add an "... unless" clause that explains where this could be useful, e.g., for hybrid schemes but this needs to be confirmed if this process is indeed hybrid and therefore the use case is covered.
I think is the cleanest approach, but may take more time for implementations, we will try to get some experience there. also doesn't sound bad to me.
I think I still lean towards preferring something like # 2 - just remove the explicit prohibition of symmetric algorithms from SD-JWT and not say much, if anything else about it in that spec. Let the layer above SD-JWT/JOSE (probably the presentation protocol) define how an HMAC key is agreed upon and use existing JWS HMAC algs and implementations. I.e., the verifier sends a public key in it's presentation request, which the generator uses in a key agreement with their private key to get a key that is then KDFd to produce an appropriate key for existing/established JWS HS256[384|512] algs.
That layer is going to have to define much of that anyway so there's not much gain from pushing an ECDH-based MAC alg into JOSE/JWS (also note that defining and registering a new JOSE alg is far from a trivial exercise). And the prohibition of symmetric algorithms in SD-JWT makes sense from a particular perspective but is arguably just unnecessarily restrictive at the building block layer.
I would agree that removing the restriction is okay, as SD-JWT is an improvement of JWT and JWTs don't have this restriction. Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
I wouldn't take it that far. My comments/arguments here are really just in the context of the current state of JWS specs and existing library support.
NAME NAME if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
I agree in general that since SD-JWT is a building block, being too restrictive there regarding symmetric algorithms is probably not necessary.
I don't object removing the restriction, I checked RFC7519 and there is no similar statement.
Definitely not opposed to saying something. But it might be challenging to say something that's actually meaningful/helpful.
URL removes the explicit prohibition on MAC from SD-JWT (which will be in the -08 draft-ietf-oauth-selective-disclosure-jwt)
Then, we need a PR that cleans up the language in this specification, so MAC is not going to be prohibited.
Includes some new text and several small cleanups.
did you forget to merge it?
Sorry, there was ice cream cake and I got distracted
Some header field values are case-insensitive, in whole or in part. The canonicalization rules do not account for this, thus a case change to a covered header field value causes verification to fail.
While I'd just put a warning on that, it would be great to have some examples/use cases for that.
Intermediaries are permitted to strip comments from the header field value, and consolidate related sequences of entries. The canonicalization rules do not account for these changes, and thus they cause signature verification to fail if the header is signed. At the very least, guidance on signing or not signing headers needs to be included.
Let's add a paragraph with some caveats and header examples.
As part of the discussion about the Encryption specification we discussed how Content-Encodings can or should take parameters from HTTP headers. The consensus was that they shouldn't. Whatever information a C-E may need should be inside the body of the object, just like the GZIP header etc. We should document this as a rule, if we ever do a HTTP[1].ter
+1, except for the constraint: "when possible". In the case of the encryption coding, it's clearly necessary to have the actual key information needed for description outside the payload.
we can add something to URL
I'm fine with this, but I'm also fine with closing with no action. I'm not sure what value it's really adding, since it's so vague, but I'm not sure what else can be said.
(again)
We say that we don't restrict how other caches (e.g., higher-layer in the browser, back/forward) interpret cache directives, but I think it would be useful to give a bit more guidance here, as this causes a lot of confusion and interoperability problems (since the browsers still haven't sorted out the various other caches' operation). For example, we could give string guidance (non-normative) that should be respected by other caches.
All of these caches are in front of the networking stack and in theory might not even have all response headers if converted to a more optimal representation. If you consider JavaScript modules, they are de-duped based on their request URL in a module map. If the first response for such a URL had , we still wouldn't be making any further requests. The same goes for images, style sheets, and some other resources as I understand it and for some of these changing that would result in compatibility issues (or presumably functional errors in case of module maps). For back-forward in particular it might be worth reading URL There's a worry that an explicit opt-out could end up cargo-culted and make the feature unusable.
NAME that makes sense, I agree the current wording is too strong. How about changing apparent to or easily controllable by the user, it is strongly encouraged to honour basic control mechanisms like Cache-Control: no-store, as they indicate the resource's intent regarding caching. to: apparent to or easily controllable by the user, it is strongly encouraged to define its operation with respect to HTTP cache directives, so as not to surprise authors who expect caching semantics to be honoured. For example, while it might be reasonable to define an application cache "above" HTTP that allows a response containing Cache-Control: no-store to be reused for requests that are directly related to the request that fetched it (such as those created during the same page load), it would likely be surprising and confusing to users and authors if it were allowed to be reused for requests unrelated in any way to the one from which it was obtained.
I think that's good. Some of the caches I mentioned do cross page loads (e.g., images and style sheets). However, I think the statement about those is correct and we should be better about explaining how they fit in and make sense (and perhaps adjust if they don't).
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity