jiebi/CodeConvo huggingface dataset:
Code change:
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 9.4. </del> <ins> 10.4. </ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy <del> 9.5. </del> <ins> 10.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO

Related discussion:
text: Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.
Code change:
Other deployments that meet the requirements set forth herein are also possible. <del> 4. </del> <ins> 5. </ins> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core.

Related discussion:
text: Document what needs to happen for compression. The Client-Cert field will be largely constant for the same client, so it might be a good candidate for compression. However, with requests through the TTRP potentially coming from multiple clients, the connection to the origin server might get different values over time. Document what needs to happen here: either very large dynamic tables with certificates in them, or no compression for the field and larger requests. You also need to consider the effect on the protocol of very large header blocks. Both HTTP/2 and HTTP/3 have soft limits on the size of header blocks that this might exceed. Servers need to be provisioned to allow for large certificates. cc NAME
Thanks for the feedback Martin. I've read through RFC7541 and some of RFC7540 and I'm honestly still unsure what this draft can or should say about compression. As I understand it, the size of the dynamic table is established between the peers (dynamic table size update and SETTINGSHEADERTABLE_SIZE) of the connection. And the TTRP would decide whether or not to add client certs to the table. Undoubtedly there's a trade off between large dynamic table with certs and no compression for the field with larger requests. But I don't know what's "better" and imagine it will depend on the specifics of the deployment. Although I guess continually adding and evicting certs on a small table would be the worst of both. Are you looking to have that trade off described in something like an implementation/deployment considerations? Or something more or different? And if so, are there some specifics you can suggest or propose? WRT limits and large headers, URL has "A server that receives a request with a Client-Cert header value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of [RFC6585]." Is that wrong? Or insufficient? Or is this another implementation/deployment considerations thing where the draft should mention to readers that they might need to adjust some settings around maxim header sizes? Or something else?
Roughly, I think you could say something like
I think the issue is somewhat different. H2/H3 allow implementations to advertise a limit on the sum of the size of all headers received.
Code change:
Other deployments that meet the requirements set forth herein are also possible. <del> 4. </del> <ins> 5. </ins> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core.

Related discussion:
text: If an intermediary and a backend advertise the same value, but the intermediary is adding huge headers, it's possible that a request that the client sent was within the limit, but the request sent by the intermediary to the server will be too large.
There's also some background in that might help explain the issue.
There are two things here really. Alan is concerned about header block size. Mark about compression efficiency. Both are worth mentioning.
Code change:
3.2. <del> To release to a verifier a subset of SD-JWT claim values, a holder </del> <ins> To SD-JWT-R to a verifier a subset of SD-JWT claim values, a holder </ins> creates a JWS such as the following: Note that the signature over

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR
Code change:
Reason Phrase: Provides the reason for announcement error. <del> 6.13. </del> <ins> 6.12. </ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the

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

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

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

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
Recommended HTTP status code: 502 <del> 3.33. </del> <ins> 3.32. </ins> Name: proxy_internal_response

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
IANA is asked to initialize the registry with the entries in iana- hash-algorithm-table. <del> 7.2. This section registers the "Representation-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Representation-Digest" Status: permanent Specification document(s): representation-digest of this document 7.3. This section registers the "Content-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Content-Digest" Status: permanent Specification document(s): content-digest of this document 7.4. This section registers the "Want-Representation-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Want-Representation-Digest" Status: permanent Specification document(s): want-fields of this document 7.5. This section registers the "Want-Content-Digest" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" SEMANTICS. Field name: "Want-Content-Digest" Status: permanent Specification document(s): want-fields of this document </del> 8.  References 8.1.  URIs

Related discussion:
text: simplifies IANA field registration section obsolete Digest
Thanks for this, it's almost there. I suggest we just have two sections that ask IANA to do things directly, rather than giving any prelude to those instructions.
Code change:
The format of "SUBSCRIBE_FIN" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239. <del> The proxy includes the client's signature value from the original message under the label "sig1", which the proxy signs in addition to the Forwarded field.  Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del> <ins> While the proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. While it is possible for the origin server to have additional information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- signatures).  To counter this, the proxy adds its own signature over the new message before passing it along.  The proxy includes the new "@authority" derived component and the Forwarded header, which it added to the message.  The proxy's signature also includes the client's signature value from the original message in its covered components, as a dictionary field member under the label "sig1". Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of:

Related discussion:
text: But perhaps I was just misreading... It seems there is a dependence of the final recipient on the signature of the proxy. I think there is still the problem of the time being wrong...
Yes, the signature needs to be recalculated and replaced due to the typo in the timestamp (I will need to check the generation script). I can see now how that line can be misread. Though it is definitely possible for the origin server to validate the client's signature if it has additional information, like that discussed in URL and URL -- but this could be made more clear.
Code change:
The JWT MUST contain an "iat" (issued at) claim that identifies the time at which it was issued. <del> The JWT MUST contain an "sts_lst" (status list) claim conforming to the rules outlined in jwt-status-list-claim-format. </del> <ins> The JWT MUST contain an "status_list" (status list) claim conforming to the rules outlined in jwt-status-list-claim-format. </ins> The JWT MAY contain an "exp" (expiration time) claim that convey's when it is considered expired by its issuer.

Related discussion:
text: Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo
Code change:
1. <del> Merkle proofs are verifiable data structures that support secure data </del> <ins> Merkle trees are verifiable data structures that support secure data </ins> storage, through their ability to protect the integrity of batches of documents or collections of statements. <del> Merkle proofs can be used to prove a document is in a database (proof of existence), or that a smaller set of statements are contained in a large set of statements (proof of disclosure). </del> A merkle proof is a path from a leaf to a root in a merkle tree. <del> Merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </del> <ins> Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </ins> The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications.

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.