jiebi/CodeConvo huggingface dataset:
Code change:
signatures on them can no longer be trusted to originate from the Issuer. <del> 11.2. </del> <ins> 11.3. </ins> If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the

Related discussion:
text: Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
Code change:
signatures on them can no longer be trusted to originate from the Issuer. <del> 11.2. </del> <ins> 11.3. </ins> If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition
Code change:
signatures on them can no longer be trusted to originate from the Issuer. <del> 11.2. </del> <ins> 11.3. </ins> If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the

Related discussion:
text: Despite or maybe in light of some recentish discussion on the mailing list, the topic seems like it deserves more prominent placement.
Code change:
6. This section defines encoding, validation and processing rules for <del> SD-JWT VPs. </del> <ins> presentations of SD-JWT VCs. </ins> 6.1. <del> SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I-D.ietf-oauth-selective- disclosure-jwt. </del> <ins> A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I- D.ietf-oauth-selective-disclosure-jwt. </ins> <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> A presentation of an SD-JWT VC MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. </ins> 6.1.1. <del> If the SD-JWT VP includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </del> <ins> If the presentation of the SD-JWT VC includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </ins> The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored.

Related discussion:
text: Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?
Code change:
JWK Set included by value or referenced in the JWT Issuer Metadata. The following is a non-normative example of a JWT Issuer Metadata <del> including </del> <ins> configuration including </ins> : The following is a non-normative example of a JWT Issuer Metadata <del> including </del> <ins> configuration including </ins> : <ins> Additional JWT Issuer Metadata configuration parameters MAY also be used. 5.3. The value returned MUST be identical to the value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. </ins> 6. This section defines encoding, validation and processing rules for

Related discussion:
text: The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.
Code change:
the process of issuance/registration and distribution of the underlying credentials ensures their confidentiality. <del> If the client is confidential or credentialed, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </del> <ins> If the client is confidential, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </ins> It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS RFC8705 or "private_key_jwt"

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple <del> communications systems and channels (e-mail, messaging, text etc), </del> <ins> communications systems and communication channels (e-mail, text messaging, instant messaging or other communication mechanisms), </ins> making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems.

Related discussion:
text: See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.
Code change:
configuration of underlying encryption, allowing a "http" URI to be accessed using TLS RFC5246 opportunistically. <del> Currently, "https" URIs require acquiring and configuring a valid </del> <ins> Serving "https" URIs require acquiring and configuring a valid </ins> certificate, which means that some deployments find supporting TLS <del> difficult.  Therefore, this document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </del> <ins> difficult.  This document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </ins> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks,

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
8.2. A downgrade attack against the negotiation for TLS is possible.  With <del> commitment commit, this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </del> <ins> commitment (see commit), this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </ins> For example, because the "Alt-Svc" header field I-D.ietf-httpbis-alt- svc likely appears in an unauthenticated and unencrypted channel, it

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:
send only the extensions that narrowly specify which certificates would be acceptable. <ins> Servers can also learn information about clients using this mechanism.  The hostnames a user agent finds interesting and retrieves certificates for might indicate origins the user has previously accessed. </ins> 6.3. Failure to provide a certificate for a stream after receiving

Related discussion:
text: I believe that NAME comment on that issue is already covered by the following section on Denial of Service.
If a malicious server claims support for a variety of common hostnames for which it doesn't actually possess certificates, browser clients with a long-lived connection to the attacker will probe for certificates when the user attempts to access those sites. This allows the server to monitor user behavior during the lifetime of the connection, even without valid certificates. One obvious strategy is to probe everything "interesting" ASAP after the ORIGIN frame, but that obviously leaks what the client considers interesting, which is its own privacy leak. Note that a DNS lookup of claimed hostnames prior to requesting the cert prevents this attack. Should probably recommend that clients which omit the DNS lookup never solicit secondary server certificates, but probably don't need to mandate anything.
In addition to monitoring user behavior, depending on client behavior (do you race two connections? fallback on error?), the malicious server could also deny access to other hostname or degrade performance.
Code change:
that controls its message storage, retrieval, and deletion.  A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.  Any <del> client or server MAY employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. </del> <ins> client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel. </ins> The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response

Related discussion:
text: ... full stop.
Also 500f337 (committed instead of PR'd, sorry; if we don't do this that will need to be backed out)
Code change:
4.1. <del> The OPTIONAL "u" (user ID) parameter is a byte sequence that specifies the user ID that the user agent wishes to authenticate. </del> <ins> The OPTIONAL "k" (key ID) parameter is a byte sequence that identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. </ins> 4.2. The OPTIONAL "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the <del> credential that matches its user ID. </del> <ins> credential that matches its key ID. </ins> 4.3.

Related discussion:
text: The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Code change:
2.1.2. The "match-dest" value of the Use-As-Dictionary header is an Inner <del> List of String values that provides a list of request destinations for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination). </del> <ins> List of String values that provides a list of FETCH request destinations for the dictionary to match. </ins> An empty list for "match-dest" MUST match all destinations.

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.11. </del> <ins> 3.2.12. </ins> A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders. <del> 3.2.12. </del> <ins> 3.2.13. </ins> An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
and delivery of SRT on top of QUIC using datagram frame types.  This specification sets some requirements regarding how the two interact and leaves considerations for congestion control and pacing to <del> prevent conflict between the two protocols. </del> <ins> prevent conflict between the two protocols.  Apart from that, SRT provides a native suport for stream multiplexing, thus contributing this missing functionality to QUIC datagrams. </ins> 3.5.

Related discussion:
text: One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!
Code change:
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <ins> 4.4. The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to possessing the key exporter output.  This avoids issues with signature schemes where certain keys can generate signatures that are valid for multiple inputs (see SEEMS-LEGIT). </ins> For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):

Related discussion:
text: In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this
Code change:
supply chain attacks across the entire software lifecycle while prioritizing data privacy. <del> Insert more detail on the development and deployment flows, threat landscape, and notional artifacts that allow security/compliance risk assessment. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM!
Code change:
The "next-hop-aliases" parameter's value is a String STRUCTURED- FIELDS that contains one or more DNS names in a comma-separated list. <del> The items in the list include all alias names an canonical names </del> <ins> The items in the list include all alias names and canonical names </ins> received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they

Related discussion:
text: think its a case of s/an/and
The abstract says is it really , is it some other phrasing a little more technically correct?
LGTM thanks
Code change:
"jti": A unique identifier for the token. <ins> "wth": Hash of the Workload Identity Token, defined in to-wit. The value is the base64url encoding of the SHA-256 hash of the ASCII encoding of the token's value. </ins> "ath": Hash of the OAuth access token, if present in the request, which might convey end-user identity and authorization context of the request.  The value, as per RFC9449, is the

Related discussion:
text: Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.
Code change:
segment boundary and MUST preserve segment boundaries when forwarding frames. <del> Bit 5 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad Low field is present. </ins> <del> Bit 6 being set indicates that the Pad High field is present. </del> <ins> Bit 5 being set indicates that the Pad High field is present. </ins> This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a ConnectionErrorHandler of type

Related discussion:
text: I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.