jiebi/CodeConvo huggingface dataset:
Code change:
claim. <del> 6.4.4. </del> <ins> 6.3.4. </ins> <del> A Consumer MAY cache Type metadata for a type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </del> <ins> A Consumer MAY cache Type Metadata for a SD-JWT VC type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </ins> header of the HTTP response to determine how long the metadata can be cached. <del> 6.4.5. </del> <ins> 6.3.5. </ins> Credentials MAY encode Type Metadata directly, providing it as "glue <del> information" to the consumer. </del> <ins> information" to the Consumer. </ins> For JSON-serialized JWS-based credentials, such Type Metadata documents MAY be included in the unprotected header of the JWS.  In

Related discussion:
text: Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above.
Code change:
claim. <del> 6.4.4. </del> <ins> 6.3.4. </ins> <del> A Consumer MAY cache Type metadata for a type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </del> <ins> A Consumer MAY cache Type Metadata for a SD-JWT VC type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the </ins> header of the HTTP response to determine how long the metadata can be cached. <del> 6.4.5. </del> <ins> 6.3.5. </ins> Credentials MAY encode Type Metadata directly, providing it as "glue <del> information" to the consumer. </del> <ins> information" to the Consumer. </ins> For JSON-serialized JWS-based credentials, such Type Metadata documents MAY be included in the unprotected header of the JWS.  In

Related discussion:
text: Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.
Code change:
Request: <del> 2.2.5.1. </del> <ins> 2.2.4.1. </ins> A new receipt: <del> 2.2.6. </del> <ins> 2.2.5. </ins> This endpoint is inspired by I-D.draft-ietf-oauth-sd-jwt-vc. Authentication SHOULD NOT be implemented for this endpoint.  This

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
Code change:
3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.

Related discussion:
text: Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a
Code change:
The ABNF for a Boolean in textual HTTP headers is: In textual HTTP headers, a boolean is indicated with a leading "?" <del> character.  For example: </del> <ins> character followed by a "1" for a true value or "0" for false.  For example: </ins> 4.

Related discussion:
text: thx!
Boolean values can be conveyed in Structured Headers. The ABNF for a Boolean in textual HTTP headers is: sh-boolean = "?" boolean boolean = "0" / "1" Either say "0" is false and "1" is true, or maybe rephrase the ABNF to: sh-boolean = sh-false / sh-true sh-false = "?0" sh-true = "?1"
Code change:
Clients SHOULD treat 500 and 503 HTTP status code responses as transient failures and MAY retry the same request without <del> modification at a later date.  Note that in the case of a 503 response, the Transparency Service MAY include a "Retry-After" header field per RFC9110 in order to request a minimum time for the client to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. </del> <ins> modification at a later date. Note that in the case of any error response, the Transparency Service MAY include a "Retry-After" header field per RFC9110 in order to request a minimum time for the client to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. </ins> 2.1.

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
Code change:
Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of End-User data or correlation <del> attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT as the plaintext payload of a JWE) to encrypt the SD-JWT when transmitted over an insecure channel. </del> <ins> attacks by passive observers are a concern. To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the SD-JWT as the plaintext payload of a JWE.  Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. </ins> 10.3.

Related discussion:
text: update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative
Code change:
flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. <del> 5.1.15. </del> <ins> 5.1.16. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or

Related discussion:
text: Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.
Code change:
the key goals for QUIC were: Minimizing connection establishment and overall transport latency <del> for applications, starting with HTTP/2, </del> <ins> for applications, starting with HTTP, </ins> Providing multiplexing without head-of-line blocking, Requiring only changes to path endpoints to enable deployment, Enabling multipath and forward error correction extensions, and

Related discussion:
text: From NAME
NAME and NAME - I agree with Magnus in his email (cut and pasted in the description), where he said "what about RMTP and SRT?", but I'm thinking that since we already have a "Why QUIC?" section, we should probably have a "Why NOT other protocols" section, rather than trying to talk about that in (what was) Section 6.1. That could also conveniently map into saying why we're not looking at "Interactive Media" in this document (and, transitively, in the BOF), and why we're not looking at "On Demand" (Media) in this document (and in the BOF). Please let me know if this is a BAD idea soon (I'm typing PRs).
NAME for media ingest, Magnus has a good point about covering not just HLS and DASH, but also making (even brief) reference to non-segmented protocols like RTMP and SRT (but really, this can be expanded to RIST, ZiXi, etc etc etc). This can just be a sentence or two; I'm happy to write it.
NAME - I had a complicated day yesterday, which became less complicated last night, so I'm not coherent enough to type text. I'll see what I can do in the next couple of hours, and if I can include these NAME suggestions.
The current definition of latency targets in the draft is based on specific numeric ranges. Those do make sense (since they ultimately come from use case requirements), but I believe we should focus more on what consequences those have for the protocol design. Reflecting on our experience with QUIC used for live video vs QUIC used for video conferencing, my proposed definition of the latency target for live video would be "latency an order of magnitude higher than one RTT". Two major examples of why this is important: When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment. When the target latency is in the range of many, many RTTs, selectively retransmitting only lost packets is almost always better than FEC. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs.
Code change:
the key goals for QUIC were: Minimizing connection establishment and overall transport latency <del> for applications, starting with HTTP/2, </del> <ins> for applications, starting with HTTP, </ins> Providing multiplexing without head-of-line blocking, Requiring only changes to path endpoints to enable deployment, Enabling multipath and forward error correction extensions, and

Related discussion:
text: I think the first point illustrates nicely why protocols like RTP have low-level control over packetization, while the existing MoQ proposals defer it entirely to the QUIC stack.
NAME - that's super helpful. It helps us explain a few things - why we need to know this, in order to explain why we're shooting for One Protocol, and why we think the first three use cases in the draft are different (they're all RTPish), and why we're not looking at RTP in the BOF - right now, the draft just says AVTCORE is looking at RTP over QUIC, which really isn't much of a justification, engineering-wise.
Victor's points are well made, though I think picking the boundary of the number of round trips necessary to rely on standard QUIC loss detection is a challenge. 5 RTTs provides almost 5 opportunities to repair a loss, which in my experience is almost always enough. Similarly, I'd expect it's enough for BBR to complete various probing cycles. It's also important to understand what RTT we have in mind here. I think the RTT used to understand what domain you're in is approximately smoothed RTT (not min RTT), because the number of rounds for loss recovery or BBR gain cycling or Cubic packet conservation matter the most.
I agree that the numeric ranges are not useful when designing a protocol but they're useful enough as product requirements. However focusing on the RTT completely misses the point. Network latency involves fixed delays (min RTT) but most of it is caused by queuing (primarily congestion control). This includes any queues within the application, the network layer, intermediate routers, and even the receiver. You can think of latency as the "frame RTT" which is decoupled from the packet RTT. Of course the packet RTT is important, but it just doesn't factor in how much data has been queued. For example, it's just useless to talk about RTMP and HLS/DASH latency in terms of network RTTs. In my opinion, the problem with those protocols is that they impose unnecessary dependencies, making it slow to drop the bitrate to reduce queue sizes. Sending media over a single stream means that every frame depends on every previous frame regardless of the GoP structure (no frame dropping), and it also means that new GoPs are dependent on the previous GoPs (no skipping ahead).
Code change:
the key goals for QUIC were: Minimizing connection establishment and overall transport latency <del> for applications, starting with HTTP/2, </del> <ins> for applications, starting with HTTP, </ins> Providing multiplexing without head-of-line blocking, Requiring only changes to path endpoints to enable deployment, Enabling multipath and forward error correction extensions, and

Related discussion:
text: WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.
Code change:
acquisition and deployment of software in certain security domains of the organization, a check of software quality and characteristics must succeed.  Compliance and requirement checking includes audits of <del> the results of organisational procedures and technical procedures, </del> <ins> the results of organizational procedures and technical procedures, </ins> which can originate from checks conducted by the organization itself or checks conducted by trusted third parties.  Consecutively, <del> consumers of statements about a released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews, certification documents (e.g., FIPS or Common Criteria), virus scans, vulnerability disclosure reports (fixed or not fixed), security impact or applicability justification statements.  Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </del> <ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews certification documents (e.g., FIPS or Common Criteria) virus scans vulnerability disclosure reports (fixed or not fixed) security impact or applicability justification statements Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </ins> A consumer of a released software wants:

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:
Either the client or server of the connection. <del> The smallest unit of communication, each containing a frame header. </del> <ins> The smallest unit of communication within an HTTP/2.0 session, consisting of a header and a variable-length sequence of bytes structured according to the frame type. </ins> A complete sequence of frames.

Related discussion:
text: Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,
Code change:
To indicate that the content is a Key Binding JWT: <del> 12.2. </del> <ins> 12.3. </ins> This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry

Related discussion:
text: Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.