jiebi/CodeConvo huggingface dataset:
Code change:
ephemeral keys to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by having that entity metering the <del> availability of keys temporally or geographically).  Unprompted Authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </del> <ins> availability of keys temporally or geographically).  The Signature HTTP authentication scheme is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </ins> There are scenarios where servers may want to expose the fact that authentication is required for access to specific resources.  This is

Related discussion:
text: But I don't feel strongly about this one so I'm happy to not include it if it's the WG's preference.
Just saying here's a registry that you might could co-opt: URL Defined by URL
This is an existing registry of hash algorithms with string identifiers: URL Defined by URL
Discussed at IETF 116, sense of the room appeared to be that removing the HMAC feature entirely and switching to the TLS SignatureScheme registry for signatures was the simplest solution here.
OK wrote up to address this
Is there a technical reason why the header was not chosen for this draft? That can be sent without a corresponding challenge (in an unprompted way), as we note in the . It seems like that would work in this context, too.
Is this rather about using the Authorization header?
Yep!
NAME can you elaborate on "as we note in the "? I skimmed through that draft and it seems to clearly require a TokenChallenge before sending a Token.
I thought we had text that described it, but I can't find it. In any case, I think one can send the Authorization header unsolicited, so I think this draft ought to do that instead of rolling a new auth header.
Fair enough, let's discuss this at 116.
FWIW, I agree that unprompted "Authorization" is permissible in this context, but I think "Unprompted-Authorization" could be useful for clarity when reading logs, etc.
Discussed at IETF 116, sense of the room appeared to be that switching to Authorization made sense.
OK wrote up to address this
Code change:
5.2.2. <del> General-purpose protocols need to coexist in the Internet with real- </del> <ins> General-purpose algorithms need to coexist in the Internet with real- </ins> time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available capacity) and more strict latency bounds.  See RFC8836 for a

Related discussion:
text: The title of section 5.2.1 mentions general-purpose transports but the content really about comparing against standard congestion control algorithms, I suggest to reflect that in the section title. URL
Hmmm: This was originally conceived as General-Purpose v Real-Time (next section). If we change this to "standard general-purpose congestion control algorithms" , does it then make "real-time look non-standard - so ought that now be "standard real-time congestion control algorithms"? Would that help?
It was not that clear that it was supposed to convey "general-purpose" VS "real-time". But my main point was that if this is all about congestion control for general purpose transport then lets say that. Competing with general purpose congestion control Competing with real-time congestion control
Code change:
8.8.3. An HTTP POST request that includes control data and a request header <del> and message content is transmitted as one HEADERS frame, followed by </del> <ins> with message content is transmitted as one HEADERS frame, followed by </ins> zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA

Related discussion:
text: This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:
Code change:
1.2. <del> The abstract OAuth 2.0 flow illustrated in fig-protocol-flow </del> <ins> The abstract OAuth 2.1 flow illustrated in fig-protocol-flow </ins> describes the interaction between the four roles and includes the following steps:

Related discussion:
text: Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different
Code change:
The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the <del> receipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a StreamErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in

Related discussion:
text: Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:
Code change:
In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client <del> request's last-byte-pos in the Content-Range response header. </del> <ins> request's last-byte-pos in the Content-Range response header field. </ins> For example:

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
defined by the issuer.  Using a WIMSE ID without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain.  Additionally, the trust domain must be <del> tied to an authorized issuer cryptographic trust root through some </del> <ins> tied to an authorized issuer cryptographic trust anchor through some </ins> mechanism such as a JWKS or X.509 certificate chain.  The association <del> of an issuer, trust domain and a cryptographic trust root MUST be </del> <ins> of an issuer, trust domain and a cryptographic trust anchor MUST be </ins> communicated securely out of band. 6.2.

Related discussion:
text: Change trust root to trust anchor, to align with Trust Anchor terminology as used in rfc5280.
sure
Code change:
client in fields when forwarding the request to a service host, including a signature over the client's original signature values. <del> The following is a non-normative example of header fields a reverse proxy sets in addition to the examples in the previous sections. </del> <ins> The following is a non-normative example starts with a signed request from the client.  The proxy takes this request validates the client's signature. </ins> <del> The client's request includes a signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header defined in RFC7239.  Note that since the client's signature already covers the client's "Signature-Input" value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  This results in a signature input string of: </del> <ins> The proxy then alters the message before forwarding it on to the origin server, changing the target host and adding the "Forwarded" header defined in RFC7239. The proxy includes the client's signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header. Note that since the client's signature already covers the client's "Signature-Input" value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature input string of: </ins> And a signature output value of:

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples
Code change:
(D) The client presents the authorization grant to the authorization server of Domain B.  See access-token-request. <del> (E) Authorization server of Domain B validates the authorization grant and returns an access token. </del> <ins> (E) Authorization server of Domain B validates the JWT authorization grant and returns an access token. </ins> (F) The client now possesses an access token to access the protected resource in Domain B.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
5. <del> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core. </del> <ins> 5.1. Please register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by I-D.ietf-httpbis- semantics: Field name: Client-Cert Status: permanent Specification document: headers of [this document] Field name: Client-Cert-Chain Status: permanent Specification document: headers of [this document] </ins>

Related discussion:
text: fill out client-cert's IANA Considerations with HTTP field name registrations to
NAME wrote: http-core. This should be pretty simple to add, but for the purposes of having a clean PR pulling out the TODOs, I'm moving it to an issue for now anyway.
URL points to draft-ietf-httpbis-semantics for this
Code change:
their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content <del> adaption, and optinally use additional mechanisms to negotiate </del> <ins> adaption, and optionally use additional mechanisms to negotiate </ins> delegation policies that control access of third parties to same fields.

Related discussion:
text: Per discussions in fetch [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] URL /cc NAME NAME
Code change:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del> <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins> <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del> <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.

Related discussion:
text: to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!
Code change:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del> <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins> <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del> <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.

Related discussion:
text: In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.
Code change:
2.4.3. <del> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or "urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. 2.4.4. </del> All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification.

Related discussion:
text: and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
Code change:
2.4.3. <del> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or "urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. 2.4.4. </del> All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification.

Related discussion:
text: example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT
Code change:
structure, together with the hash itself. As part of the signature verification, the receiver MUST make sure <del> that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use. </del> <ins> that the message imprint in the embedded timestamp token matches a hash of either the payload, signature, or signature fields, depending on the mode of use and type of COSE structure. </ins> RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing

Related discussion:
text: URL [ ] In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. [ ] In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” The draft looks good to me. I have two minor suggestions. In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” From: Michael Jones Date: Tuesday, July 30, 2024 at 1:53 PM To: "EMAIL" Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs _____ COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL
Code change:
An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in <del> RFC8941 on a Dictionary containing only that item. </del> <ins> RFC8941 on the member value and its parameters, without the dictionary key. </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature input.  Parameterized keys MAY appear in any

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples