jiebi/CodeConvo huggingface dataset:
Code change:
verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and <del> prevent verifier from obtaining claims irrelevant for the use case at hand. </del> <ins> prevent verifier from obtaining claims irrelevant for the transaction at hand. </ins> One example of such a multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
A software component source (e.g., a library) released by a certain original producer is becoming popular.  The released software component source is accompanied by a statement of authenticity (e.g., <del> a detached signature).  Over time, there has been an increasing amount of providers of the same version of the software component source over the Internet.  Some popular providers package the software component and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </del> <ins> a detached signature).  Over time, due to its enhanced applicability to various products, there has been an increasing amount of multiple providers of the same software component version on the internet. Some providers include this particular software component as part of their release package bundle and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </ins> fixes produced by third-parties, as these emerge faster than solutions from the original producer.  Due to complex distribution and promotion lifecycle scenarios, the original software component

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
A software component source (e.g., a library) released by a certain original producer is becoming popular.  The released software component source is accompanied by a statement of authenticity (e.g., <del> a detached signature).  Over time, there has been an increasing amount of providers of the same version of the software component source over the Internet.  Some popular providers package the software component and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </del> <ins> a detached signature).  Over time, due to its enhanced applicability to various products, there has been an increasing amount of multiple providers of the same software component version on the internet. Some providers include this particular software component as part of their release package bundle and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </ins> fixes produced by third-parties, as these emerge faster than solutions from the original producer.  Due to complex distribution and promotion lifecycle scenarios, the original software component

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements
Code change:
RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. <del> If used in a related-response, the "@query-params" component </del> <ins> If used in a related-response, the "@query-param" component </ins> identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.
Code change:
sending TCP stream content optimistically, subject to flow control limits (RFC9113 or RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the <del> TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </del> <ins> TCP connection fails.  (Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send

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:
sending TCP stream content optimistically, subject to flow control limits (RFC9113 or RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the <del> TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </del> <ins> TCP connection fails.  (Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send

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:
Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. <del> 4.2.1. </del> <ins> 4.1.1. </ins> The following rules apply to validating the "status_list" (status list) claim

Related discussion:
text: reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards
Code change:
be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT. <ins> The JWT MAY contain an "nonce" claim containing a String value that is provided by the authorization server to associate the Client Attestation PoP JWT with a particular transaction and prevent replay attacks. </ins> The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.

Related discussion:
text: Add security consideration for replay attack prevention and add nonce as optional value for PoP JWT URL
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
What about using the authorization code or pre auth code as suggested in our demo?
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code.
How many implemantations out there actually use different grant types than auth-code? Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested. NAME What's your opinion on this?
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.
discussion on 23.05 is leaning towards DpoP-style error providing nonce
can we please bring this issue forward, it is very important? I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint.
Update provided in
PR
PR
Code change:
most origin servers do not implement CONNECT. A client sending a CONNECT request MUST send the authority component <del> (described in Section 3.2 of RFC3986) as the request target; i.e., the request target consists of only the host name and port number of the tunnel destination, separated by a colon.  For example, </del> <ins> (described in RFC3986) as the request target, excluding userinfo but always with a port; i.e., the request target consists of only the host name and port number of the tunnel destination, separated by a colon.  For example, If the port is missing or invalid in the request target of a CONNECT request, the request MUST be rejected (typically, with a 400 (Bad Request) response). </ins> The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another

Related discussion:
text: It isn't a normative change because the ABNF already requires port to be present in this form of request. The description is just inconsistent. I also intend to change the reference to 3986 to the right section of this document.
The as used for CONNECT describes the request target as comprising an authority, which consists of an IP or reg-name and, optionally, a port number. The example shows an explicit port of 80. What happens if an explicit port is not included? Does the proxy use the port number associated with the implied protocol (80 if the inbound connection is TCP without TLS, 443 if it is TLS)? Or is it an error? As far as I am aware, a port is always provided in practice. Maybe the answer is to explicitly require that the port number is always present and note that no default port can be supplied in this case as there is no scheme and therefore no associated default port.
cc NAME
NAME +1. This is the most natural outcome based on our established consensus in H2 and H3 that CONNECT requests is not accompanied by a scheme.
It's supposed to be a 400 error.
I verified that Apache mod_proxy will respond with 400 if there is no ":" or if the port is empty or non-numeric, and 403 if the port is not configured for use.
Is this something that needs to be listed as normatice change?
Code change:
input_string.  If there are not two characters, fail parsing. <ins> If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing. </ins> Let octet be the result of hex decoding octet_hex (Section 8 <del> of RFC4648), in a case-insensitive fashion.  If decoding fails, fail parsing. </del> <ins> of RFC4648). </ins> Append octet to byte_array.

Related discussion:
text: Can I suggest we use 'converted' instead of 'normalized' ?
WFM, will update.
It's annoying to test for otherwise. Still allow both cases in parse.
Postel's law ("Be liberal in what you accept, and conservative in what you send.") isn't as popular these days as it once was. Not sure we need to accept upper case % anymore.
I am sure that we don’t. (Though I have thoughts on the use of the Robustness Principle to guide this sort of decision. Generally, it is better to look at what the case needs. Here, the values are created by code, so permissiveness is not a valuable feature.)
Fine. See URL
Code change:
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A <del> Status List may either be provided by an endpoint or be signed and </del> <ins> Status List may either be provided via HTTPS or be signed and </ins> embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic

Related discussion:
text: "endpoint" is still mentioned in there, unsure we we completely want to get rid of it
Section '8.1. Status List Request' currently states: This seems redundant when the endpoint is used to retrieve a Status List Token, as the Token's integrity is already guaranteed by requiring it to be signed using an asymmetric cryptographic algorithm. If requiring TLS was intended for providing confidentiality of the Token, this seems unnecessary. The endpoint is publicly accessible - there does not seem to be any client authentication mechanisms described for it - thus the Tokens could be retrieved by anybody.
Hi NAME , thanks for the feedback! I think you are correct that we could relax using TLS when a Status List Token is queried. However, if an unsigned Status List is returned, we need TLS as an integrity mechanism.
Yes I vehemently agree :) Btw, perhaps the issue is a bit broader that just permitting plain HTTP when obtaining Status List Tokens. I don't think it's currently explicitly stated in the specification whether a Status List Provider should/must simultaneously provide both plain Status Lists and Status List Tokens. Ie the standard states that an RP should use the Accept-Header to indicate the requested response type, but it does not specify what the Status List Provider should do if it is unable to provide the requested response type. I think this is somewhat relevant under this issue as: if you were to simply add a sentence to the spec permitting plain HTTP for Status List Tokens then an Issuer would have to decide whether to put an HTTP or HTTPS URI in the claim of the Referenced Token but this somewhat contradicts with the Accept-Header mechanism which would seem to indicate (to the reader of the spec) that it's up to the RP to choose the response type. Perhaps the Issuer should explicitly specify supported response type(s) in the claim of the Referenced Token? Ie there could be an additional attribute in the object under the claim specifying the supported formats. Such an attribute could prove beneficial in other regards as well. For example, I don't immediately see an use case where an Issuer/Status List Provider would be providing cbor/cwt Status Lists for JOSE Referenced Tokens.
Section mentions Status List Endpoint. The term is not mentioned elsewhere in the specification nor is it defined.
Thanks for the feedback. Discussion Editors Call: connected to the discussion whether Status List Provider is an entity that shall be described in the spec intend to clarify the term for next iteration
Code change:
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A <del> Status List may either be provided by an endpoint or be signed and </del> <ins> Status List may either be provided via HTTPS or be signed and </ins> embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic

Related discussion:
text: Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex