jiebi/CodeConvo huggingface dataset:
Code change:
Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message providing the result of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of <del> either ANNOUNCE_OK or ANNOUNCE_ERROR. </del> <ins> either ANNOUNCE_OK or ANNOUNCE_ERROR.  When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use

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:
The following rules MUST be followed in processing delta updates: If a catalog is received without the parent sequence number field <del> parentsequencenumber defined, then it is an independent catalog and no delta update processing is required. If a catalog is received with a parent sequence number field present, then the content of the catalog MUST be parsed as if the catalog contents had been added to the contents received on the referenced moq-transport object.  Newer field definitions overwrite older field definitions. </del> <ins> parentsequence defined, then it is an independent catalog and no delta update processing is required. If a catalog is received with the parent sequence number field present, then the contents of the catalog MUST be parsed as if the catalog contents had been added to the state represented by the catalog whose sequence number matches the parent sequence number. Newer field definitions overwrite older field definitions. </ins> Track namespaces may not be changed across delta updates.

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
Disclosure as described in creating_disclosures.  The Issuer includes a Disclosure for each selectively disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures selected <del> for the given presentation.  Additionally, for presentation with a Key Binding, the Holder adds the key </del> <ins> for the given presentation. Alternative methods for conveying the disclosures MAY be used (such as including them in a </ins> <del> at the top-level of the serialized JWS with a string value containing the Key Binding JWT as described in kb-jwt. </del> <ins> member of an outer JSON structure also containing the JSON Serialized SD-JWT) as dictated by a specific application or transport protocol. However, the details of such approaches fall outside the scope of this specification. </ins> Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be <del> split into component parts, but disclosures and (if applicable) a Key Binding JWT can be found in the respective members of the JSON object. </del> <ins> split into component parts, the disclosures can be found in the respective member of the JSON object (or elsewhere), and Key Binding (if applicable) will be provided by means not specifically defined in this specification. </ins> Using a payload similar to that from Example 1 [2], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. Below is a non-normative example of a presentation of the JWS JSON <del> serialized SD-JWT, where the Holder includes a Key Binding JWT and has selected to disclose </del> <ins> serialized SD-JWT, where the Holder has selected to disclose </ins> ,

Related discussion:
text: -Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses
Code change:
4.2. The REQUIRED "a" (public key) parameter is a byte sequence that <del> contains the public key used by the server to validate the signature </del> <ins> specifies the public key used by the server to validate the signature </ins> provided by the client.  This avoids key confusion issues (see SEEMS- <del> LEGIT).  The encoding of the public key is described in context. </del> <ins> LEGIT).  The encoding of the public key is described in public-key- encoding. </ins> 4.3.

Related discussion:
text: In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.
Code change:
When decoding a set of header field representations, some operations emit a header field (see header.emission).  Emitted <del> header fields can be safely passed to the upper processing layers as part of the current Header Set. </del> <ins> header fields are added to the current header set and cannot be removed. </ins> 3.1.1.

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.
Code change:
The PUSH_PROMISE frame defines the following flags: <del> PUSH_PROMISE frames MUST be associated with a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </del> <ins> PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </ins> associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type

Related discussion:
text: This makes it clearer that they can't be sent otherwise.
LGTM
Merged by RFC editor.
has the following clarification added in draft 17: Should this be instead of ? If not I think we have an inconsistency with which has the following for the section:
NAME - Ping.
This is merely a problem with perspective. As in, there is none. I can provide that thusly: Does that work?
This is an improvement. I'm not sure if we can avoid it but it is a bit confusing with respect to :
I don't think that's a problem. The (remote) peer isn't sending, but the (local) peer can.
Agreed. Ship it :) Thanks!
Code change:
an HTML document response, processed by the user agent.  If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full <del> access to the redirect URI and the artifacts (e.g. authorization </del> <ins> access to the redirect URI and the artifacts (e.g., authorization </ins> code) it contains.  Additionally, the request URL containing the authorization code may be sent in the HTTP Referer header to any embedded images, stylesheets and other elements loaded in the page.

Related discussion:
text: 657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"
Code change:
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del> <ins> URI must denote a "secure" connection (as defined by the user agent). NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".

Related discussion:
text: As the cookie specification does not clearly define the behavior on localhost, we could consider reusing the notion of from the Secure Context specification, instead of suggesting a user-agent-dependent "secure protocol" check on the scheme of the request-URI, in point 13 of . Best regards
I think it's reasonable to modify the phrasing to include potentially trustworthy origins.
This is a good change, thanks. I don't think we have WPT in place for this (and I'm not entirely sure that we can?), but have you looked into the support for this change across browser engines? I'm generally in favor of landing it as long as it's reflecting (near) reality.
Code change:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material. <del> Note: need to define how holder public key is included, right now examples are using </del> <ins> Note: Examples in this document use </ins> <del> I think. </del> <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.

Related discussion:
text: addresses Issue
NAME considering the last OOP refactor on the python code and the revision of Brian probably it would be easier to close this PR and starting a new one on top of the current master branch, the changes in the code and in the text are very trivial
NAME ok, please do a PR directly to this branch :)
Code change:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material. <del> Note: need to define how holder public key is included, right now examples are using </del> <ins> Note: Examples in this document use </ins> <del> I think. </del> <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
GOAWAY frame, the identified stream is the highest-numbered stream initiated by the client. <del> Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </del> <ins> Once the GOAWAY is sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </ins> If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those

Related discussion:
text: : As this sentence seemed to indicate that the sender itself was sent, we updated the text to clarify that the GOAWAY is sent. Please let us know if this update is incorrect. Original: Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier. Currently: Once the GOAWAY is sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.
Code change:
it MUST use DHCPv6 PD rather than the ULA Link prefix it allocated for the stub network out of its ULA Site Prefix. <del> A SNAC router SHOULD request stub network prefixes with length 64. If the SNAC router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the SNAC router obtains a prefix with length greater than 64, the SNAC router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. </del> <ins> A SNAC router MUST request stub network prefixes with length 64.  It does so by sending an IA_PD option for each prefix, each with a different IAID, containing an IA_PREFIX with a hint of 64 as described in RFC8415.  If the SNAC router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros.  If the SNAC router obtains a prefix with length greater than 64, the SNAC router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. </ins> A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for

Related discussion:
text: This change does two things: change the SHOULD to a MUST when specifying what size of prefix to request, so that only requests for /64 prefixes are allowed, and providing a reference to RFC8415 that says how to provide such a hint. Additional text describes what to do if there is more than one prefix.
OLD: A SNAC router SHOULD request stub network prefixes with length 64. New: A SNAC router should request stub network prefixes using IAPD with IAPrefix with a hint of 64 as defined in RFC 8415 Section 18.3.9.
Agree with adding the details. Is there a reason to change SHOULD -> should ? Seems wise to keep the SHOULD in caps given the MUST requirement that follows soon after it:
Code change:
<del> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC9360, using the signature algorithm and verification key of the Issuer. The Transparency Service MUST check that the Signed Statement includes the required protected headers.  The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. </del> <ins> The Transparency Service MUST perform signature verification per RFC9052 and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per RFC9360.  The Transparency Service MUST also check the Signed Statement includes the required protected headers.  The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types. </ins>

Related discussion:
text: This editorial change attempts to per feedback from NAME
The three steps from Section 4.3 on Registration are essentially the same. To verify the signature you have to retrieve the issuer credentials and you have to do item 4. Issuer Verification: The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. Signature verification: The Transparency Service MUST verify the signature of the Signed Statement, as described in [RFC9360], using the signature algorithm and verification key of the Issuer. Signed Statement validation: The Transparency Service MUST check that the Signed Statement includes the required protected headers listed above. The Transparency Service MAY verify the Statement payload format, content and other optional properties.
LGTM for reduction and lack of duplicity
Code change:
entities to an entity who does it on their behalf to offload the burden to filter from and select all statements <del> that are applicable to a particular release of a multi release </del> <ins> that are applicable to a particular version of a multi release </ins> software product, to an entity who does this on their behalf to make an informed decisions on which authoritative entities to

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
Check for the existence of a "status" claim, check for the existence of a "status_list" claim within the "status" claim and validate that the content of "status_list" adheres to the rules <del> defined in referenced-token-jwt for JWTs and referenced-token-cwt for CWTs.  This step can be overruled if defined within the </del> <ins> defined in referenced-token-jose for JWTs and referenced-token- cose for CWTs.  This step can be overruled if defined within the </ins> Referenced Token Format natively Resolve the Status List from the provided URI

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication. <del> When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </del> <ins> A client acquires an http-opportunistic response by making a GET request to the "http-opportunistic" well-known URI.  When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </ins> The origin and alternative service's hostnames are the same when compared in a case-insensitive fashion, and

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:
Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.

Related discussion:
text: alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued.