jiebi/CodeConvo huggingface dataset:
Code change:
Transparency Services MUST maintain Registration Policies. <del> Transparency Services MUST also maintain a list of trust anchors used to authenticate Issuers, which MAY be included in a registration policy statement.  For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. </del> <ins> Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a registration policy statement.  For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. </ins> Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
6. MOQT uses a single bidirectional stream to exchange control messages, <del> as defined in session-init.  Every signle message on the control </del> <ins> as defined in session-init.  Every single message on the control </ins> stream is formatted as follows: An endpoint that receives an unknown message type MUST close the

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
considered complete. The next example shows an upload creation, where only the first 25 <del> bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </del> <ins> bytes of a 100 bytes upload are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
Code change:
considered complete. The next example shows an upload creation, where only the first 25 <del> bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </del> <ins> bytes of a 100 bytes upload are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
receives a non-error response to a request with a method whose safety is unknown. <del> Here, a "non-error response" is one with a </del> <ins> means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. A "non-error response" is one with a </ins> or status code. <ins> Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches it travels through. </ins> 5. This section defines the syntax and semantics of HTTP fields related

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
4. A server can notify its support for CACHE_DIGEST frame by sending the <del> ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </del> <ins> SETTINGS_ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </ins> SHOULD send the SETTINGS parameter immediately after the connection is established.

Related discussion:
text: Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!
Code change:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <del> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </del> <ins> Applications that make use of the content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </ins> field in the request, the server is unable to include a signature that covers the request's content.

Related discussion:
text: Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
Code change:
RFC3040 (also commonly known as a <del> RFC1919 or ) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </del> <ins> RFC1919) differs from an HTTP proxy because it is not chosen by the client.  Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </ins> Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate

Related discussion:
text: refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.
Code change:
4.1.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the Consumption Device (e.g., Smart TV) </del> <ins> QR code or a user code on the Consumption Device (e.g., smart TV) </ins> which is then scanned or entered on the Authorization Device (the mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being

Related discussion:
text: Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >
Code change:
A URI in the claim can be used to express a type.  If the type is a URL using the <del> HTTPS scheme, Type Metadata can be retrieved from the URL , i.e., by inserting after the authority part of the URL. </del> <ins> HTTPS scheme, Type Metadata MAY be retrieved from it. </ins> The Type Metadata is retrieved using the HTTP GET method.  The response MUST be a JSON object as defined in type-metadata-format.

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.
Code change:
A URI in the claim can be used to express a type.  If the type is a URL using the <del> HTTPS scheme, Type Metadata can be retrieved from the URL , i.e., by inserting after the authority part of the URL. </del> <ins> HTTPS scheme, Type Metadata MAY be retrieved from it. </ins> The Type Metadata is retrieved using the HTTP GET method.  The response MUST be a JSON object as defined in type-metadata-format.

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
6. <del> IANA is requested to add the two COSE header parameters described in sec-tst-hdr to the "COSE Header Parameters" registry in the IANA.cose registry group. </del> <ins> IANA is requested to add the COSE header parameters defined in tbl- new-hdrs to the "COSE Header Parameters" registry IANA.cose_header- parameters. </ins>

Related discussion:
text: and have pointed out that the current registration requests are rather informal and could be improved using the templates in . All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock wrote:
Answering Mike P.’s question about IANA registrations, it is strongly preferred to have the IANA Considerations section follow the registration template and contain the exact values to be placed in the registry (with the Label of course, being TBD). An example of such IANA Considerations text is URL Please update the draft to add this content. Thanks, -- Mike From: Michael Prorock Sent: Friday, August 23, 2024 5:40 AM To: Michael Prorock Cc: Michael Jones ; cose Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-tsa-tst-header-parameter All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels).
Code change:
6. <del> IANA is requested to add the two COSE header parameters described in sec-tst-hdr to the "COSE Header Parameters" registry in the IANA.cose registry group. </del> <ins> IANA is requested to add the COSE header parameters defined in tbl- new-hdrs to the "COSE Header Parameters" registry IANA.cose_header- parameters. </ins>

Related discussion:
text: That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock > wrote: Thanks for the additional time Mike and Ivo. I support moving this along, but I would like to perform a detailed read through. I have some time set aside for this and will have comments back next week. Mike Prorock founder - URL Ivo and I reviewed the results of the WGLC and there have been no responses whatsoever – even from the authors. We are therefore extending the WGLC for another two weeks until Tuesday, August 27th. Unless multiple people support progressing the draft, we will not request publication. Please send your reviews and feedback on the draft. Thank you, -- Mike and Ivo From: Michael Jones > Sent: Tuesday, July 30, 2024 10:53 AM 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