jiebi/CodeConvo huggingface dataset:
Code change:
As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined <del> in HTML5. </del> <ins> in PRIVACY. </ins> HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  Reusing connections for

Related discussion:
text: The thinking has evolved considerably since the original reference was made. This is the right way to refer to this concept.
So the re-request review button doesn't appear to work; NAME any objections to landing this with the new reference target?
The current reference is in the WHATWG "infra standard": URL To use this, we need to ask for the "tracking-vector" anchor to be made permanent.
URL filed. I have changes for a pull request .
I'm a bit surprised you chose infra; the fingerprinting guidance document in the W3C is much more complete. There are also tons of academic references that have better descriptions; to start, Eckersley's original paper.
I was looking for a direct replacement, which is what that is. I can cite URL if you think that is better. Or URL if that makes more sense. I never know which is better.
Probably the TR - whatever bibxml says, I'd think.
I'm going to go with something simpler. RFC 6973 has an adequate definition.
None whatsoever.
Code change:
Relying parties MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 3.2.1. </del> <ins> 4.2.1. </ins> The following rules apply to validating the "status_list" (status list) claim

Related discussion:
text: NAME Whats' failing on the build here?
breaks the build All RFC references are resolved interally and linked
There are possible applications of this draft that go beyond just verifiable credentials, hence we do not want to use that term in this draft IMO. "Token" is already a term broadly used in this space e.g CWT and JWT both use it, "subject" was used in this context because it is also a term used heavily w.r.t tokens, feel free to suggest alternative terminology but at this point I think subject token is the best I've heard suggested.
can we simply use JWT/CWT instead of creating any kind of abstraction term like ? One person i asked for feedback associated with a token used to communicate a subject of an email.
or, bottomline, please stick to . is very confusing.
I'm with Tobias on this and prefer introducing a new term here. Otherwise things get really weird because the status list is also a JWT/CWT and a token. We need something that clearly separated the status list token and the other token. I think subject token is the best we have. Also subject is leaving towards what we have as credentialSubject in the VC world, so the term subject is kind of established in this context
I am really strongly against "Subject Token". Not only because it is not intuitive (I have been asking various people in this space and no one would associate what it trying to be conveyed), but we should not be introducing a new term in this already confusing ecosystem. Moreover, this status list mechanism can be used with a JWT/CWT that does not necessarily contain a subject (like SD-JWT-VC), so using a term subject because it is widely used is not a sufficient reason. Keep referring to it as a token, because this draft should not be opinionated about what is in the JWT/CWT whose status is being expressed should be fine, if a "status list JWT/CWT" is always referred as such. there are multiple occurrences where "status list JWT" is referred to simply as a JWT which should be fixed IMO.
We need clear terminology for: the status list token (i think this one fits pretty well) the credential / token that is bound to the status list I do believe only calling it token will cause confusion with the status list token.
Code change:
Relying parties MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 3.2.1. </del> <ins> 4.2.1. </ins> The following rules apply to validating the "status_list" (status list) claim

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
Clients and servers that will accept requests for HTTP-layer certificate authentication indicate this using the HTTP/2 <del> "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, the value is non-zero. </del> <ins> "SETTINGS_HTTP_CLIENT_CERT_AUTH" (0xSETTING-TBD1) and "SETTINGS_HTTP_SERVER_CERT_AUTH" (0xSETTING-TBD2) settings. The initial value for both settings is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, one or both of the values is non-zero.  "SETTINGS_HTTP_CLIENT_CERT_AUTH" indicates that servers can use certificates for client authentication, while "SETTINGS_HTTP_SERVER_CERT_AUTH" indicates that servers are able to offer additional certificates to demonstrate control over other origin hostnames. </ins> In order to ensure that the TLS connection is direct to the server, rather than via a TLS-terminating proxy, each side will separately <del> compute and confirm the value of this setting.  The setting is derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </del> <ins> compute and confirm the value of these settings.  The setting values are derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </ins> The exporter is constructed with the following input:

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes (RFC7235) which need to return additional information during or after authentication. </del> <ins> authentication schemes (RFC7235) which need to return information once the client's authentication credentials have been accepted. </ins> Both were previously defined in RFC2617, defining the HTTP "Digest" authentication scheme.  This document generalizes the description for

Related discussion:
text: Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .
Code change:
Each digest value ensures the integrity of, and maps to, the respective Disclosure.  Digest values are calculated using a hash <del> function over the Disclosures, each of which contains a random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in sd-jwt-structure. </del> <ins> function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in sd-jwt-structure. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.

Related discussion:
text: first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.
Code change:
time. Objects are comprised of two parts: metadata and a payload.  The <del> metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> metadata is never encrypted and is always visible to relays (see relays-moq).  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.

Related discussion:
text: 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
Code change:
3.3. <del> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </del> <ins> The following is a non-normative example of the user data of an unsecured payload of an SD-JWT VC. </ins> The following is a non-normative example of how the unsecured payload <del> of the SD-JWT VC above can be used in a SD-JWT where the resulting </del> <ins> of the SD-JWT VC above can be used in an SD-JWT where the resulting </ins> SD-JWT VC contains only claims about the Subject that are selectively disclosable:

Related discussion:
text: for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.
Code change:
8.1.2.1. <del> While HTTP/1.x used the message start-line (see HTTP11) to convey control data, HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) for this purpose. Pseudo-header fields are not HTTP header fields.  Pseudo-header fields contain control data (see HTTP).  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </del> <ins> HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear

Related discussion:
text: This required a little careful rewriting of text that only recently rewrote. Hopefully this retains the improvements of that rewrite.
Right now, we have a lot of 1.1-specific language. In theory, it should be possible to remove 1.1 references and use core HTTP semantics to describe the protocol elements. That would be much cleaner, but it could be tricky.
Nice. I think the retains the original meaning of the text well enough, and is as clear as it can be without ever needing to normatively invoke HTTP/1.1. Needle well threaded.
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.17. </del> <ins> 6.18. </ins> A publisher sends a 'TRACK_STATUS' message on the control stream in response to a TRACK_STATUS_REQUEST message.

Related discussion:
text: 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.
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.17. </del> <ins> 6.18. </ins> A publisher sends a 'TRACK_STATUS' message on the control stream in response to a TRACK_STATUS_REQUEST message.

Related discussion:
text: 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.
Code change:
values that are contained in the SD-JWT, along with the precise input to the hash calculation, and the salts.  There MAY be other information the issuer needs to communicate to the holder, such as a <del> private key key if the issuer selected the holder key pair. </del> <ins> private key if the issuer selected the holder key pair. </ins> 4.2.1.

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
As defined in that specification, one way of establishing this is using a TLS-based protocol with the certificate checks defined in <del> RFC2818.  Clients MAY impose additional criteria for establishing reasonable assurances. </del> <ins> RFC2818.  Clients are permitted to impose additional criteria for establishing reasonable assurances. </ins> For the purposes of this specification, an additional way of establishing reasonable assurances is available when the alternative

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
A recipient MUST be able to parse and decode the chunked transfer coding. <ins> The chunked encoding does not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.1.1. The chunked encoding allows each chunk to include zero or more chunk

Related discussion:
text: This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.