jiebi/CodeConvo huggingface dataset:
Code change:
7. <del> TBD </del> <ins> 7.1. Claim names are not hashed in the SD-JWT and are used as keys in a key-value pair, where the value is the hash.  This is because SD-JWT already reveals information about the issuer and the schema, and revealing the claim names does not provide any additional information. </ins> 8.

Related discussion:
text: reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
Code change:
7. <del> TBD </del> <ins> 7.1. Claim names are not hashed in the SD-JWT and are used as keys in a key-value pair, where the value is the hash.  This is because SD-JWT already reveals information about the issuer and the schema, and revealing the claim names does not provide any additional information. </ins> 8.

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
6. <ins> SNAC networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the lack of a standard mechanism similar to router advertisements in IPv4.  However, it can stll be useful for hosts on the SNAC network to establish communications with IPv4-only hosts on the infrastructure network. Although NAT64 provides IPv6-only hosts with a way to reach IPv4 hosts, there is no easy way for an IPv4 host to use NAT64 to originate communication with an IPv6 host.  Therefore, this document enables IPv6 hosts on the SNAC network to discover and reach with IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the SNAC network. This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6 service on the infrastructure network that is suitable for communicating using IPv6 to hosts on the SNAC network--there should not be any hosts on the infrastructure network that can't communicate with hosts on the stub network unless such hosts do not have an IPv6 stack at all. So the purpose of providing IPv4 connectivity for SNAC hosts is to enable communication with arbitrary IPv4 hosts which may not be on the AIL.  This is accomplished by providing NAT64 address translation in the stub router, and by enabling service discovery using a Discovery Proxy. </ins> Stub Network routers must be capable of providing NAT64 themselves, and must be capable of discovering the availability of NAT64 service on the infrastructure network and providing it when it is available

Related discussion:
text: Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
Code change:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del> <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf

Related discussion:
text: Addressing issue and
This fixes issue and issue
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:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del> <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf

Related discussion:
text: Updated firmware and Software integrator use case to the same format as the ones above.
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.
Code change:
5.2. SD-JWT-VCs as defined in this specification can use any claim <del> registered in the "JSON Web Token Claims" registry as defined in RFC 7519. </del> <ins> registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins> Some of the claims in a VC MUST NOT be selectively disclosed as they are always required for processing on the verifier side.  All other

Related discussion:
text: NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that
Code change:
3.1.1. <del> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </del> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some

Related discussion:
text: Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.
Code change:
3.1.1. <del> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </del> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
An "iat" claim, whose value is the time at which the Txn-Token was created. <ins> An "aud" claim, whose value is a URN RFC8141 that uniquely identifies the audience of the Txn-Token.  This MUST identify the trust domain in which the Txn-Token is used. </ins> An "exp" claim, whose value is the time at which the Txn-Token expires.

Related discussion:
text: Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.
Code change:
implicitly pressure Verifiers into collusion by incentivizing participation in their larger ecosystem.  Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as <del> possible, and/or make the risks transparent to the End-User. </del> <ins> possible, and/or make the risks transparent to the user. </ins> Contrary to that, Issuer/Verifier unlinkability with an honest Verifier can generally be achieved.  However, a callback from the

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.14. </del> <ins> 3.2.15. </ins> A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.15. </del> <ins> 3.2.16. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks

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:
The following examples demonstrate interactions where a client solicits a "Digest" using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
This header field is only used by an HTTP/2.0 client for Upgrade- based negotiation. <ins> 12.6. This section registers the "PRI" method in the HTTP-p2. PRI No No ConnectionHeader of this document This method is never used by an actual client.  This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2.0 connection known-http. </ins>

Related discussion:
text: In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.
Code change:
Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies. <del> The HTTP Tunnel-Protocol header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </del> <ins> The HTTP ALPN header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </ins> <del> When the CONNECT method is used to establish a tunnel, the Tunnel- Protocol header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </del> <ins> When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </ins> protocols are indicated. <del> The Tunnel-Protocol header field carries an indication of client intent only.  In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other protocols could negotiate protocols differently. </del> <ins> The ALPN header field carries an indication of client intent only. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client.  Other protocols could negotiate protocols differently. </ins> Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
3.2.2.1. <ins> 3.2.2.1.1. </ins> This specification defines the JWT claim . The value MUST be a case-sensitive <del> value serving as an identifier for the type of the SD-JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </del> <ins> (see RFC7519) value serving as an identifier for the type of the SD- JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims

Related discussion:
text: URL
I found several minor issues here: The spec has the following headlines: 4.2.2 Claims Comparing this to RFC7519 JWT these should be: JOSE Header JWT Claims Set Also, in 4.2.2.1 type claim is never explained. This should be added to the Terminology. Its also missing a link to the Annex A.1.
Additionally, headline 4.2.2.1 would better fit saying "New JWT Claims"?
Code change:
For simplicity, assume that the ALTO server is using the Basic authentication.  If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO Cost Map resource <del> with resource ID "my-routingcost-map", it can send the following request: </del> <ins> with resource ID "my-routingcost-map", it can send the request depiced in ex-op. </ins> <del> If the operation is successful, the ALTO server returns the following message: </del> <ins> If the operation is successful, the ALTO server returns the message shown in ex-op-rep. </ins> 6.4.

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
6. <del> There are three primary architectural patterns available when building browser-based applications. </del> <ins> Here are the main architectural patterns available when building browser-based applications. single-domain, not using OAuth a JavaScript application accessing resource servers </ins> <del> a JavaScript application that has methods of sharing data with resource servers, such as using common-domain cookies </del> <ins> either directly </ins> <del> a JavaScript application with a backend component </del> <ins> or through a service worker </ins> <del> a JavaScript application with no backend, accessing resource servers directly </del> <ins> a JavaScript application with a stateful backend component for storing tokens and handling all authentication flows (BFF proxy) </ins> <del> These three architectures have different use cases and considerations. </del> <ins> These architectures have different use cases and considerations. </ins> 6.1. For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the <del> domain of the API (resource server), OAuth adds additional attack vectors that could be avoided with a different solution. </del> <ins> domain of the API (resource server) and the authorization server, OAuth adds additional attack vectors that could be avoided with a different solution. </ins> In particular, using any redirect-based mechanism of obtaining an access token enables the redirect-based attacks described in oauth-

Related discussion:
text: Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy