jiebi/CodeConvo huggingface dataset:
Code change:
4.2. The following is a non-normative example of a presentation of the SD- <del> JWT shown above including a Key Binding JWT: </del> <ins> JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this presentation, the Holder provides only the Disclosure for the </ins> <del> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. </del> <ins> claim.  Other claims are not disclosed to the Verifier. </ins> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:

Related discussion:
text: Add general SD-JWT VC Type Metadata framework based on NAME work: URL See preview here: URL
Yep, good point. I18N is definitely needed although I'm not too sure about name/description since those are intended for developers only, not for end-users. I'll create a ticket to consider I18N, and also discuss whether this is needed for dev-only fields. I18N is definitely something we should add to metadata but needed some PR to start with first.
We have 3 approvals and no new comments coming in after 2 weeks. I propose to merge this PR NAME NAME . PR was created 1 month ago.
We should define more clearly what a credential type (identified by the claim) actually means. The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well. I think that there is a set of metadata usually associated with each SD-JWT VC type, for example Display information for the whole credential A schema for the JSON structure (may or may not be defined in JSON schema) Information about the claims, including Display information Type information Status information (self-attested vs. verified etc.) Maybe: What kind of binding is supported/usually used for this credential type Maybe: What issuers are allowed to issue this credential type Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect. The need for such metadata has been discussed in Issue and similar approaches have shown up in . The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered values (e.g., ), this metadata could go into the registry. It could also be distributed manually. But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in . Here is a completely made-up example of what this metadata could look like: Important: This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now.
Code change:
4.2. The following is a non-normative example of a presentation of the SD- <del> JWT shown above including a Key Binding JWT: </del> <ins> JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this presentation, the Holder provides only the Disclosure for the </ins> <del> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. </del> <ins> claim.  Other claims are not disclosed to the Verifier. </ins> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:

Related discussion:
text: There are overlaps with mechanisms defined in HAIP, for example, and part of this issue here is to figure out what data should go where and to avoid duplications by getting the concept right. I think that the element defined for the credential issuer metadata in could be replaced by just a identifier (the metadata could be discovered from there, or retrieved from the registry).
Interesting point, I have the following approach to satisfy the requirement of having the credential metadata along with a credential: using openid federation a trust chain is needed to attests the cryptographic keys of the issuer to verify the credential. Within the trust chain the openidcredentialissuer metadata is provided. in the openidcredentialissuer metadata there are the display information for all the credential types. Then, using this approach, the credential doesn't need any metadata. Fed trust chain can be made available in a static form, within the credential jws/MSO headers Let's see other points: I would not use , because its value seems more close to the concept of issuance type. I would say set(, ). Also the name may semantically collide with all about status lists It would be up to the trust model and the credential metadata or trust marks or attestations. We cannot allow an italian PID provider to issue a Polish PID, then the domestic italian credential identifier must be linked with one or more italian credential issuers. This information must be made available according to the infrastructure of trust, where the issued credentials are not involved yet. During a discovery phase the user/holder knows which are the credential issuers, which credential types they offers to users. Generally this is made available in the openidcredential_metadata and must be granted by an accreditation body. That's why I mentioned trusted lists or federation trust marks or X.509 custom extentions (for strong stomachs) or federation metadata policy. Without openid federation I would have to find a solution and the credential metadata sounds resonable but I use federation and this requirement is already satisfied. Another point of interest is that the credential metadata should be issued by credential issuer and bound to the credential. I would change this sentence we have in the current text: because the metadata should be issued by credential issuers and be tamper proof, otherwise a bogus implementation would use a valid credential with a fake presentation of the claims that may swaps some value and change the interpretation of the data to a verifier.
Code change:
4.2. The following is a non-normative example of a presentation of the SD- <del> JWT shown above including a Key Binding JWT: </del> <ins> JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this presentation, the Holder provides only the Disclosure for the </ins> <del> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. </del> <ins> claim.  Other claims are not disclosed to the Verifier. </ins> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:

Related discussion:
text: Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified
I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.
we may add: type of binding of the vc ,e.g. key-binding, claim-based-binding, none vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata IANA registry is probably not a good option versioning of the metadata protection against change e.g. put a hash of metadata in the vc It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource: However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.
Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.
I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback. URL
NAME I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into . I'm happy to help here. Similarly, the display reminds me of , which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?
For all these "human readable strings", please make sure to have an i18n story, and ideally reference PRECIS, or DisplayStrings, etc .
Code change:
4.8.1. <ins> It is possible to use groups as units of congestion control.  When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. This simple rules enable real-time congestion control decisions at relays and other nodes.  The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped.  If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion.  If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. 4.8.2. </ins> To enable use cases where receivers may wish to address a particular time of media in addition to having the most recently produced media available, both "pull" and "push" of media SHOULD be supported, with

Related discussion:
text: I think you're referring to the scalabilty mode known as "L2T2h": URL Of course, we could encode these dependencies as properties of the object being sent, stating for example that "object 17 can only be decoded if objects 16, 11 and 7 are available." However, this approach leads to a lot of complexity in relays. We believe that a linear approach is preferable, using attributes of objects like delivery order or priorities. [BA] Why would this lead to complexity in relays in a receiver-driven scenario? The relay would only forward the layers that the receiver asked for, and wouldn't have to store state relating to the receivers. Also, the real issue here isn't dropping layers, which can occur at any point. The reason dependencies (and more) are needed (and why the "linear approach" doesn't work) comes when it is desired to add layers. It is of course possible just to start forwarding additional layers, but that doesn't improve quality unless the forwarded frames can actually be decoded. To figure this out, whoever is in charge (receiver or relay) needs to be able to determine the "upswitch points". This also implies feedback from the receivers to the encoder (e.g. LRR). Section 4.2 We propose to express dependencies using a combination of object number and object priority. [BA] How would this permit restoration of video quality after congestion clears up? I don't think you have enough information. Section 4.3 . Relay behavior In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: [BA] Dropping is easy, it's adding layers back (and decoding them) that's hard.
Code change:
Bit 4 being set indicates that the Pad Length field is present. <del> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (GZIP).  Padding is not compressed. </del> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type . <del> Data frames are optionally compressed using GZIP.  Each frame is individually compressed; the state of the compressor is reset for each frame. An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless the setting is enabled, that is, set to 1.  An endpoint that has not enabled DATA frame compression MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </del> DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states.  The entire DATA frame payload is included in flow control, including Pad Low,

Related discussion:
text: Frames can be coalesced or split -- this is antagonistic to end-to-end, per-frame compression. This requires decompression / recompression in proxies that need to coalesce or split frame.
Discussed in NYC; no implementer interest, security concerns about proxying it. We believe it can be addressed as an extension now if someone wants to scratch that itch (and can find someone to interop with); however, fixing this properly means doing it at the HTTP semantic layer (e.g., with a new range type). In the meantime, remove frame compression.
Code change:
A template-driven TCP transport proxy for HTTP is identified by a URI Template RFC6570 containing variables named "target_host" and <del> "tcp_port".  The client substitutes the destination host and port number into these variables to produce the request URI. The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in RFC6570), the server SHOULD perform the same connection procedure as if these IP addresses had been returned in response to A and AAAA queries for a domain name. </del> <ins> "target_port".  This URI Template and its variable values MUST meet all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the request URI. </ins> 3.1.

Related discussion:
text: Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto").
Code change:
A template-driven TCP transport proxy for HTTP is identified by a URI Template RFC6570 containing variables named "target_host" and <del> "tcp_port".  The client substitutes the destination host and port number into these variables to produce the request URI. The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in RFC6570), the server SHOULD perform the same connection procedure as if these IP addresses had been returned in response to A and AAAA queries for a domain name. </del> <ins> "target_port".  This URI Template and its variable values MUST meet all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the request URI. </ins> 3.1.

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
software update images.  Doing so improves responsiveness of other connections at the cost of delaying the delivery of updates. <del> Also, a client MAY use the priority values for making local scheduling choices for the requests it initiates. 8. </del> <ins> 9. </ins> Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- hop frame, the Priority header field is defined as end-to-end.

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
Code change:
A recipient MUST be able to parse the chunked transfer coding (chunked.encoding) because it plays a crucial role in framing <del> messages when the payload body size is not known in advance.  A </del> <ins> messages when the payload data size is not known in advance.  A </ins> sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed).  If any transfer <del> coding other than chunked is applied to a request payload body, the </del> <ins> coding other than chunked is applied to a request's payload data, the </ins> sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.  If any transfer coding other than <del> chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </del> <ins> chunked is applied to a response's payload data, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </ins> For example, <del> indicates that the payload body has been compressed using the gzip </del> <ins> indicates that the payload data has been compressed using the gzip </ins> coding and then chunked using the chunked coding while forming the message body.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
A recipient MUST be able to parse the chunked transfer coding (chunked.encoding) because it plays a crucial role in framing <del> messages when the payload body size is not known in advance.  A </del> <ins> messages when the payload data size is not known in advance.  A </ins> sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed).  If any transfer <del> coding other than chunked is applied to a request payload body, the </del> <ins> coding other than chunked is applied to a request's payload data, the </ins> sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.  If any transfer coding other than <del> chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </del> <ins> chunked is applied to a response's payload data, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </ins> For example, <del> indicates that the payload body has been compressed using the gzip </del> <ins> indicates that the payload data has been compressed using the gzip </ins> coding and then chunked using the chunked coding while forming the message body.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.