jiebi/CodeConvo huggingface dataset:
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.15. </del> <ins> 6.14. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.

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:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.15. </del> <ins> 6.14. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.

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:
StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. <del> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  Only present for the "AbsoluteRange" filter type. </del> <ins> EndGroup: The end Group ID, inclusive.  Only present for the "AbsoluteRange" filter type. </ins> Subscribe Parameters: The parameters are defined in version- specific-params.

Related discussion:
text: This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: This PR: adds relationship to other docs section - preview here: URL
One little nit on the text but otherwise looks okay (after the couple iterations by NAME and NAME thanks for those).
NAME pls approve if you are happy with the latest language, then we will merge the PR.
Data model in this document resembles to the ID Token data model as defined in OIDC (with the addition of cnf). On the other hand, the data model is trying to follow the W3C VC data model. What is the benefit of this data model over the W3C VC data model (except that the claim names are different and iss can be a URI, and not an object and that JSON-LD is not supported by the data model, which basically excludes some significant use cases such as Europass that are leveraging JSON-LD for internationalization, for example)?
It is simple, leverages all predefined JWT claims (including eKYC), and can be used by people familiar with the JWT model to also implement VCs - with SD-JWT also with selective disclosure capabilities. So it clearly gives an easy migration path from the federated to the issuer-holder-verifier model. We tested the idea with some projects and communities and it seems a lot of implementers like that. Regarding Europass and other JSON-LD-based credential schemes. There could be another spec defining how SD-JWT could be used with JSON-LD.
eKCY defines its own data model same as for ID Token. eKYC can be easily mapped to VCs. The only real difference is the name of the metadata claims (iss vs issuer, iat vs validFrom, etc.) But SD-JWT can be used with W3C VCs (bot as SD-JWT is and W3C VCs as they are).
eKYC defines an extension that can be used in any JWTish environment. Doesn't work with W3C VCs due to the split between subject related data (credentialSubject) and metadata (evidence). Ask Mark Haine. not sure what you mean. can you please explain.
We did some mapping in the past (it was some time ago, and I don't remember how far we got): Evidence in VCs is optional and the model and use of evidence for eKYC doesn't make a lot of sense since eKYC already defines the full data model.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: eKYC can be nicely modelled within the credential subject. There were discussions around re-using the model of eKYC for expressing different levels of verifications. Essentially it was something like: verifiable-attestation-URL is the VC data model e-kyc-verifiedclaims-2022-URL - is the JSON schema of the eKYC
Just had a chat with Alen about typing and want to share the conclusion. We think typing happens on the following levels: Payload of a (HTTPS) response - here, a processor needs to know how to process the object (blob). So on this level, the media types or should be used. JOSE header - on that level, the determines how the payload of the JWS shall be processed. fits on that level. It governs the format (SD-JWT, which implies JSON) and what claims MUST be present (e.g. and ). Those claims are related to security of and trust in the credential. They are not related to the further domain specific structure of the credential. In SD-JWT VC, we use the claim to determine the structure/schema beyond the basic structure determined by the JOSE header. A university credential, for example, will have different rules for the schema of the payload than a drivers license. NAME NAME NAME NAME NAME NAME NAME Please let us know, whether we are on the same page. If so, it might be beneficial to add some text along those lines to the draft.
on point 1, I think that is ruled by the underlying protocol - OID4VP/OID4VP define those ( and ) I do not think sd-jwt vc draft should say anything about that. on points 2 and 3, i think i agree
to answer the original question raised in the issue, the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like will not be conformant. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. VCDM itself is silent about how to sign/process the I would absolutely not equate ID Token data model to a VC data model. VC data model needs one step to get to the ID Token usability which is defining how the concepts defined in VCDM are mapped to the JWT claims and how to sign/process that JWT claimset, which is what this sd-jwt vc draft attempts to do.
NAME I think we need to at least scope the media type definition in the spec as those definitions are related to the only, not request payload.
why it can't be left to the protocol? why it can't be ? just for example: URL
NAME the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like NAME is in the payload, we put it to be conformant, but are not processing it will not be conformant. Please check the discussion in URL since the conclusion is different. NAME What do you understand under LD processing? (LD processing with VCs is used only by: data integrity proofs, selective disclosure that's been just defined, internationalisation, identity matching, some advanced querying) Since JWS is not using any of that, JWS protection mechanism is not affected by the -LD part. However, it enable use cases, that want to use the -LD (e.g., ELM v3) for internationalisation etc., to use it. When VCs are secured with JWS, LD processing is not performed. It MAY be performed, if use case requires it, in the post-processing (after the validation) or rendering phase. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. That's perfectly fine. W3C VCDM is focusing on the VCDM data model.
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: Note that the current VCDM v2.0, without any JWT claim, is a valid JWT. VCDM itself is silent about how to sign/process the data model I think this is a good approach of the specification, since it defines a data model. Securing mechanism should be defined by specifications like JAdES which defines a profile for JSON-based AdES.
Reason is simple and it is following the basic architecture/design principles. Signature (e.g., JWS) defines the serialisation and with it the resulting type. JWS specification cannot and should not know anything about the protocol that will use it. When a protocol defines a profile or a set of supported elements, the protocol needs to ensure that the media type that's defined consistent with the elements it selected.
NAME Perhaps I did not explain well. This is the media type definition from the spec. It does not describe the context where the media type shall be used. So people might think this is a media type that should be used as content type of an HTTP response. I think we agree this is not the case. All I'm suggesting is to document the intended use in the JOSE header (and as format identifier in credential exchange protocols). Would you agree?
I don't agree that it is a good idea to take VCDM claims and use all of those to secure JWTs, because there are existing claims from JWT claims registry and existing implementations depend on those
NAME thank you for your feedback and I fully understand your concern. We need to put things into a context: most of those cases operate within closed systems where everything is well defined - data models, verification rules, etc. Within this context, I fully agree with you. Securing JSON-LD can be done today by JAdES (pure JWS, no JWT). I believe it is worth to read and reflect on it URL From my experience, the NAME is really processed (in most cases) outside of the verification scope/process. There are signatures that rely on the context, however, that's not relevant for JWS and this discussion. (In a brute-force scenario context can be embedded/inline and problem solved - size is the price to pay - not in the scope of this discussion) Since JWT specifies that all claims are optional, libraries should be able to process JWT tokens without any JWT claims (I know how it sounds).
Code change:
8. <del> TBD </del> <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats, which can be used independently of each other.  For example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>

Related discussion:
text: From experience, JWS/JWT libraries verify the signature, other verifications are performed manually. People could also argue that VCs are used. This direction won't lead to a solution. ID Token and eKYC define rules for the JWT claims when they are secured with JWS. I believe there are many other use cases that define profiles, rules, etc. In an open multi-use case system, there are additional challenges and we had a good discussion with Torsten on the topic where we identified several points that should be considered. It is worth reflecting on the designs of JWS JAdES linked data proofs VCDM v2 on their data model and serialisation. Back to my question: What is the real benefit of this data model over the W3C VC data model by looking at the situation objectively? (I'm also trying to find an answer to the question) With Torsten we had a very fruitful discussion. We need to reflect on several elements. Have a nice weekend!
NAME , I missed one point. Can you please elaborate on "take VCDM to secure JWT"? If my understanding is correct (sometimes is, sometimes isn't), it is JWS the one secures the payload (and it can be any JSON). JWT claims define contextual information: who, validity, about who, for whom. We should reflect on sigTst from JAdES. I'm personally not proposing to use VCDM to protect a JWT. VCDM and JWT are both protected by JWS.
As an example, iss and cnf are registered claim names for JWTs that are used to secure the VC. Existing RFCs are using those. Therefore it doesn't make sense to overwrite those by the w3c data model in my opinion
Thank you NAME I understand your view. If VC claims were registered, what would be the benefit of the data model over VCDM? Since I’m involved in projects that use VCDM (in JSON and JSON-LD) and also JWT I would really like to understand the objective benefits od the data model.
To resolve this issue, we will add a section on relationship to other documents and include a chapter on "VCDM".
This issue is ready for a PR.
Approved with a minor proposed improvment.
Code change:
is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. <del> The algorithm-specific details of checking inclusion proofs are covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency Services. </del> Relying Parties MAY be configured to re-verify the Issuer's Signed <del> Statement locally, but this requires a fresh resolution of the Issuer's verification keys, which MAY fail if the key has been revoked. Some Relying Parties MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. Relying Parties MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case a dispute arises. </del> <ins> Statement locally. In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated. Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </ins> 5.

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
content with a length prefix, and a trailer section with a length prefix. <del> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content. </del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. <ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content, not including the length field itself. </ins> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.