jiebi/CodeConvo huggingface dataset:
Code change:
Would result in the following "@query" value: <ins> If the query string is absent from the request message, the value is the leading "?" character alone: </ins> If used in a related-response, the "@query" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: This might be why you're getting valid signatures that look different from the examples -- you shouldn't expect to replicate the exact signature values. RSA 1.5 is deterministic, and will always give this same signature for the same input (as will HMAC). This is just one of the reasons why it's not recommended in many environments. I think we can add some text in the examples sections that points this out, if that would be helpful.
NAME You can also test keys and examples at URL for another implementation. I am pretty confident in the values in the examples, but if there are in fact bugs in these implementations (which is always possible!) I'd love to know and fix them.
NAME you were right. I had been verifying the keys by string comparison, so I fixed that. I also worked out what the Java names for the various algorithms were and got nearly all the tests to run on JS and Java platforms. But there is one error left that is consistent across both, so I wrote it up here. URL
Nevertheless, I have not yet been able to import the private key PEM file in JS. So I looked for a way to convert it to JWK to see how that would fare. I looked online, but none of the services worked, I looked at npm but that did not work, finally I found in Java that did the conversion in 2 lines of code. With this I could get signing to work: So there is something problematic with that PEM, at least insofar as it makes it very difficult to get the example to work in JS which should be one of the main platforms. (I have not yet verified the signature in JS as I am having trouble getting verification in JS to work with a valid PSS key, even though I can create the public key with the PEM, and am able to do that Scala-JS)
I think I found the problem to be with the private key. After going through this process: transforming the spec key to JWK as described above transforming the JWK to PEM PKCS1 using node's I get the following transforming the above using Java's Bouncy Castle to PEM I get this: And with that all the JS crypto API tests pass. See the .
Code change:
Would result in the following "@query" value: <ins> If the query string is absent from the request message, the value is the leading "?" character alone: </ins> If used in a related-response, the "@query" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: I think to understand why that final private key works with the Java Web Crypto API but not the original one from which it was derived (which worked with Bouncy-Castle) we'd need the input of someone like NAME . With that public key replaced (in commit ) and a few others commits to get Continuous Integration to work, we have all the tests pass for Scala compiled to JavaScript Those running in the browser are a bit interleaved due to asynchronous execution, something that needs still to be fixed.
Looks good!
Code change:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send payload data in the response (i.e., the response terminates at the end of the header section).  The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., </del> <ins> send payload data in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about the without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications. The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the payload data.  For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain </ins> <del> ) MAY be omitted. HEAD is used to obtain metadata about the </del> <ins> and </ins> <del> without transferring the representation data.  It is often used to test hypertext links for validity, accessibility, and recent modification. </del> <ins> fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the payload data for a HEAD request, since HEAD is usually requested for the sake of efficiency. </ins> A payload within a HEAD request message has no defined semantics; sending payload data in a HEAD request might cause some existing

Related discussion:
text: Note that I also cleaned up the surrounding paragraph and removed parentheses from around the statement that the response always terminates after the header section.
currently links to "Message Payload", but that is not that helpful in order to find out what fields actually are "payload header fields".
Note. We currently say: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 6.4) MAY be omitted." URL would change this to: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., Transfer-Encoding) MAY be omitted." (me confused by that)
I should probably just list them all. Content-Length and Transfer-Encoding are the obvious ones, but I would have to go through the spec to be sure there are not more. The reason for this is that servers do not generate the body on HEAD responses, so the fields that are defined while buffering the first 8K of body (when they can still be sent as headers) are not sent on HEAD responses. Maybe we should just say that.
Code change:
Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this <del> behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </del> <ins> behavior is specific to HTTP/1.1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </ins> Concatenate the list of values together with a single comma (",") and a single space (" ") between each item.

Related discussion:
text: Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.
Code change:
Streams have the following states: <del> In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state.  Frames of unknown types are ignored. </del> <ins> In the absence of more specific rules, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state. The rules in this section only apply to frames defined in this document.  Receipt of frames for which the semantics are unknown cannot be treated as an error as the conditions for sending and receiving those frames are also unknown; see extensibility. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpExamples.  An example of the state

Related discussion:
text: We could try to make every statement precise. We could add "of the frames defined in this document" to a bunch of places. Or we could make a (better) blanket statement. That is what this does.
As discussed in , the current language of 5.1 prohibits all frames on closed streams other than the ones indicated. It is not clear whether the requirement in Section 5.5 constitutes "more specific guidance." My suggestion in the erratum was to scope "any frame" to "any frame defined in this document" where we might allow an extension frame to appear, since that was the minimal change to the RFC 7540 text, but the editors might choose a broader rewording.
So the text already says: "Frames of unknown types are ignored." right next to the guidance you refer to. Maybe we just need to be more direct about this.
Be careful Martin, you removed the sentence "Frames of unknown types are ignored" so I think we're losing one piece of information when looking at the patch. I should re-read it withiin its context to make sure we don't miss anything, but I preferred to warn.
NAME yes, that was a deliberate change. I replaced that text with a complete paragraph and a reference to the extensibility section, which already covers the rules for unknown frames clearly: "Implementations MUST discard frames that have unknown or unsupported types."
I think this is fine.
Code change:
Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison. <ins> Note that this is the same equality comparison procedure described in Section 8.3 of RFC8259. </ins> 7. 7.1.

Related discussion:
text: Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.
Code change:
packaging of media, taking into consideration the various technical trade offs that each provide. <ins> 4.5.1. 4.5.2. 4.5.3. </ins> 4.6. <ins> 4.6.1. 4.6.2. 4.6.3. 4.7. 4.7.1. 4.7.2. 4.7.3. 4.7.4. 4.7.5. 4.8. </ins> End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized intermediates or observers and prevent or restrict ability to decrypt

Related discussion:
text: NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.
Code change:
use a redirect mechanism to communicate between them. An additional concern with handling access tokens in a browser is <del> that as of the date of this publication, there is no secure storage mechanism where JavaScript code can keep the access token to be later used in an API request.  Using an OAuth flow results in the JavaScript code getting an access token, needing to store it somewhere, and then retrieve it to make an API request. Instead, a more secure design is to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </del> <ins> that in case of successful XSS attack, tokens could be read and further used or transmitted by the injected code if no secure storage mechanism is in place. It could as such be considered to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </ins> access the cookie value itself.  The "Secure" cookie attribute should be used to ensure the cookie is not included in unencrypted HTTP requests.  Additionally, the "SameSite" cookie attribute can be used <del> to counter CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </del> <ins> to counter some CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </ins> OAuth was originally created for third-party or federated access to APIs, so it may not be the best solution in a common-domain

Related discussion:
text: Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy
Code change:
Description: RFC 3161 timestamp token <del> Reference: RFCthis </del> <ins> Reference: sec-tst-hdr-ttc of RFCthis </ins> The content of the byte string are the bytes of the DER-encoded RFC 3161 TimeStampToken structure. <del> When used as described in sec-timestamp-then-cose, the message imprint sent to the TSA (RFC3161) MUST be the hash of the payload field of the COSE signed object. </del> <ins> 3.2. The "3161-ctt" COSE </ins> <del> When used as described in sec-cose-then-timestamp, the message imprint sent in the request to the TSA MUST be either: </del> <ins> header parameter MUST be used for the mode described in sec-cose- then-timestamp. The message imprint sent in the request to the TSA MUST be either: </ins> the hash of the signature field of the COSE_Sign1.

Related discussion:
text: See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat
Code change:
Body: SCITT COSE_Sign1 message <del> 2.1.1.2. </del> <ins> 3.1.1.2. </ins> One of the following:

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- sensitive as per HTTP.  While conventionally standardized method <del> names are uppercase US-ASCII, no transformation to the input method value's case is performed. </del> <ins> names are uppercase US-ASCII (STD80), no transformation to the input method value's case is performed. </ins> For example, the following request message:

Related discussion:
text: Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base
Code change:
The "ttl" value is optional and defaults to 31536000 (1 year). <del> 2.1.3. </del> <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,
Code change:
In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  "Claims" here refers to both object <del> properties (key-value pairs) as well as array elements.  When issuing the SD-JWT to the Holder, the Issuer includes the cleartext </del> <ins> properties (name-value pairs) as well as array elements.  When issuing the SD-JWT to the Holder, the Issuer includes the cleartext </ins> counterparts of all hidden claims, the so-called Disclosures, outside the signed part of the SD-JWT.

Related discussion:
text: for and based largely on text suggested on list by Neil Madden
from this thread URL Neil Madden has suggested the following for "Choice of a Hash Algorithm" section. I think (with maybe some minor tweaks) the text works and it would also address issue .
Saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. resulting from this thread URL / URL etc "... indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms."
How to actually write this in an appropriate way for a draft RFC feels kinda tricky though. JWE has some text about using that I was hopping to borrow from but the context is (unsurprisingly) different enough that using text straight from it doesn't quite work. Maybe adding a very general statement in would be sufficient.
At IETF 118 Tuesday meeting, Orie proposed locking the hash to the one committed to by the Issuer. Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use.