jiebi/CodeConvo huggingface dataset:
Code change:
Note that parameters are ordered, and parameter keys cannot contain uppercase letters. <del> When serialised in a textual HTTP field, a Parameter is separated </del> <ins> When serialized in a textual HTTP field, a Parameter is separated </ins> from its Item or Inner List and other Parameters by a semicolon.  For example:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
Subscribe ID: Subscription Identifer as defined in message- subscribe-req. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. <ins> ContentExists: 1 if an object has been published on this track, 0 if not. If 0, then the Largest Group ID and Largest Object ID fields will not be present. Largest Group ID: the largest Group ID available for this track. This Group ID corresponds to the Group that would be returned with a subscribe-locations RelativePrevious value of 0.  This field is only present if ContentExists has a value of 1. Largest Object ID: the largest Object ID available within the largest Group ID for this track.  This Object ID corresponds to the Object that would be returned with a subscribe-locations RelativePrevious value of 0. This field is only present if ContentExists has a value of 1. </ins> 6.6. A publisher sends a SUBSCRIBE_ERROR control message in response to a

Related discussion:
text: It seems like it would be better to transfer this in the STREAMHEADERTRACK and equivalent. Thoughts on that ? I also worry about how long a subscribe would wait to find out this information - that seems like it could be problematic for the client knowing when to give up on a subscribe. Hopefully we can discuss in Denver
Code change:
Subscribe ID: Subscription Identifer as defined in message- subscribe-req. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. <ins> ContentExists: 1 if an object has been published on this track, 0 if not. If 0, then the Largest Group ID and Largest Object ID fields will not be present. Largest Group ID: the largest Group ID available for this track. This Group ID corresponds to the Group that would be returned with a subscribe-locations RelativePrevious value of 0.  This field is only present if ContentExists has a value of 1. Largest Object ID: the largest Object ID available within the largest Group ID for this track.  This Object ID corresponds to the Object that would be returned with a subscribe-locations RelativePrevious value of 0. This field is only present if ContentExists has a value of 1. </ins> 6.6. A publisher sends a SUBSCRIBE_ERROR control message in response to a

Related discussion:
text: This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.
Code change:
Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. <del> The Key Binding JWT MAY include addtional claims which, when not </del> <ins> The Key Binding JWT MAY include additional claims which, when not </ins> understood, MUST be ignored by the Verifier. 4.2.

Related discussion:
text: also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.
Code change:
12.5. <del> This memo updates the "SHA" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "SHA" digest-algorithm in the HTTP Digest </ins> Algorithm Values [7] registry: Digest Algorithm: SHA

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality, if the privacy of End-User data or correlation attacks are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </del> <ins> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </ins> 9.3.

Related discussion:
text: When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL
Code change:
The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For <del> example, "example.com"'s public suffix is "com".  User agents SHOULD </del> <ins> example, "site.example"'s public suffix is "com".  User agents SHOULD </ins> use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. An origin's "registered domain" is the origin's host's public suffix <del> plus the label to its left.  That is, for "https://www.example.com", the public suffix is "com", and the registered domain is "example.com".  This concept is defined more rigorously in PSL, and </del> <ins> plus the label to its left.  That is, for "https://www.site.example", the public suffix is "example", and the registered domain is "site.example".  This concept is defined more rigorously in PSL, and </ins> is also known as "effective top-level domain plus one" (eTLD+1). The term "request", as well as a request's "client", "current url",

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.
Code change:
that some of them are supported by default by RFC8345): Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
this specification which the native application uses to obtain an authorization code. <ins> Authorization servers supporting this specification SHOULD include the URL of their authorization challenge endpoint in their authorization server metadata document RFC8414 using the "authorization_challenge_request_endpoint" parameter as defined in authorization-server-metadata. The endpoint accepts the authorization request parameters defined in RFC6749 for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint.  Some examples of such extensions include Proof Key for Code Exchange (PKCE) RFC7636, Resource Indicators RFC8707, and OpenID Connect (OIDC) [OIDC].  It is important to note that some extension parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query).  It is out of scope as to what the AS does in the case that an extension defines a parameter that is has no meaning in this use case. </ins> The client initiates the authorization flow with or without information collected from the user (e.g. a password or MFA code).

Related discussion:
text: I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Code change:
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <del> 5.4. </del> <ins> 5.5. </ins> The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to

Related discussion:
text: Based on discussions with NAME NAME and others, there are potential key confusion attacks when the server is checking the signature using the wrong public key. I think the simplest solution is to add the public key to the TLS key exporter. That should solve the issue without increasing the amount of bytes sent on the wire
Including the public key in the exporter context makes it significantly harder to implement the server side of this. Including the hash of the public key in the signature appears to work also. I have a sketch model in Tamarin that doesn't find any attacks when the hash of the public key is in the signature, which gives me some confidence that it's doable, although NAME wasn't convinced. We should discuss this in the room at 117.
I agree with NAME The implementation complexity that comes from putting the public key in the exporter context is real, at least for some edge networks. I think we should pursue alternatives that don't weaken the security properties, even if they make the registration step a bit more explicit.
If this design makes implementation hard then we should totally change it. Can I ask you to elaborate on what causes this to be hard on the server side?
The basic problem in our particular case is that the component that terminates TLS and computes exported values is upstream of the component that has the public key. So when a request comes in with the header to the TLS terminator, the public key needs to get relayed back for computation. If, instead, the public key was signed, then the TLS terminator could simply forward the computed exporter without any sort of round trip. (I punched this in on my phone, but can draw pictures on a laptop if the above is not clear.) We don't necessarily need to cater to one implementation, but I would be surprised if this were not a common arrangement in practice.
Thanks, that makes sense. To explore the problem space: if we were to include the public key in both the context and a header parameter, would that work for your implementation? (That way the TLS terminator can call the exporter without a round trip.)
Yep, that would address the problem too.
SIGMA seems like it might be worth considering as an alternative. That is, sign the nonce, but then include a MAC that covers all of the relevant parameters.
Something like SIGMA should also work, but I'd like to minimize the number of primitives required to implement this.
Code change:
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <del> 5.4. </del> <ins> 5.5. </ins> The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to

Related discussion:
text: Currently, modifying an HTTPS stack to support this draft only requires a signature implementation and a TLS key exporter API. Using a MAC would require a MAC primitive and opens the question "which MAC should we use?"
That's an easy question: you are using HKDF to get the values, so HMAC is a logical choice. The only reason I suggested that is that I'm increasingly nervous about these bespoke constructions. We understand what sign and mac provides.
I think we need to first identify what property it is we actually want, and then see what is the simplest way to get there. NAME what is the property we want?
NAME had a long chat about this today. We didn't come to any solid conclusions - the authentication property here is really subtle and the attacker model not yet clear. This is going to need some really careful work and detailed formal analysis to get right. In terms of this discussion, my personal take would be: I don't think a mac & sign approach is going to give you anything strictly better or different than an exporter + signature approach. In both cases its just a question of what you put in the exporter / mac. Having the public key conveyed in the header and bound explicitly in the exporter (rather than via the keyid) seems like a conservative and reasonable approach.
Thanks for thinking through this! I've written up to add the public key to both the context and the header
Code change:
additional considerations when Integrity fields are included in this set. <del> There are no restrictions placed on the type or format of digitial </del> <ins> There are no restrictions placed on the type or format of digital </ins> signature that Integrity fields can be used with.  One possible approach is to combine them with HTTP Message Signatures SIGNATURES. <del> Digests explicitly depend on the "representation metadata" (e.g. the </del> <ins> Digests explicitly depend on the "representation metadata" (e.g., the </ins> values of "Content-Type", "Content-Encoding" etc).  A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering.  For example, an actor could

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded. <del> 2.1.2. </del> <ins> 2.2.2. </ins> <del> 2.1.2.1. </del> <ins> 2.2.2.1. </ins> <del> 2.1.2.2. </del> <ins> 2.2.2.2. </ins> One of the following:

Related discussion:
text: Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.
Code change:
Operation ID returned in the response.  Clients should always obtain a Receipt as a proof that Registration has succeeded. <del> 2.1.2. </del> <ins> 2.2.2. </ins> <del> 2.1.2.1. </del> <ins> 2.2.2.1. </ins> <del> 2.1.2.2. </del> <ins> 2.2.2.2. </ins> One of the following:

Related discussion:
text: The transparency service knows that animal products require certificates to be imported, and issues a challenge token that looks like this: iss: "https://transparency.example" aud: "https://transparency.example" iat: ${now} exp: ${now + 7 day} currenttreehead: ... (not all TS are trees) currentpolicyhash: ... (not all policies are stored in trees) entrynumber: 42 htscodes: [ 16056100 ] The holder starts registering signed statements, each is bound to the same "challenge token". The first signed statement covers a phytosanitary certificate for the sea cucumber processing facility. The regulatory requirements change. The second signed statement covers the (now required) export certificate for sea cucumbers. The transparency service would normally have rejected the second signed statement, but because of the context in the challenge token, the transparency service knows that the second signed statement is now actually required. The holder did not need to request a "new challenge token" when the regulatory changes happened, and the holder still had to prove possession of the public key bound to both certificates ( and these public keys are different ). I chose to make this context scenario about sea cucumbers, but it could easily have been about network capable hardware devices that need to comply with regulations specific to Radio Antennas and GPUs... In those cases there would be firmware certifications required, and compliance requirements might change inside the transaction window. This also solves the problem of forcing the issuer to commit to the registration policies as they exist at the time the "challenge token" is issued. The TS can reject registrations that are committing to stale policies, or accept registrations that are commiting to stale policies, because the TS will know which policies the issuer is committing to by checking the challenge token. In the case that proof of possession is not required, and there is no need to commit to policies, the challenge token can be omitted, and the registration can proceed exactly as it is specified today. OS ORIE STEELE Chief Technology Officer www.transmute.industries