jiebi/CodeConvo huggingface dataset:
Code change:
WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is <del> established.  There is no definition of the protocol over other transports, such as TCP, and applications using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </del> <ins> established.  When using QUIC, datagrams MUST be supported via the [QUIC-DATAGRAM] extension, which is already a requirement for WebTransport over HTTP/3. There is no definition of the protocol over other transports, such as TCP, and applications using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.

Related discussion:
text: To allow subscribers to indicate that no new subscriptions will be routed to the publisher for a given namespace. Happy to bikeshed on the name and whether we really need another frame for this.
The problem is not possible for the subscriber to reject an ANNOUNCE afterwards. This would be very useful, for example to inform a publisher that no more subscriptions will be routed to them for whatever reason. Examples: The auth parameter in ANNOUNCE has expired. Another publisher has sent an overriding ANNOUNCE (reconnect?) The broadcast has been closed remotely, ex. some moderation tool. Without this message, the only recourse for the subscriber is to close the connection. This won't work if multiple ANNOUNCE messages are pooled over the same connection, nor is it clean.
I propose two options: can be sent after . We add and to mirror . I personally hate 3 separate messages for a subscriber to close an announce, or a publisher to close a subscription. See
very trivial bikeshed comment ... I would prefer to call it something other RESET ( and also other places we use RESET ). I get the TCP analogy but I think that is the wrong way to think about this. I would prefer something like REVOKE.
how about ANNOUNCE_CANCEL to cancel an open announce ?
Conclusion is that we do need to add a new frame to end an ANNOUNCE. Additionally, there was a principle stated that we should not rely on closing the session as the typical or optimal way to close state and close either an ANNOUNCE or SUBSCRIBE.
On the call today, people tend to prefer ANNOUNCECLOSE over ANNOUNCECANCEL as a name. They also prefer merging SUBSCRIBERESET and SUBSCRIBEFIN into a single message, possibly SUBSCRIBE_CLOSE.
On an editorial note, it'd be nice to have subsections for publisher/subscriber to make it clearer to the reader.
If we're going to combine and , then we should just combine and now. My desire is to have four messages: publisher create: ANNOUNCE publisher close: UNANNOUNCE subscriber accept: ANNOUNCEOK subscriber close: ANNOUNCESTOP The same goes for subscriptions: subscriber create: SUBSCRIBE subscriber close: UNSUBSCRIBE publisher accept: SUBSCRIBEOK publisher close: SUBSCRIBESTOP
Code change:
HTTP/2 uses DATA frames to carry message content.  The <del> transfer encoding defined in HTTP11 cannot be used in HTTP/2. </del> <ins> transfer encoding defined in HTTP11 cannot be used in HTTP/2; see ConnectionSpecific. </ins> Trailer fields are carried in a field block that also terminates the stream.  That is, trailer fields comprise a sequence starting with a

Related discussion:
text: The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).
Code change:
TBD: add other disclosures. <del> 4.3. </del> <ins> 4.4. The recipient of the VC-SD-JWT MUST process and verify an VC-SD-JWT as follows: </ins> <del> A Verifier MUST validate an VC-SD-JWT as follows: </del> <ins> Any claims used that are not understood MUST be ignored. </ins> Additional validation rules MAY apply, but their use is out of the scope of this specification.

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
Code change:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del> <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:

Related discussion:
text: yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change
Code change:
"aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del> <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:

Related discussion:
text: Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.
Code change:
header table is that the remaining entries are renumbered.  The first entry of the header table is always associated to the index 0. <del> When the modification of the header table is the replacement of an existing entry, the replaced entry is the one indicated in the literal representation before any entry is removed from the header table.  If the entry to be replaced is removed from the header table when performing the size adjustment, the replacement entry is inserted at the beginning of the header table. </del> The addition of a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the header table to be dropped and the new entry not to be added to the <del> header table.  The replacement of an existing entry with a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same consequences. </del> <ins> header table. </ins> 4.

Related discussion:
text: We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .
Code change:
2.1.1. <del> Authentication SHOULD NOT be implemented for this endpoint.  This endpoint is used to discovery the capabilities of a transparency service implementing this specification. </del> <ins> Authentication SHOULD NOT be implemented for this endpoint. This endpoint is used to discover the capabilities and current configuration of a transparency service implementing this specification. </ins> Request:

Related discussion:
text: Issue
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
The optional API endpoints have intent statements that outline the goal of the Endpoints for example 2.2.1 (Issue Signed Statement Endpoint) has this intent statement: Such a statement is currently missing from both: (Transparency Configuration) and 2.1.2 (Signed Statement Registration).
I'll take this one and put a PR up with consistency for all the endpoints
This was fixed in
LGTM
Code change:
to, remove or modify) the asserted values within a Txn-Token. The value of the "aud" claim MUST remain unchanged in a replacement <del> Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </del> <ins> Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </ins> <del> 7.3.1. </del> <ins> 7.4.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

Related discussion:
text: Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.
Code change:
to, remove or modify) the asserted values within a Txn-Token. The value of the "aud" claim MUST remain unchanged in a replacement <del> Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </del> <ins> Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </ins> <del> 7.3.1. </del> <ins> 7.4.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

Related discussion:
text: PR raised a number of issues around processing of authorization details How are these details determined by the Transaction Token Service (i.e. where do they come from)? Should all the claims be visible to all workloads? or should they be restricted to a subset of workloads? Who is authoritative for specifying the claims of the object
Some thoughts: I think the spec should be un-opinionated about how the TraT service generates the value of claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control. A TraT service could implement selective disclosure, although we could recommend in the spec that one should implement it by encrypting certain fields. Stating this makes the actual mechanism for selective disclosure outside the scope of the spec. I believe the TraT service MUST be authoritative for the claims of the object, because it is signing the TraT.
Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio. Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting object and whether it should be protected in some way or not. I am curious to hear from others as to their thoughts.
Suggestion to rename to and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the object into claims in the object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
I suspect in many cases the AS that issues an accesstoken used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself. Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the object. Should we require this format? or just leave out of scope of the specification what values are present in the claim of the transaction token?
I would definitely not require that format.
Code change:
to, remove or modify) the asserted values within a Txn-Token. The value of the "aud" claim MUST remain unchanged in a replacement <del> Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </del> <ins> Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </ins> <del> 7.3.1. </del> <ins> 7.4.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

Related discussion:
text: And would again suggest that RFC 9493 isn't needed in the Txn-Token context and good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the claim is determined. In that context, I think the Transaction Token should carry the issuer of the claim which means the default and claims of the JWT are not sufficient. Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of , is the Transaction Token Service the correct issuer of the which is an email address?
I feel like there might be an undue emphasis on a relationship between and that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer URL but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the and the such that the globally unique identification is the combination of and . I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the claim MUST be unique within the single trust domain as identified by the claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true? I can see the TTS being authoritative for the single trust domain but not necessarily for the identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion... 'iss' claim is optional be clear that there is no relationship between iss and sub claim sub is unique within context of the 'aud' or trust domain go back just supporting the claim (no sub_id)
Added a new commit to PR to address this issue.
A few months ago, I also suggested to support the sub claim as per JWT RFC.
Code change:
to, remove or modify) the asserted values within a Txn-Token. The value of the "aud" claim MUST remain unchanged in a replacement <del> Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </del> <ins> Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </ins> <del> 7.3.1. </del> <ins> 7.4.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

Related discussion:
text: As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Hi Kai, Thanks so much for your input in this process. Atul
Since we have removed sub_ids now, I will close this issue.
Wkn
Code change:
8.2. HTTP/2 allows a server to pre-emptively send (or "push") responses <del> (along with corresponding requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del> <ins> (along with corresponding "promised" requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </ins> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The setting can be set to 0 to indicate that server push is disabled. <ins> Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type . Pushed responses that are cacheable (see RFC7234) SHOULD be stored by the client, if it implements a HTTP cache.  Such responses MAY be considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open. Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.  They MAY be made available to the application separately. </ins> Because server push is effectively hop-by-hop, an intermediary could receive pushes from the server and choose not to forward them on to the client.  In other words, how to make use of the pushed

Related discussion:
text: I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.
Code change:
requests.  If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to "Lax". <ins> If a user agent uses "Lax-allowing-unsafe" enforcement (See lax- allowing-unsafe) then this default enforcement mode will instead be equivalent to "Lax-allowing-unsafe". </ins> The "SameSite" attribute affects cookie creation as well as delivery. Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
trailing whitespace in values is significant will have to use a container syntax such as quoted-string (quoted.strings). <del> Because commas (",") are used as a generic delimiter between field values, they need to be treated with care if they are allowed in the field value.  Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production. </del> <ins> Because commas (",") are used as a generic delimiter between members of a list-based field value, they need to be treated with care if they are allowed as data within those members.  Typically, list members that might contain a comma are enclosed in a quoted-string. </ins> For example, a textual date and a URI (either of which might contain <del> a comma) could be safely carried in field values like these: </del> <ins> a comma) could be safely carried in list-based field values like these: </ins> Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary: